Webtools:SVN Guidelines
UNDER REVIEW! This document is currently under review. Please contact clouserw with input. Once content is verified, this notice will be removed.
Gotchas
- Don't ever submit a log without a description or corresponding bug number (if applicable) -- blank changelogs should not happen
- Talk to your team
- Don't duplicate effort
- Be aware of other patches in progress
- Talk to each other to ensure that your patches won't cause regressions
- Run the usual smoke tests and (ideally) some sort of automated script that can spot SNAFUs immediately
- Don't file IT requests for production updates every hour, and don't email them every 5 minutes (or text-message them either) -- your best bet is to group your updates and push them weekly.
Examples
- Examples on this page assume:
- You're using the command line client over ssh
- You're editing the mozilla.com site - modify as necessary
- You're familiar with SVN, (or at least have read our Introduction)
General Tagging Rules (quick version)
- Staging and production are as close to the same thing as we can make them.
- If production is using vhost blocks in a .conf, staging should too
- Code for both should always be from the same production tag.
- (Programmers should be developing and testing on their own branches, or /trunk/)
- When code is merged into production, a tag is created at the same time with the following format: $description_$datetime, eg. prod_200610241902
Tagging for Staging / Production
- Basic process is: check out production, merge your changes, commit production
- Our example assumes:
- All patches are done and checked into trunk
- You've checked out svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/production to /data/mozilla.com
- The last revision of the production tag is revision 100. This can be found by running `svn info` in /data/mozilla.com/ and looking at the "Last Changed Rev:" line
- The last revision of the trunk is 150. We're using a number here instead of HEAD to avoid having someone commit while you're in the middle of these steps and mess things up
- From the production tag's directory, merge the changes (If you'd like to see what's going to change without actually changing it, add --dry-run)
[clouserw@fattony /data/mozilla.com]$ svn merge -r 100:150 svn+ssh://svn.mozilla.org/projects/mozilla.com/trunk
- Find out the diffs between the production revision and the current head
[clouserw@fattony /data/mozilla.com]$ svn diff -r 100
- When you're SURE that the patches are correct/make sense, you need to commit it (substitute your rev # for 150):
[clouserw@fattony /data/mozilla.com]$ svn commit -m "Merging revisions 100:150 /trunk/ into /tags/production/"
- Then make a snapshot tag for easy reference:
[clouserw@fattony ~]$ svn copy -r 150 svn+ssh://svn.mozilla.org/projects/mozilla.com/trunk svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/prod_`date +%Y%m%d%H%M` -m "Creating snapshot tag of /trunk/ at r150"
When to push
- Only initiate a request if you are sure you are not causing a serious regression
- For major updates, you should contact major parties and discuss the update -- at least briefly -- so they are aware. When in doubt, just email everyone. :)
Requesting an update in production
- File an IT Request when you are sure you are ready to go
- Include in the request the path to the previous snapshot tag, so an easy rollback can occur! Also include any other rollback instructions.
- Assign the appropriate severity -- note that critical or blocker pages the oncall.
Actually pushing updates
- Updating production should be a simple step, and should always be consistent if we follow this procedure:
[root@do-stage01]$ svn up
- Note: If configuration or db changes are required, specify the order and the action in the request bug
After the push
- Always be available after updates are pushed
- Tell the community you have made an update -- blog, planet, etc.
- Keep an eye open for what's going on, file an IT request or page sysadmin for a rollback if necessary
Rolling back
- Sysadmins, if the developer did things right, you should be able to rollback by using:
[root@do-stage01]$ cd /data/live/www.mozilla.com/ [root@do-stage01]$ svn switch svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/prod_<given datetime of revision>
- If you just want whichever is before where you're at, and you don't have a number, you can see them all with:
[root@do-stage01]$ svn ls svn+ssh://svn.mozilla.org/projects/mozilla.com/tags
- Don't forget any database/config changes that need to be rolled back