Next, we use the Deploy plugin to deploy the WAR file to the test server. Of course it is generally
possible, and not too difficult, to write a hand-rolled deployment script to get your application on to
your application server. In some cases, this may be your only option. However, if a Jenkins plugin
exists for your application server, it can simplify things considerably to use it. If you are deploying to
Tomcat, JBoss, or GlassFish, the Deploy plugin may work for you. This plugin uses Cargo to connect
to your application server and deploy (or redeploy) your application. Just select the target server type,
and specify the server’s URL along with the username and password of a user with deployment rights
(see Figure 12.3, “Deploying to Tomcat using the Deploy Plugin”).
Figure 12.3. Deploying to Tomcat using the Deploy Plugin
This is known as a hot-deploy, where the application is deployed onto a running server. This is generally
a fast and efficient way of getting your application online, and should be the preferred solution because
of its speed convenience. However, depending on your application and on your application server,
this approach has been known to result in memory leaks or resource locking issues—older versions of
Tomcat, for example, were particularly well-known for this. If you run into this sort of issue, you may
have to force the application to restart after each deployment, or possibly schedule a nightly restart of
the application server on your test machine.
12.3.1.2. Redeploying a specific version
When you deploy your application automatically or continually, it becomes of critical importance to
precisely identify the version of the application currently deployed. There are a several ways you can
do this, which vary essentially in the role Jenkins plays in the build/deployment architecture.
Some teams use Jenkins as the central place of truth, where artifacts are both built and stored for future
reference. If you store your deployable artifacts on Jenkins, then it may make perfect sense to deploy
your artifacts directly from your Jenkins instance. This is not hard to do: in the next section we will look
at how to do this using a combination of the Copy Artifacts, Deploy, and Parameterized Trigger plugins.
Alternatively, if you are using an Enterprise repository such as Nexus or Artifactory to store your
artifacts, then this repository should act as the central point of reference: Jenkins should build and deploy
artifacts to your central repository, and then deploy them from there. This is typically the case if you
are using Maven as your build tool, but teams using tools like Gradle or Ivy may also use this approach.
Repository managers such as Nexus and Artifactory, particularly in their commercial editions, make
this strategy easier to implement by providing features such as build promotion and staging repositories
that help you manage the release state of your artifacts.
Let’s look at how you might implement each of these strategies using Jenkins.