Page MenuHomePhabricator
Paste P14231

Deployment of a backport, the very short version (atg notes)
ActivePublic
Actions

Authored by ArielGlenn on Feb 8 2021, 11:21 AM.
NOTE: at this writing mwdebug1003 is on stretch and mwdebug1001,2
are on buster; use the buster ones for testing unless there is a
stretch-specific thing you are checking.
ALSO NOTE: official docs on deployment are on wikitech at
https://wikitech.wikimedia.org/wiki/How_to_deploy_code
and the official docs on how to do backports and deploy those are at
https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers
* Backporting in gerrit is a matter of figuring out which versions are
deployed where that need the backport; you can look at
https://versions.toolforge.org/ and then if there are entries that
list multiple versions for a group of wikis, you can go to any current
copy of the mediawiki-config repo, grep for the version(s) that interest
you in wikiversions.json, and determine which specific wikis run those
versions. once you've determined which versions should get the backport,
you can do the backport directly in gerrit, by going to the merged changeset
in master, in the upper right corner clicking the three dots for the extended
menu, selecting "cherry pick", typing "wmf" to get the suggestion list, and
as much needed of the branch to see the desired branch in the suggestion
list, and choose that. The rest should be self-explanatory.
* If you are the +2-er on master, you can also backport in gerrit (wait until
master +2 post-merge jenkins completes, then you can do it) and +2 it there
* anyone can grab a ubn ticket w/ a patch and herd it along, there is no set
procedure, but it is preferred that someone on the clinic duty team grab
and do it, including the deploy.
* You don't have to wait for a window if it's really OMG UBN (as opposed to
"we'd like it done soon but things are not on fire"), but then you do need
to make sure someone from sre is around in case there are issues with the
deploy, and you should announce to releng too. channels for these:
#wikimedia-sre (to ask for someone to pay attention to the deploy),
#wikimedia-releng (to notifiy releng), #wikimedia-operations (to discuss
each step of the deploy as it happens).
* If you are using a backport/deploy window, you don't need to ask for an sre
since these windows are scheduled on the deployment calendar and known in
advance, but you do need to add your info to the calendar:
https://wikitech.wikimedia.org/wiki/Deployments
you can +2 and merge the backport ahead of time but you should time it
so that the merge finishes up around the start of the window or later,
instead of completing well beforehand.
* Verify that you can reproduce the bug that's being fixed, before you start,
so that you know the procedure to check if the error is gone on the
appropriate mwdebug host.
* If it's not an error but a feature, verify that you know how to use the
feature and test for its presence on the right mwdebug host.
* If you are deploying in a window, there is a list of deployers who might
manage the window on the Deployments calendar. In practice one of those
people will announce that they are managing the window for that time.
They will call out each person in the slot on the calendar and verify that
the person is present for the deployment. Then they will go through the
deployments, typically in the order listed on the calendar. This may
be shuffled around if folks are waiting for patches to merge.
Although the person managing the window can deploy your patch, they are
usually quite happy for you to do it yourself.
* On deploy1001 in /srv/mediawiki-staging/php-your-version, git status and
see what is outstanding. If there are security patches committed locally but
not merged, this is ok. Such patches will be listed first before the top
commit of the branch, and marked as SECURITY in the commit message.
If some extensions have unmerged commits, you can ignore them. IF THERE ARE
OTHER CHANGES NOT MERGED OR NOT COMMITTED, STOP and get advice.
* git log to see what is going on, same as above.
* If all is good, git fetch to pull in your backported changes
* git log to be sure only your change got pulled in; you can specifically
compare your local HEAD to upstream by "git log -p HEAD..@{u}"
* git merge
* If there were unmerged security changes on top, git rebase (no args needed)
* ssh to mwdebugX (not the one with buster), and, as your regular user, scap pull
from any directory; NOTE THAT this does an rsync so it picks up everything in
the directory.
* Verify that your test of the bug or feature does what is expected
* Back on deploy1001, from /srv/mediawiki-staging you can now do
scap sync-file php-version/.../path-to-change.php "message here"
A nice format for the message with the linked gerrit commit and the linked
phab task is available at
https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers
and you should use it! Basically it is this:
'Backport: [[gerrit:GERRIT-NUMBER|COMMIT-MESSAGE (PHABRICATOR-TASK)]]'
* Wait a bit for things not to explode
* Profit!
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL