Difference between revisions of "Code push"
m (→Check for pushability) |
(resectioning and prep for additions) |
||
| Line 3: | Line 3: | ||
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. | 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== | + | == To do in advance of the push == |
| + | |||
| + | === 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, Mark, or Kareila a few hours in advance to see if there are any pull requests in the review queue that should go into the release for business reasons. | 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, Mark, or Kareila a few hours in advance to see if there are any pull requests in the review queue that should go into the release for business reasons. | ||
| − | == | + | === Announce in <dwcomm>dw_maintenance</dwcomm> that a code push is scheduled === |
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. Add a link to <a href="http://www.timeanddate.com/worldclock/fixedform.html">Time and Date's Event Time Announcer</a>. | 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. Add a link to <a href="http://www.timeanddate.com/worldclock/fixedform.html">Time and Date's Event Time Announcer</a>. | ||
| − | == Update Twitter == | + | == Preparing to push == |
| + | |||
| + | === Update Twitter === | ||
Update the @dreamwidth Twitter account when beginning the push to let people know the push is starting. | Update the @dreamwidth Twitter account when beginning the push to let people know the push is starting. | ||
| − | == Update dw_maintenance | + | === Update <dwcomm>dw_maintenance</dwcomm> === |
When beginning the push, update <dwcomm>dw_maintenance</dwcomm> again to announce that it's starting. Include a downtime estimate, with an extra 20% or so added on top for unexpected problems. | When beginning the push, update <dwcomm>dw_maintenance</dwcomm> 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 == | + | === Do technical magic === |
| − | == Spot-check the push == | + | === Spot-check the push === |
Inform the #dw-dev 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. | Inform the #dw-dev 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. | ||
| − | == | + | ==After the push is complete == |
| − | + | ||
| − | + | ||
| − | == Update the dw_maintenance entry == | + | === Update the dw_maintenance entry === |
Edit the <dwcomm>dw-maintenance</dwcomm> 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. | Edit the <dwcomm>dw-maintenance</dwcomm> 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. | ||
| − | == Update Twitter account == | + | === Update Twitter account === |
| − | + | If needed, update the Twitter account again to let people know the push is complete, and that any problems should go to Support or <dwcomm>dw-maintenance</dwcomm>. | |
| − | == Monitor <dwcomm>dw-maintenance</dwcomm> entry for a few hours == | + | === Monitor <dwcomm>dw-maintenance</dwcomm> entry for a few hours === |
| − | + | Make sure someone can stay available for a few hours as <dwcomm>dw_maintenance</dwcomm> 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 or Kareila will handle that.) | |
| − | == | + | === Commit any needed fixes on the release branch === |
| − | If there is a secondary push to resolve bugs, | + | If there is a secondary push to resolve bugs, these commits should go directly on the release branch. The hotfixes will be merged back to the develop branch before the next push. |
Revision as of 14:44, 6 December 2015
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.
To do in advance of the push
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, Mark, or Kareila a few hours in advance to see if there are any pull requests in the review queue that should go into the release for business reasons.
Announce in ![[info]](http://wiki.dreamwidth.net/wiki/extensions/LJ/images//dw/user.png)
dw_maintenance that a code push is scheduled
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. Add a link to <a href="http://www.timeanddate.com/worldclock/fixedform.html">Time and Date's Event Time Announcer</a>.
Preparing to push
Update Twitter
Update the @dreamwidth Twitter account when beginning the push to let people know the push is starting.
Update dw_maintenance
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-dev 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.
After the push is complete
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.
Update Twitter account
If needed, update the Twitter account again to let people know the push is complete, and that any problems should go to Support or dw-maintenance.
Monitor dw-maintenance entry for a few hours
Make sure someone can 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 or Kareila will handle that.)
Commit any needed fixes on the release branch
If there is a secondary push to resolve bugs, these commits should go directly on the release branch. The hotfixes will be merged back to the develop branch before the next push.
