Reading/Web/Release manager
Release manager responsibilities:
[edit]All week
[edit]- If there is an e-mail alert, you are responsible for investigating it promptly (ideally within an hour) (or delegating to someone to investigate it) and taking appropriate action (e.g. changing the alert/blocking the train/arranging a backport).
- Alerts can be disruptive to your team mates. Once action has been taken or a Phabricator ticket has been created, silence the alert or change the threshold value. If changing the threshold leave a note in the description detailing what the current threshold is, and what the previous threshold is and point to the Phabricator URL so we can restore the alert after the task has been resolved.
- Alerts are
- Any backports that are needed during the week are your responsibility.
- Please communicate any deployment blockers to the release engineering team that should delay the train as they occur. For example if on Wednesday an UBN is discovered, it's your duty to make sure that doesn't get onto English Wikipedia on Thursday. For example 1.41.0-wmf.14 deployment blockers task is: task T337528
- Chores (you can do these daily but MUST do them on the days as detailed below) The chores page has been reflected with suggested dates @ Release Manager updates
Monday
[edit]- Please let the release engineering team if there are any risky changes they should know about during the train deployment. If you are not sure if there are risky changes, check the board and/or ask your team mates.
- Chore: Visual regressions
- Check Pixel and browser tests
- Pixel should show 0 regressions by the end of Monday either by tagging expected regressions or fixing/reverting unexpected regressions. Consider instigating a code-freeze if the error rate is high.
- To tag expected regressions you must ssh into the Pixel box and update the command like so:
ssh pixel.reading-web-staging.eqiad1.wikimedia.cloud sudo vi /srv/pixel.sh # update the line reference="-b latest-release"Â to be reference="-b latest-release -c <gerrit id of expected regression>"
Wednesday, Thursday, Friday
[edit]- Chore: Logstash Check logstash errors, with a focus on group 0 and 1 wikis. Anything abnormally high would indicate a regression for Thursday. If so, create a ticket and consider making it a deployment blocker or preparing for a Thursday deployment. Check validation errors if any tests are being run.,
- Chore: Review dashboard - Check the triage board for any bugs that may have been filed against the current train and make sure all tasks are in the backlog in preparation for the Thursday grooming session.
- Make sure any UBN tasks have been deployed and that logstash is in a healthy space.
- Check performance / web dashboards for any regressions that may have occurred during the course of the week creating tasks
Friday
[edit]Leave everything in a good state for the next release manager. For example, if there are visual regressions, don't leave them to have to do everything on Monday!