> 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