The Grails framework has reached maturity with the recent release of its 1.0 version. As Grails is becoming increasingly popular and more and more enterprise applications based on Grails started appearing, I believe that Grails developers deserve the same level of tool support that is available to plain Java developers. This applies not only to IDEs, but also to continuous integration servers. Grails projects' needs for continuous integration don't differ from needs of any other enterprise projects.
TeamCity is a continuous integration server with many unique features, like pre-tested commit, unit and integration testing, integrated test reports, tight IDE (Eclipse, Visual Studio and IntelliJ IDEA) integration, code coverage calculation and reporting, parallel builds, VCS-event-based build triggering and many others. The good news is that most of these features are available to Grails projects as well. In my short series of how-to articles I'll show you how to configure TeamCity to leverage its full power for your Grails applications.
The ultimate goal
First I'll build your appetite with a couple of screenshots from my project build to demonstrate the options you have. We will gradually get to a point when you will be able to get the same screenshots from your own Grails project, I'm sure.
You can quickly navigate to test reports.
And view the reports on-line
The generated war file of your Grails application can be downloaded with a single click
Cobertura code-coverage reports can be generated
And viewed on-line
Canoo webtest report online
How to jump-start your build process.
I assume you are familiar with Grails and TeamCity already.
TeamCity uses a powerfull concept of build agent grid, when the server distributes builds to any available build agent in the network, which is compatible with the build requirements. As Grails applications rely on Groovy and Grails installations, you need to install Groovy and Grails on at least one agent so that the agent can build your applications.
Grails projects themselves need to be configured in TeamCity just like any other projects. The only two steps that deserve our attention in this document are choosing a runner and setting agent requirements.
For a quick start I recommend using the command line runner to invoke grails commands directly as this is the easiest way to build Grails applications. The Ant runner is a little bit more demanding on configuration, but gives you many more options in exchange, so I'll cover it in a dedicated post.
Now back to the command-line runner. You specify "grails.bat" on Windows or "grails" on unixs in the Command executable field. In the Command parameters field you need to specify the grails command to invoke and and in the Artifact paths you set the path to files that your command is supposed to generate and you want to gain access to. This works well for war file generation, but for test reports it is not very convenient to have to download multiple report files. We will resolve this issue with later when configuring the Ant runner.
Configure ant runner to build the app and run tests
Configure ant runner to generate a war file.
To enable running Grails app builds only on Grails-compatible agents the following environment variables must be required to be set on the agent for all configurations:
Set the required agent environment properties
Certainly there are limitations compared to Java projects. For example, the test or webtest reports are not integrated into TeamCity and you have to retrieve them manually as project artifacts. Code coverage is also not supported for the command line runner. In the next article I'll cover the Ant runner, which will help us easily overcome these issues.