Continuous Delivery

Advertisements

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.

Release Engineering 101 – Build Script

Each software platform will provide a way to write a script and invoke a sequence of build steps Unix shell scripts, make files, windows batch files etc can be used to define a build script.

A framework / tool like ANT, helps in abstracting the script from a platform dependency and use simple XML file to define the build script.
Interestingly ANT itself is only a XML notation, that defines the sequence of steps. The steps themselves rely on the code base, framework binaries, SDK binaries etc.
In summary using any suitable syntax a build script should be defined. The script itself should automate the sequence of steps that needs to be executed to create a single unit of software.