You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Difference between revisions of "Deployments/Train/Ideas"

From Wikitech-static
Jump to navigation Jump to search
imported>20after4
(some train process ideas)
 
imported>20after4
(link mw:Wikimedia_Release_Engineering_Team/Project/Train2.0)
Line 1: Line 1:
{{ptag|train deployments}}
{{TOC|align=right}}
{{Navigation MediaWiki deployment}}
This is a page to put train improvement/change ideas
This is a page to put train improvement/change ideas
{{TOCright}}


=== Small incremental changes ===
=== Small incremental changes ===
Line 19: Line 21:


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.
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.
=== See Also ===
[[mw:Wikimedia Release Engineering Team/Project/Train2.0|Wikimedia Release Engineering Team / Project / Train 2.0]]

Revision as of 17:50, 15 October 2021

Deployments

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.

See Also

Wikimedia Release Engineering Team / Project / Train 2.0