Grails Tips: Deployment Tricks

Post by Josh Reed

I’m often working with several versions of a project deployed across a variety of deployment environments. Grails makes it easy to manage all of the configuration for these environments, and also allows you to switch the environment at deployment time by setting a JVM property. However, in our lower environments we’re sharing servers between multiple projects so setting a blanket environment isn’t always possible. On more than one occasion I’ve found myself wondering which environment a particular WAR file was configured for. By default, the WAR file generated by Grails is named after the app name and the app version e.g., supercoolapp-0.5.war, but a minor tweak to your BuildConfig.groovy file will add the environment to filename:


After getting the correct WAR file deployed, the next challenge is identifying the version of code running if/when bugs are found. Grails has a built-in mechanism for versioning which works well when I remember to actually use it. And unless you’re setting a new, unique version after each change, the version won’t tell you exactly what code is running. Fortunately, Git gives us an easy and automatic way to identify the code–commit hashes. The only trick is getting the hash into the app so it can be displayed. To accomplish this, we can hook into the Grails event model to ask Git for the current commit hash at compile time. Create a scripts/_Events.groovy file with the following contents:

eventCompileStart = { msg ->
  new File("grails-app/views/_git.gsp").text = ("git rev-parse HEAD".execute().text)

This will put the latest Git commit hash into a GSP template called _git.gsp which you can include on any page in your app. I’ll generally put this in the footer of the main layout, either visible or commented out, so it is on every page. You’ll want to add _git.gsp to your .gitignore file since it will change frequently.

Hopefully these two little tricks will make working with your Grails apps across different deployment environments a little bit easier.

This entry was posted in Agile Processes, Software Development and tagged , , . Bookmark the permalink.

Related Posts:

6 Responses to Grails Tips: Deployment Tricks

  1. Mike Hugo says:

    Nice post! You can also try out the build info plugin which captures the svn or git revision number when the war is built and adds a controller at /buildInfo that display that plus a bunch of additional information.

  2. Josh Reed says:

    Thanks for the heads up, Mike. Looks like a great plugin and easier than doing the _Events.groovy for each project.

  3. Eric Berry says:

    Awesome post! These are both items I was hoping to figure out. Keep me coming!

  4. Pingback: Questa settimana in Grails (2012-19) - - Il blog di Luca Canducci: notizie, tips e nuove tecnologie dal mondo dell’IT.

  5. Erik Pragt says:

    Interesting post and a good writeup! Just one question though: how about just having 1 war and externalize all configuration instead? This way you only have to manage one war, and don’t worry to much about where it’s deployed. This also has the advantage of not having production credentials in your war file.

  6. Josh Reed says:

    Hey Erik, thanks for the comment. Externalizing the configs is another great option, especially if you’re working in a fairly homogenous environment for deployment so your external locations are the same. I think you’d still have to be careful with your permissions regardless of whether they are in the war file or external location if you are worried about people accessing your credentials.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>