You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org
- Ask for a little more time than what you think you'll need for deployment and testing; you never know what issues may come up and slow you down.
- Generally, we have found one hour to be a good size for most things.
- Deployment windows are 'pinned' to the time in San Francisco and thus the UTC time will change due to the United States observance of Daylight Savings Time as appropriate.
- SWAT deploys are for pushing out simple and low-risk changes (as assessed by you, SWAT team, and the Release Manager). They happen at:
- 06:00, 11:00 and 16:00 Pacific on Mondays and Thursdays
- 06:00 and 16:00 Pacific on Tuesdays
- 06:00, 10:00 and 16:00 Pacific on Wednesdays
For detailed instructions on how to actually deploy code to the Wikimedia servers, see How to deploy code.
This page tracks planned deployments of software to the Wikimedia Foundation servers that host the various Wikimedia projects (Wikipedia, Wiktionary, Wikiversity, Wikimedia Commons, etc.).
- The Wikimedia Foundation currently follows a one-week deploy cadence. This means that there is one week between updates to any one Wikimedia project site wiki (excluding urgent fixes, of course).
- To schedule a deploy window, or if you see a potential conflict with your upcoming deployment, please e-mail Greg Grossmeier.
- Inclusion criteria
- See the list at Inclusion criteria for the kinds of changes that require scheduling here.
- Long running tasks/scripts
- While not strictly a deployment, performing long running (>1 hour) tasks (eg: migration scripts) can encounter issues when code is updated while a script is being run. For this reason it is required to add an entry in the calendar for the task with a window that accounts for the anticipated start time and estimated length for the task.
- Every major or new feature deployment should be announced on the Wikimedia blog and/or Tech News (use the "user-notice" tag on Phabricator) and/or global on-wiki delivery. For routine and maintenance deployments, listing your change here is enough.
- Changes that are liable to affect site performance or infrastructure should be announced on the ops mailing list. This includes anything that alters caching behavior, introduces cookies, substantially increases the static asset payload, or adds new and complicated query patterns.
- Something went wrong‽ (see also Incident response)
- Is there a user-impacting or other severe issue?
- What happens next?
NOTE: You can also subscribe to the "WMF Deployments" google calendar by adding <email@example.com>. This does not always get one-off windows that are noted below. This wiki page is the canonical deployment schedule and any differences with the google calendar are to be interpreted as the google calendar being incorrect.