[Engineering] [Ops] Changes to SWAT deployment policies, effective Monday April 30th

Timo Tijhof ttijhof at wikimedia.org
Fri Apr 27 23:33:48 UTC 2018


On 27 April 2018 at 15:59, Brad Jorsch (Anomie) <bjorsch at wikimedia.org>
wrote:

>
> I'd hate to see people mangling[1] the git log by submitting and merging
> patch chains for updating individual files of a single logical change just
> to satisfy this SWAT requirement. I'd hate even more if people do that in
> mediawiki/core master (versus splitting an existing patch while
> backporting), to the point where I'd recommend -2ing such patch-chains
> there.
>


Those are good points, but I disagree that these are specific to SWAT. I
assume we all want things like "Keeping the site up", and "Verify code in a
representative and meaningful way before deploying to production".
Regardless of whether someone deploys on their own, or uses the convenience
of SWAT.

The bottom line is that each commit should be verifiable and deployable.
The changes to the SWAT policy ensure that:

* Verifiable: Can be staged on tin and staged on mwdebug1002 in a way is
representative of actual deployment.
* Deployable: Can be deployed in one step, and the deployed state matches
Git, and can be reverted in one step if needed.

These are incompatible with syncing a patch in two steps. Such as adding a
variable, dblist or function; and referencing it from another file. Because
if you do, our current deployment workflow will not result in a state on
mwdebug1002 that matches the result of the (first) sync command. As such,
the verification is not as meaningful given actual sync may still break the
site. This has happened on more than one occasion, in part because we don't
have strict pre-promote checks[1] (although it is being worked on).

Making complex changes and refactors in mediawiki/core is fine. But if it
can't wait for the train or can't be given its own window with full scap,
it will need to be broken down into smaller changes that each can be safely
merged, beta'ed, cherry-picked, verified and deployed.

-- Timo

[1] https://phabricator.wikimedia.org/T121597
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/engineering/attachments/20180428/0780ceec/attachment-0001.html>


More information about the Engineering mailing list