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

Tyler Cipriani tcipriani at wikimedia.org
Fri Apr 27 19:03:48 UTC 2018


On 18-04-27 10:49:28, Stas Malyshev wrote:
>Hi!
>
>> First, we now disallow multi-sync patch deployments. See T187761[0].
>> This means that the sync order of files is determined by git commit
>> parent relationships (or Gerrit's "depends-on"). This is to prevent SWAT
>> deployers from accidentally syncing two patches in the wrong order.
>
>Question about this: if there's a patch that requires files to land in
>specific order, e.g. one that part of the config is moved into another
>file (example: https://gerrit.wikimedia.org/r/c/419367) is this handled
>automatically by scap (i.e. all changes in the same patch land at the
>same time atomically and scap takes care of nothing ever seeing the
>intermediate states) or has to be managed manually, and if so, how?

Scap doesn't currently handle this since for MediaWiki deploys it's 
still using rsync at a basic level.

Currently, syncing changes in a way that avoids bad intermediate states 
is handled by the SWAT deployer and is determined on the fly at the time 
of deployment.

That is, the deployer figures out how to sync stuff on the fly. And 
deployers are pretty good at it, mostly. If I were deploying that change 
today I'd split it up and sync one at a time:

    - wmf-config/WikibaseSearchSettings.php
    - wmf-config/InitialiseSettings.php
    - wmf-config/Wikibase.php
    - wmf-config/Wikibase-production.php

(or maybe I'd combine the last two into a sync-dir wmf-config).

The new policy asks the folks submitting patches to split up patches to 
avoid bad intermediate states ahead of time.

So Instead of me syncing that change one file at a time, maybe that 
change becomes two changes and I can pull a change that adds the 
WikibaseSearchSettings.php file and the variables in 
InitialiseSettings.php -- sync-dir wmf-config, and then a second patch 
that could be synced all at once as well. Two syncs rather than 3 or 4 
in this case.

The hope is that this will be more efficient, less error-prone, and 
lower the difficulty factor for deployers. Ideally, this makes it more 
and more difficult to earn a t-shirt[0] :)

-- Tyler

[0]. <https://photos.tylercipriani.com/i-broke-wikipedia.jpg>



More information about the Engineering mailing list