Deployments/Train/Ideas

From Wikitech-static
< Deployments‎ | Train
Revision as of 23:32, 14 October 2021 by imported>20after4 (some train process ideas)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This is a page to put train improvement/change ideas

Small incremental changes

These are the less drastic ideas which could be implemented in small steps without drastic changes to the process

Deploy smaller batches more frequently

Just like the current train but with smaller batches deployed more frequently. As a starting point, consider daily instead of weekly.

Just stop cutting train branches! Everything must be landed in production via backports to the existing production branch.

Simply stop doing trains. Everything is deployed via backport windows using the current backport process. Although this wouldn't require drastic changes to processes or infrastructure it would become a bottleneck for getting patches merged and deployed. At a minimum this would require some automation to help usher patches through the backport and deployment process with minimal overhead. This is similar to what I proposed years ago, see T89945 and for even more context: https://phabricator.wikimedia.org/project/board/2117/query/all/

Large and disruptive changes

These ideas are larger, more disruptive. Maybe even transformative to the point where the current process would be almost completely replaced with a new and different process.

Deploy Batches of Patches, one per team

In this model, each team would be in charge of their own deployment velocity. Instead of merging directly to main, teams would have their merges batched and landed all together as soon as they give the green light for their batch to go to production.

Someone from each team would be responsible for monitoring their batch and rolling back anything that breaks production. Release Engineering would provide automation and support for the process.