Grails & Hudson Part 4: Automated Deployment

This is a quick post to describe the steps involved with getting Hudson to deploy a Grails application to a remote Tomcat server.

Tomcat
First up you’ll need to ensure that Tomcat has the manager application installed (e.g. on Debian Lenny the tomcat5.5-admin package on stable) and that $TOMCAT_HOME/conf/tomcat-users.xml has been configured with a manager user e.g.

<tomcat-users>
<user name="admin" password="top_secret_password" roles="admin,manager" />
</tomcat-users>

Note: You can also digest the password & configure the realm to use digest passwords…
Update: see this post.

Hudson
Back in Hudson, you’ll need to install the Deploy plugin.
This follows the same process that we covered in part 2 of this series (we’ll omit the screenshots this time):

  1. From the main Hudson dashboard, click on the “Manage Hudson” menu item
  2. Click on “Manage plugins”
  3. Go to the available tab, find & select Deploy, click on the install button.
  4. When the plugin has downloaded and installed, you will need to restart Hudson (you can use the button provided).

In your Grails job, we need to instruct the Grails builder to package a war file, but first we’ll set the Grails application version number using the Hudson build number for traceability.

  1. Set the version number using a Hudson variable:
    “set-version 1.0.0.${env['BUILD_NUMBER']}”

  2. Build a war (e.g. for a prod war named ggug.war):
    “prod war ggug.war”

The double quotes are required to group the arguments appropriately.

Finally, we’ll instruct Hudson to deploy to a ‘remote’ Tomcat server:

Tips
I’ve used this a lot for automated deployments to pre-production environments (in conjunction with the Grails Autobase plugin). However, for live deployments that require more control I’d typically use the SCP plugin instead and then manually invoke a deployment script (or handle through a configuration management tool e.g. Puppet – see their post on war deployment).

Also, I’ve tended to split the compilation/testing & deployment into two Hudson jobs – this is to separate deployment issues (e.g. Tomcat out of permgen space) from compilation or automated testing failures. If you do this, you’ll probably want the Hudson Next Build Number plugin.

About these ads

7 responses to “Grails & Hudson Part 4: Automated Deployment

  1. Pingback: Grails & Hudson Part 4: Automated Deployment

  2. Pingback: Tweets that mention New blog post - Grails & Hudson Part 4: Automated Deployment: #Grails #Hudsonci -- Topsy.com

  3. Pingback: Grails & Hudson / Jenkins Part 5: Monitoring build status | Lean Java Engineering

  4. Hey,

    thanks for your HowTo’s. They’re really nice!

    For this one I do have a tiny hint: With newer versions of Jenkins the “Non Interactive” checkbox is marked by default which leads to compiling errors with this way of deploying. Therefore it should be disabled!

    Cheers

    Moritz

  5. Hi,
    greet Tutorial! I’ve just red all of your tutorial parts and I was’nt a problem at all to set up my grails hudson job. Nice job! That’s how a tutorial should be written. Compact, straight, without errors! You made my day!

    Greets

    Jonas

  6. Pingback: Automated Deployment by phbree - Pearltrees

  7. Hi,

    We do similar things with jenkins. A compile/test job and a deploy job.
    Here are my tips:
    - we use the parameters in builds a lot to have a single deploy job which has dropdown parameters for the environment to deploy to and the job from which to take the artifact.
    - we have written a relatively simple ant script which uses ssh and have a few simple targets: remote copy, remote stop tomcat, remote start tomcat, remote undeploy. Our deploy in jenkins is simple calling the ant target “remote deploy” which takes a few parameters: the host to deploy to, the artifact to copy, the name of the deployed artifact (might be ROOT.war). This solution has proved very very robust and we have gotten rid of those annoying perm gen space problems.

    Andre

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s