DZone
DevOps Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > DevOps Zone > Grails & Hudson Part 4: Automated Deployment

Grails & Hudson Part 4: Automated Deployment

Robin Bramley user avatar by
Robin Bramley
·
Dec. 18, 11 · DevOps Zone · Interview
Like (0)
Save
Tweet
10.65K Views

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):

  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/


Hudson (software) Grail (web browser)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Pub/Sub Design Pattern in .NET Distributed Cache
  • What Are the Best Performance Tuning Strategies for Your SQL Server Indexes?
  • Python Class Attribute: Class Attribute vs. Instance Attribute
  • PermGen and Metaspace

Comments

DevOps Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo