DevOps Zone is brought to you in partnership with:

Robin Bramley is a hands-on Architect who has spent the last decade working with Java, mobile & Open Source across sectors including Financial Services & High Growth / start-ups. Prior to that he helped UK Police Forces with MIS /reporting & intelligence systems. He has contributed to a wide variety of Open Source projects including adding Open ID support to Spring Security. Robin is a DZone MVB and is not an employee of DZone and has posted 24 posts at DZone. You can read more from them at their website. View Full User Profile

Grails & Hudson Part 4: Automated Deployment

12.18.2011
| 8764 views |
  • submit to reddit

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.


Source: http://leanjavaengineering.wordpress.com/2010/12/31/grails-deployment-in-hudson/


Published at DZone with permission of Robin Bramley, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)