A similar approach can be used for deployable artifacts such as WAR or EAR files—they are built
and tested on the CI server, then automatically deployed to the Enterprise Repository, often as part of
a build pipeline involving automated tests and quality checks (see Section 10.7, “Build Pipelines and
Promotions”). SNAPSHOT versions are typically deployed to a test server for automated and/or manual
testing, in order to decide whether a version is ready to be officially released.
The exact strategy used to decide when a release version is to be created, and how it is deployed, varies
greatly from one organization. For example, some teams prefer a formal release at the end of each
iteration or sprint, with a well-defined version number and corresponding set of release notes that is
distributed to QA teams for further testing. When a particular version gets the go-ahead from QA, it
can then be deployed into production. Others, using a more lean approach, prefer to cut a new release
whenever a new feature or bug fix is ready to be deployed. If a team is particularly confident in their
automated tests and code quality checks, it may even be possible to automate this process completely,
generating and releasing a new version either periodically (say every night) or whenever new changes
are committed.
There are many ways to implement this sort of strategy. In the rest of this section, we will see how
to do it using a conventional multimodule Maven project. Our sample project is a web application
called gameoflife, consisting of three modules: gameoflife-core, gameoflife-services and
gameoflife-web. The gameoflife-web module produces a WAR file that includes JAR files from
the other two modules. It is this WAR file that we want to deploy:
tuatara:gameoflife johnsmart$ ls -l
total 32
drwxr-xr-x 16 johnsmart staff 544 16 May 09:58 gameoflife-core
drwxr-xr-x 8 johnsmart staff 272 4 May 18:12 gameoflife-deploy
drwxr-xr-x 8 johnsmart staff 272 16 May 09:58 gameoflife-services
drwxr-xr-x 15 johnsmart staff 510 16 May 09:58 gameoflife-web
-rw-r--r--@ 1 johnsmart staff 12182 4 May 18:07 pom.xmlEarlier on in this chapter we saw how to use the Deploy plugin to deploy a WAR file generated by the
current build job to an application server. What we want to do now is to deploy an arbitrary version of
the WAR file to an application server.
In Section 10.7.1, “Managing Maven Releases with the M2Release Plugin”, we discussed how to
configure Jenkins to invoke the Maven Release Plugin to generate a formal release version of an
application. The first step of the deployment process starts here, so we will assume that this has been
configured and that a few releases have already been deployed to our Enterprise Repository Manager.
The next step involves creating a dedicated project to manage the deployment process. This project will
be a standard Maven project.
The first thing you need to do is to set up a dedicated deployment project. In its simplest form, this
project will simply fetch the requested version of your WAR file from your enterprise repository to
be deployed by Jenkins. In the following pom.xml file, we use the maven-war-plugin to fetch a
specified version of the gameoflife-web WAR file from our enterprise repository. The version we
want is specified in the target.version property: