Wikimedia Release Engineering Team/Project/Train2.0

This page is to plan out the work needed to accomplish the "train 2.0" goal.

Goal
Improve our weekly deployment train process by using a saner deployment and release process. Primarly this means moving to a long-lived branch strategy versus the current weekly branching strategy.

Much thought has gone into the way we do our "deployment train," and especially the weekly branch cutting. Several adjustments to this process will result in a significant increase in quality and improved developer productivity.

What

 * Maintain two long-lived production branches, wmf/next and wmf/prod
 * Periodically merge from master into wmf/next. As part of this process, all merged commits should be briefly reviewed for production readiness
 * Communicate with the author of questionable or not-well-understoon commits. Release engineering should be confident that a change is reasonable before merging to wmf/prod. Otherwise the commit will be reverted on the branch.

Dependencies

 * TechOps for any needed caching changes.
 * MediaWiki expertise for the needed changes to MW internals.

Movement

 * Improved code quality means less outages and less bugs make it to production.
 * We should be able to move more quickly and with more confidence, releasing improvements sooner / more often

Foundation

 * Less time spent cutting branches and less time spent hunting down unexpected changes during a deployment. Release Engineering should have a much better "big picture" understanding of what is happening across mediawiki teams, leading to better response to problems when they do arise.

Milestones (FY 2016/17)
(or "how to get there from here")