Creating Proxy Releases (release management)

Last updated: January, 2011

This is a description on how to create and deploy releases for the proxy application. The procedure is guided by the limited resources available for this project. The aim is to rapidly deploy releases with a minimal amount of resources, while ensuring the overall quality of the project.

The Proxy application consists primarily of Java code and third party Java libraries. It is dependent of two other applications: Java and Tomcat. The Java code and third party library versions are managed within SVN. As the Java and Tomcat versions do not change that frequently a typically Proxy release consists of an SVN revision number.

The proxy project has limited manpower and the different proxy instances (testing and production) run on one server (with another server for failover purposes). The size of the code base and its dependencies is also limited. As a result there is no generic package builder and tester (e.g. Hudson) that enables you to create one installer to deploy the proxy application on different servers.

Deploy/Building Release

The proxy server contains a so-called release environment. Each proxy instance on the proxy server is represented by a different (linux) user. The release environment contains an initialize.sh script to deploy new proxy applications. This initialize.sh script (after creating a new user) enables to quickly setup a deployment environment for a new proxy.

Each proxy instance home directory contains several files and directories:

  • bin (directory). Contains the deployment environment and a collection of symbolic links that point to several scripts used by all the proxies (start,stop, reset, configuration management, etc..)
  • config.xml. The proxy config file
  • java . Symbolic link to java version used by this proxy instance
  • tomcat. Symbolic link to tomcat version used by this proxy instance
  • mamproxy. Symbolic link to version of proxy used by this proxy instance.
If you need to update an existing proxy instance to a new version (which is not yet used by other proxy instances): aka "deploy a new proxy release" do the following:
  • In the /dalet/proxymaster/mamproxy directory create a directory for the new proxy release based on the version number (major_minor_bug). E.g. mamproxy_1_6_5
  • In this directory checkout the correct SVN revision number that corresponds to this release. Notice that we do not create any release within SVN. The SVN is hosted remotely and part of the integrated ticketing/wiki environment JIRA. Each SVN release would make a copy of not only the source code but also the third party libraries that are under revision control, resulting in an SVN repository that would grow rapidly in size and the risk of paying for additional storage to host this SVN repository. We do keep a mapping between our versions and SVN revisions which is sufficient for our purposes.
  • In the home directory of the proxy instance that you want to update to this new version, rename the mamproxy symbolic link to the version it points. Doing this consistently gives us a version history per proxy instance and allows us to rollback to a previous version in case of problems.
  • Within the home directory of the proxy instance that we want to update, create a new mamproxy symbolic link that points to the new SVN release that has been checked out (e.g. /dalet/proxymaster/mamproxy/mamproxy_1_6_5)
  • Build the new release by doing the following in the home directory of the proxy instance:
    • source bin/setup.sh
    • cd mamproxy/MAM
    • source setup.sh
    • cd proxy
    • ant jar
  • In the bin director execute the script ./stop_proxy.sh which will stop the proxy instance
  • Assuming that the config.xml file has been updated to reflect this new version do ./start_proxy.sh in this same bin directory
  • The start_proxy.sh automatically tails the log file so you can check for any exceptions due to deploying this new version.

Creating Release Notes

The last step of making a new release is to compile the release notes. Release notes are an aggregation of SVN commit comments from the developers between two consecutive versions. The quality of the release notes depends on the quality of the comments made by the developers. Developers should (when they commit) in their comment specify to which ticket(s) this change/update in the source code relates to, as the ticket contains a detailed description and allows quality control and managers to correlate the release notes with the actual work defined in the tickets.

  • Do an "svn log > svnlog.txt" in the directory where you checkout the SVN revision.
  • Edit the svn_release_notes.py script. This script contains a mapping between the proxy versions and the SVN releases.
  • Add to the rel2svn dictionary the mapping from the proxy version to the corresponding SVN release number
  • In the start_end array specify what release notes we want to generated. Usually you want to generate release notes of a version relative to the previous version. In our example it would be something like this: start_end = [ ("1_6_4","1_6_5") ]
  • Run the svn_release_notes.py script (make sure it points to the svnlog.txt file), which creates a file called: release_1_6_5.txt . This file contains all the comments made by the developers during SVN commits between version 1_6_4 and 1_6_5 and includes the SVN revision number.
  • Publish the release_1_6_5.txt to the web server that contains all information of every proxy software release by copying it to: /var/www/html/proxy/releases/