< Back to Webtools

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. If you need it more frequently than that, file a bug on getting the site auto-updated from SVN.

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/)

Tagging for Staging / Production using svn merge

• 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/"

• If possible, it helps to keep track of what your last merge revision was (or you will look it up next time you merge. We throw it into the IRC channel topic just for reference.

Tagging for Staging / Production using svn externals

A downside of using merge is that you can create conflicts/inconsistencies when manually merging a subset of an atomic revision (just a couple files instead of the whole tree).

The alternative is to use svn externals.

The downside and/or "hacky" thing about using externals is that SVN requires a directory to check out a repo path as an external. This makes it sub-optimal if you have lots of single files in your root directory.

Here is a list of steps to tag something using externals:

• Create your tag directory. It has to exist before you set properties on it.

 [clouserw@fattony /data/mozilla.com]$ svn mkdir svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/newtag

• Update or check out this tag.

 [clouserw@fattony /data/mozilla.com]$ svn up

or

 [clouserw@fattony /data/]$ svn co svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/newtag mozilla.com

• Edit your tag properties to change which externals are pulled when it is checked out and updated.

 [clouserw@fattony /data/mozilla.com]$ svn propedit svn:externals .

• This will open your CLI editor (vim/emacs/pico -- whatever you have set in your .subversion/config dir under "editor-cmd") and you can edit which items get pulled. We will use the en-US directory as an example.

en-US -r3491 https://svn.mozilla.org/projects/mozilla.com/trunk/en-US/

• This tells SVN, "when I check out the 'newtag' tag, newtag/en-US will pull https://svn.mozilla.org/projects/mozilla.com/trunk/en-US/, revision 3491".

• At any time if you would want to find out what externals your tag has, you can use this:

svn propget svn:externals https://svn.mozilla.org/mozilla.com/tags/newtag

• Note that mozilla.com is a bad example because it has files floating in the root dir -- README and index.html can't be checked out as externals. So it may not be a good fit for you depending on how your files are laid out. For AMO, however, it fits a bit better because the root directory of the tag just has a simple README with a link to the wiki and two directories that can be easily set up to be externals.

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 revision number of the previous merge, so an easy rollback can occur! Also include any other rollback instructions. You can get the previous revision number by running `svn log` on the production tag.
• Assign the appropriate severity -- note that critical or blocker pages the Mozilla Operation Center (MOC).

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
• Please paste the last line of output into the bug (Should be something like "Updated to revision 15")

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

• If you have the last revision number, substitute it for the "100" here:

[root@do-stage01]$ cd /data/live/www.mozilla.com/
[root@do-stage01]$ svn switch -r 100 svn+ssh://svn.mozilla.org/projects/mozilla.com/tags/production

• If you want to see all the revision numbers you can switch to, try this:

[root@do-stage01]$ cd /data/live/www.mozilla.com/
[root@do-stage01]$ svn log

• When rolling back, don't forget any database/config changes that need to be rolled back