Difference between revisions of "Code push"

Revision as of 03:59, 24 July 2010

The checklist for updating the code running on the live "dreamwidth.org" production site to the most recent version of the code. Admins of other installations will most likely need to alter this checklist based on your site's unique needs.

Check for pushability

Code pushes can be requested for business reasons or by members of the dev team, but the admin doing the push should take a few minutes to check over what will be pushed to make sure all patches are complete and in a releasable state. Before a push, check with Denise a few hours in advance to see if there are any patches in the review queue that should go into the release for business reasons.

Update dw_maintenance in advance

Ideally, the comm should be updated a day or so in advance to let people know the timing of the push; at the very least it should be a few hours' notice. Give times in your local timezone and in GMT, and be sure to include the timezone information.

Update Twitter

Update the @dreamwidth Twitter account when beginning the push to let people know the push is starting.

Update dw_maintenance when beginning

When beginning the push, update dw_maintenance again to announce that it's starting. Include a downtime estimate, with an extra 20% or so added on top for unexpected problems.

Do technical magic

Spot-check the push

Inform the #dw-work channel that the push has been completed and the site is back on. Ask them to spot-check a few functions by posting entries, reading their reading page, updating settings, etc. Watch the logs for any errors or problems.

Increment repository tags

Increment the tags on any repository that has had commits to it since the last push. Use secondary versions (0.1.0 to 0.2.0, etc)

Update the dw_maintenance entry

Edit the dw-maintenance entry (don't post a new one) with the date/time (in both your local timezone, clearly marked, and in GMT) with a notice that the push has been completed. Let them know that if they spot any issues, they should contact Support or leave a comment.

Monitor dw-maintenance entry for a few hours

Stay available for a few hours as dw_maintenance comments come in, in case there's a major issue that needs to be resolved with another push. (You don't need to reply to the comments -- Denise will handle that.)

Increment repository tags again (if necessary)

If there is a secondary push to resolve bugs, update the repo tags to a tertiary version (0.1.0 to 0.1.1) after a day or so, when all the issues are resolved. (The day after a code push should remain as a code freeze, for bugfixes with the previous push only.)