Release Engineering 101 – Using Version Control System (Subversion)

Subversion has a few interesting ways of managing releases. The obvious one is the revision number – you committed revision 1234 to Subversion from your local workstation, then you “exported” revision 1234 to Dev, tested, signed off, and as a final step (once you’re happy with your testing) you export revision 1234 to the QA machine. (The process then repeats, but with different testers/QA people, and with UA -> Production instead of Dev -> UA).

A more robust approach, however, would be for you to create “tags” (tags are simply copies) – you committed revision 1234 to Subversion, but 1234 is a but of a mouthful. It’d be nicer if there was an easier, clearer way to refer to the code you’re interesting in testing. What you’d do is copy your existing code tree to a new directory, e.g. from /trunk/ to /tags/tag-2010-01-11_1500. Since tags (all copies, in fact) are in Subversion you may find you create tags frequently – /tags/build-2010-01-11_1600, /tags/releases-v1.2.3. Tags can be exported to Dev, QA and Production machines just as easily (if not more easily) than revisions.