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.

Notes on build script

  • Choose a language that can be used in multiple platforms (very important for a Java project)
  • Ensure that as many steps are automated. Begin with a full clean up and allow full build and deployment to the server
  • Automate even server restart to increase developer efficiency
  • Each build should ensure that it recompiles all classes and optionally fetches latest code from the repository
  • Stale references to others code is the most frequent offense among developers. So use the build script to enforce some discipline too
  • While writing a build script, one needs to take care of small short cuts that can help in a faster build and deployment
  • Deploy only HTML and JSP
  • Deploy only compiled java classes
  • Do only a restart
  • Deploy only properties files
  • This is not a default option and one should not spend time at this in the beginning. This is a step more relevant to iterative improvement of the build script
  • 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.