Grails & Hudson Part 4: Automated Deployment
Join the DZone community and get the full member experience.
Join For Free
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):
- from the main hudson dashboard, click on the “manage hudson” menu item
- click on “manage plugins”
- go to the available tab, find & select deploy , click on the install button.
-
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.
-
set the version number using a hudson variable:
“set-version 1.0.0.${env['build_number']}”
-
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/
Opinions expressed by DZone contributors are their own.
Comments