This page is currently a draft.
More information and discussion about changes to this draft on the talk page.
Sometimes, something is broken in production, and it needs fixing right now, even though deployments aren't happening right now. Maybe there's a deployment freeze on, or it's at night, over a weekend or holiday, or the deployment train is broken. In these cases, you need to make an emergency deployment.
To do so, you should check in IRC and get positive confirmation from both Release Engineering and SRE, and perhaps other specialist teams as well (such as Security) and carry out the deployment with them.
- Rollback first, fix later; maintaining an overall service to our users is the most important focus.
- Prioritise general availability over that of new features; we have a billion readers and only a few users of your new tool, no matter how cool.
- Make on-wiki edits rarely, and only when you really have to; each wiki's editing community expects autonomy.
Example reasons we have needed an emergency release:
- Address security issues
- For example, a mis-configuration once meant that a private wiki and all of its content was accidentally made public.
- Avoid data loss / corruption
- For example, a coding error meant that newly-painted pages were being cached in a corrupted form; the longer it went, the more of the site was wrong.
- Maintain availability
- For example, a new feature proved much more popular than planned and the extra load it was causing was threatening to take down the site, so it was temporarily disabled over a holiday, until people were back at work.
- Prevent abuse
- For example, a massive content scraping run from a search engine wasn't responding to automated HTTP 429 speed bumps and so had to be manually blocked until they could adjust their code.