Release Management using Maven

Release Management is a serious business, no doubt! You can have the best development processes in place to build robust applications or you may have bug-free n-tier changes signed off and ready for roll-out, and yet if something goes wrong during the roll out process, critical systems may end up malfunctioning or worse, stay down for extending periods of time because of lengthy roll back procedures with potential consequences to the profitability and reputation.

Therefore, mechanisms that enable the seamless integration of development work into shippable builds that are also stored into a persistent area for quick roll back, are becoming increasingly critical for Release Managers. In this article, we will take a look in Maven one of the most popular tools that serves this process, as well as Archiva, a local repository for storing builds and their corresponding source code.

software

What is Maven – a refresher

Maven is an Apache initiative that provides a standard mechanism for building application projects. In particular, as Apache states, it aims at:

  •     Making the build process easy
  •     Providing a uniform build system
  •     Providing quality project information
  •     Providing guidelines for best practices development
  •     Allowing transparent migration to new features

In my long experience with Maven I concur that it does deliver with regards to the above on every single count! In a future article I will go through more in detail on the various aspects regarding its use and benefits. However, here I want to focus more on the release management side of things.

How it serves the Release Management

Now let’s get to the nitty-gritty of what Maven can do for a Release Manager through a case study. In this instance I will use Eclipse, a Java project and SVN as source control. But you can do this from a command line (if that rocks your boat…) or from other IDEs (e.g. NetBeans).

The scenario

For the upcoming UAT of an Internet Banking’s latest version, the Release Manager must build a release candidate. The Eclipse project of the Internet Banking Application has been created as a Maven project and thus it can take advantage of all the features that the Eclipse/Maven integration offers: downloading the dependency libraries from the Maven repository (thus no need to store them in the source control), the POM file (see below), right click to execute the most popular Maven commands (clean, build, install etc.)

The global team has confirmed the commit of all their changes to the trunk. So the Release Manager goes ahead checking out the project in Eclipse and creates a tag (you can do this in Eclipse, Tortoise, command line or anything else you fancy. I will come back in a future article regarding best practices on tagging, branching and continuous integration).

Now our friend is ready for the next stage, that is building the release candidate.

Configuring the Maven Descriptor (POM file)

The first step is to parametrize the build process. This is done in the Project Maven descriptor,  the famous POM file. Let’s see what it looks like:

 

  • The section at the top refers to the description of the artefact (the build) to be created. It will effectively create a war file named internetbanking-13.1.24.1.war and the file contained in the folder /com/mybestbank/webapp/internetbanking/13.1.24.1.
  • The Properties section contains a number of variables to be used by maven. We’ll talk about it in a minute.
  • The Dependencies section contains a number of library dependencies (e.g. Spring MVC in this case).
  • The Build part contains directives related to the build itself
  • The Repositories section tells Maven where else to look for the dependency libraries (any additional download URLs)
  • Finally, the distributionManagement section instructs Maven what online repository to use to persist the artefacts (i.e. the release candidate build in our case). We will talk about this cool feature a bit further down.

Let’s take a closer look to the Build section. We want to do the following:

  • We need to declare where the source code is and any additional resources that contain Maven tags (more of this in a minute)
  • Use the Maven code compiler plugin (maven-compiler-plugin) and define the Java version compatibility (e.g. 1.5).
  • Along with the binary code (war file) we want to package the corresponding source code, so we need to use the related Maven plugin (maven-source-plugin).
  • Use the Maven plugin maven-resources-plugin that will look into the resources mentioned earlier for tags that will replace dynamically with text we define in the parameters section. This way for example, in a resource file containing the tag ${pom.version}, this string will be replaced by the contents of the version tag in the POM i.e. 13.1.24.1. Also if it contains the tag ${timestamp} it will be replaced by the POM tag <timestamp> i.e. the date/time the build was created/

Below is how all the above adds up:

Implicitly, our Maven project will integrate a few additional plugins but one that is really handy is the maven-surefire-plugin that will execute any JUnit tests you have in the code. If our developers have integrated code that causes a compilation time error, the release manager will find out before the deployment to the target server when it is too late (Ideally, of course, with continuous integration techniques you can find out before this even arrives to the release manager. I will talk about continuous integration in one of my next articles).

Building the project

Ok, so now the Release Manager is ready to build the project and install in the local repository (this is the default setup) which lies inside the .m2 folder in your home directory (both in UNIX and Windows). In Eclipse this is right click Project => Run As => Maven Install. The output looks like this:

The above output informs that the build was successful and that 3 artefacts were created:

  • internetbanking-13.1.24.1.war (our war file)
  • internetbanking-13.1.24.1.pom (the perpetual pom file)
  • internetbanking-13.1.24.1-sources.jar (a jar that contains the java code)

Deploying the project

So now the Release Manager has now the release candidate build (i.e. the war file) and they are ready to deploy it.

For this purpose, Maven provides a cool feature that enables the deployment to a remote server to be run as part of a deploy maven goal. In Eclipse you do right click Project => Run Configurations => right click on Maven on the left hand side => New. In the popup dialog simply name the Configuration, select the Base directory and as Goals select “deploy” => Apply.

Before we run the deploy we need some additional configuration in the POM file. See the below.

The above configuration uses the wagon-ssh-external plugin to enable the scp unix command (we are assuming that you run everything on a UNIX-flavour. There are similar configurations for Windows using FTP). Notice that the war file is deployed in the Tomcat’s webapps folder so in theory if the right setup has been done on the Tomcat’s site there will be a hot-deploy (whether you want this on a prod machine this is a different story). We could also, instead, have the file deployed to a staging folder and a batch job would run to deploy it gracefully to tomcat.

Now the Release Manager can run the deploy selecting Project => Run Configurations => Maven => Your configuration => Run

Archiva – Persisting the build to a local Maven server

Our release manager is now happy that the build is deployed BUT there is tiny little thing bothering them. The copy of the build and the corresponding java source code jar are locally to their PC. How great it would be if they can be uploaded to a shared server so everyone can have access ideally like a local Maven repository

Apache provides its own Maven server distribution called Archiva that can be downloaded and installed to the local Intranet.It is very easy to install so just follow the instructions

For the build to be deployed there too we need a small change to the pom file:

We added a small section about archiva and the upload URL.You will also need to setup your settings.cml file in the .m2 folder in your home directory:

The above will enable the login to the Archiva repository for the non-interactive (i.e. automated) upload).

Once the deploy runs again not only we have the war in the application server machine but also persisted in a local repository along with its code. Two birds with one stone (a right click more like…) !!!

In the case of our scenario, the file would be accessible to view on:

 

Conclusion

As we have seen in this article Maven can be a powerful tool in the hands of a Release Manager. One could summarize that with Maven the roll out is ultimately one click away ! Virtually no manual intervention thus minimizing the intrinsic risks that a release has. Maven has numerous other cool features that a release manager can leverage (e.g. tag the builds as snapshots, continuous integration etc.). It is therefore providing massive flexibility to fit to the strategy that the Release Manager in coordination with the Development Manager wish to implement in their Team.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.