User:Cmcmahon/io process

The Release Engineering team interacts with and responds to and anticipates the needs of other teams at WMF involved in the delivery of software features to production.

RelEng oversees many of the tools and frameworks that help in the delivery of software features, from development environments test frameworks to deployment scripts.

Tools and Frameworks

Here is a list of tools and frameworks that people in Release Engineering understand and maintain. We may not be the only ones who know about each item, but we are all knowledgeable to a certain extent about all of the systems listed here.

Initial	Tools and frameworks	People with answers
B	Browser tests	Chris, Željko, Rummana
BC	Beta cluster	Antoine, Chris
ET	Exploratory Testing	Rummana, Elena (Željko, Chris also)
J	Jenkins/Zuul	Antoine, Željko
P	Puppet	Dan, Mukunda
PH	Phabricator	Mukunda
SC	SCAP	Greg, Mukunda
SL	SauceLabs	Željko, Chris
SW	SWAT	Greg
V	Vagrant	Dan

Teams and Tools

Release Engineering has direct, reciprocal relationships with at least ten other teams within WMF. Here is a table that attempts to capture the nature of those relationships in terms of the tools and frameworks that we use in common.

Team	Tools
Editing	B BC ET J PH SC SL V
Mobile Web/Apps	B BC ET J PH SC SL SW V
Services/Parsoid	BC J PH SW
Collaboration	B BC J PH SC SL SW V
Language	B BC J PH SC SL V
Core	BC J P PH SC SW
Multimedia	B BC J PH SC SL SW V
Engineering Community Team	B(?) BC PH
Team Practices Group	PH
Ops	BC P SC
(Fundraising)
(Zero)
(Design)

How Release Engineering Works

Release Engineering creates, manages, and supports the tools and practices that allow developers to create software easily, manage software safely, and get software to users quickly. As such, we have several input modes for work that we do:

Anticipation

When a software developer says "I would like to be able to do X", we in Release Engineering strive to be able to say in reply "OK, we already know how to do X, let us show you".

For example, no one expected that a public, shared test environment would be particularly valuable until people who are now working in Release Engineering began to make the beta cluster useful. For another example, shared development environments using Vagrant were only an experiment until people who are now working in Release Engineering made them robust and useful.

Mandate

From time to time the Foundation mandates particular practices. Automated browser tests were a mandate in early 2012. A fast deploy cycle was a mandate in early 2013. Replacing Bugzilla with Phabricator was a mandate in 2014. People in Release Engineering were critical to the success of each of these projects.

Reaction

Many of the teams we work with request improvements to the tools and systems that Release Engineering works with. We work to accommodate these requests.

Priorities

Clearly, Release Engineering priorities can undergo large shifts in short amounts of time. In general, we prioritize reactions over mandates over anticipation. We serve our colleagues first.

But we must also always balance ease, safety, and speed. The easiest thing to do is not always safe or fast, and negotiating the work we do in the context of the values we share occurs daily, week, monthly, and quarterly amongst the members of the Release Engineering team, and with the teams we serve.

We have adopted a number of practices to serve this negotiation:

• well attended weekly team meeting for all of Release Engineering
• Roadmap and Deployments meeting for senior WMF staff
• participating in Scrum of Scrums
• institutional pair-programming sessions for RelEng team people
• institutional pair-programming sessions for RelEng people and colleagues in other teams
  • Željko Filipin and others
• training sessions and public presentations
• significant contributions to code repositories across WMF, from extensions to core to operations
• significant interaction with a volunteer community who share our interests, including past projects with GSOC and OPW
• close coordination with the Operations team, on whom we depend for production services
• close coordination with Team Practices Group, with whom we share a common interest in cross-team process, practice, and methodology