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.

One Perspective on Improved Software Quality and Reduced Risks

We talk endlessly about improved software quality and reduced risks, but deployable software is the most tangible asset to “outsiders”
such as clients or users. The importance of this point cannot be overstated.