Hi All!
tl;dr: if you're a developer looking for guidance on how to deploy changes to Wikimedia's MediaWiki cluster read https://w.wiki/36nY ; if you have thoughts on our existing deployment documentation comment on https://w.wiki/36nZ
---
Over time The Train™ has become the default way to deploy changes to Wikimedia's MediaWiki cluster -- for some patches that may not always be the right path. If a developer needs a change deployed *now*, or if there is a desire to deploy a change in isolation then backports might be a better path.
As with all things, some exceptions may apply. The Release Engineering team has created some guidelines[0] that will hopefully help explain when something MUST, SHOULD, or MAY[1] be deployed via the train or via backport.
This documentation is a bookmarkable quick reference for developers. It does not change our backport window guidelines[2] or special deployment window guidelines[3], those documents should not be in conflict with the advice in the new guidelines. The new guidelines target a different use-case.
Our deployment documentation is up-to-date but sprawling. The same information is in multiple places and multiple audiences and use-cases are often mixed into the same documents. Work to improve deployment documentation is tracked on Phabricator[4].
Please reach out in #wikimedia-releng on freenode in IRC or attend the Deployment Office Hours meeting (weekly on Mondays at 17:00UTC in #wikimedia-office on freenode in IRC) if you have questions.
Thank you! -- Tyler
[0]: https://wikitech.wikimedia.org/wiki/Deployments/Train_vs_backport [1]: https://tools.ietf.org/html/rfc2119 [2]: https://wikitech.wikimedia.org/wiki/Backport_windows#Guidelines [3]: https://wikitech.wikimedia.org/wiki/Deployments/Inclusion_criteria [4]: https://phabricator.wikimedia.org/T273802
Hi,
On 3/18/21 1:49 PM, Tyler Cipriani wrote:
Over time The Train™ has become the default way to deploy changes to Wikimedia's MediaWiki cluster -- for some patches that may not always be the right path. If a developer needs a change deployed *now*, or if there is a desire to deploy a change in isolation then backports might be a better path.
As with all things, some exceptions may apply. The Release Engineering team has created some guidelines[0] that will hopefully help explain when something MUST, SHOULD, or MAY[1] be deployed via the train or via backport.
Is this suppose to codify existing practice, or suggest/recommend people should be deploying things more frequently outside of the normal train? Tgr has raised roughly the same question on the talk page: https://wikitech.wikimedia.org/wiki/Talk:Deployments/Train_vs_backport.
Thanks, -- Legoktm
Hi!
On Tue, Mar 23, 2021 at 2:59 PM Kunal Mehta legoktm@member.fsf.org wrote:
As with all things, some exceptions may apply. The Release Engineering team has created some guidelines[0] that will hopefully help explain when something MUST, SHOULD, or MAY[1] be deployed via the train or via backport.
Is this suppose to codify existing practice, or suggest/recommend people should be deploying things more frequently outside of the normal train? Tgr has raised roughly the same question on the talk page: https://wikitech.wikimedia.org/wiki/Talk:Deployments/Train_vs_backport.
Arg! Missed that there was discussion there :(
I'll follow-up here and try to answer the additional questions there as well.
The intent of this page is to encourage more deployments outside of the normal train by developers and code authors.
This page was meant to make clear the types of changes that would be difficult to deploy outside of the train for historical reasons, and to encourage the authors of other types of patches to consider deploying the change themselves or with a deployer in a backport window.
There are a few reasons that releng wants to encourage backports: 1. Smaller deployments are easier to reason about 2. The code author is often in the best position to reason the effect of their changes 3. The use of mwdebug as a manual testing platform, while similar to the group-by-group rollout of the train, can ensure that a change is working on several wikis in multiple groups with no impact to users.
Not every patch can be backported (just due to hours/day -- 420 changes this train[0] -- 5 minute deploy each is 35 hours of deploying), also backport windows are finite, and deployers time is limited. With those constraints in mind, we'd still like to move to a more continuous model of delivery and the hope is that these guidelines are a step in that direction. I'm also open to other ideas about ways to make the train a lighter and more consistent process.
Thanks! -- Tyler
[0]: https://www.mediawiki.org/wiki/MediaWiki_1.36/wmf.36/Changelog
wikitech-l@lists.wikimedia.org