12.3. Deploying to an Application Server
Jenkins provides plugins to help you deploy your application to a number of commonly-used application
servers. The Deploy plugin lets you deploy to Tomcat, JBoss, and GlassFish. And the Deploy Websphere
plugin tries to cater for the particularities of IBM WebSphere Application Server.
For other application servers, you will typically have to integrate the deployment process into your build
scripts, or resort to custom scripts to deploy your application. For other languages, too, your deployment
process will vary, but it will often involve some use of shell scripting. For example, for a Ruby on Rails
application, you may use a tool like Capistrano or Chef, or simply a shell script. For a PHP application,
an FTP or SCP file transfer may suffice.
Let’s first look at some strategies for deploying your Java applications to an application server.
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. 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. Deploying a Java Application
In this section we will look at an example of how to deploy your Java web or JEE application to an
application server such as Tomcat, JBoss, or GlassFish.
One of the fundamental principles of automated deployment is to reuse your binaries. It is inefficient,
and potentially unreliable, to rebuild your application during the deployment process. Indeed, imagine
that you run a series of unit and integration tests against a particular version of your application, before
deploying it to a test environment for further testing. If you rebuild the binary before deploying it to the
test environment, the source code may have changed since the original revision, which means you may
not know exactly what you are deploying.
A more efficient process is to reuse the binaries generated by a previous build. For example, you may
configure a build job to run unit and integration tests before generating a deployable binary file (typically
a WAR or EAR file). You can do this very effectively using the Copy Artifact plugin (see Section 10.7.2,
“Copying Artifacts”). This plugin lets you copy an artifact from another build job workspace into
the current build job workspace. This, when combined with a normal build trigger or with the Build
Promotion plugin, lets you deploy precisely the binary file that you built and tested in the previous phase.
This approach does put some constraints on the way you build your application. In particular, any
environment-specific configuration must be externalized to the application; JDBC connections or other
such configuration details should not be defined in configuration files embedded in your WAR file, for
example, but rather be defined using JDNI or in an externalized properties file. If this is not the case, you