Introducing CI to a Fresh Grails Project
Introducing CI to a Fresh Grails Project
A quick tutorial on implementing a CI solution with a Grails project, adaptable to any language or framework.
Join the DZone community and get the full member experience.Join For Free
The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.
Let's talk a little bit about introducing Continuous Integration (CI) to a fresh project. More specifically, I will talk about small projects where a developer has to find a solution by himself. If possible, the best case solution should be free. For this post, I will talk about a CI solution for a Grails project, but it can be very easily adapted to any language or framework.
My Project Choices
My project is using BitButcket as VCS.
Next, I needed a build platform. I decided to use Codeship, which is free (until you want parallel builds).
Finally, the last thing is hosting. In my case, I was looking for Java hosting to be able to run a Grails application. I started with Heroku, but soon I realized that there are very strict limits on database size, so I switched to Openshift and it suits me for my pet projects. Openshift also (as Heroku) gives you a free account with 3 engines for you applications, and you can use 1Gb free for your MySQL DB.
Let's start with Codeship. Link it to your VCS system (My Account -> Connected Services) and create a new project (choose a repository and branch to build).
Create a new project within Openshift. In the case of Grails, I have chosen Tomcat 7 (JBoss EWS 2.0) cartridge. In the settings of the Openshift account, add new SSH-RSA key and fill its content with Codeship ssh key (Project Settings->General->SSH public key). Now, Codeship could connect to Openshift for deploying of artifacts.
At this point, the test, build and deploy phases should be configured at Codeship. I was using Gradle as build tool with Gradle Wrapper, so my test and deploy phase script (Project Settings->Test):
./gradlew test ./gradlew assemble
In the case of Maven, just use
mvn <step name>.
Deployment to Openshift was a little bit tricky. Every Openshift has its own Git repository, where you commit code or artifacts and Openshift hooks will do all the rest for you (build, put artifacts in a correct directory, and restart containers). However, I want to avoid rebuilding, since there are problems with building an application directly on an Openshift box due to limits with RAM (if we are talking about a free account). In my case, I tried to commit the WAR-file that was produced by Codeship directly in the Git repository on Openshift. This process would work without any issues... for 4-5 builds. Then, during checkout of the Git repository, Openshift did not have enough memory to pack the Git repository with some huge WARs (about 100 Mb each).
The new solution is to make deployment as simple as it could be: use
scp command to copy a new .war directly in the
webapps Tomcat directory on Openshift. This approach works perfectly. Copy ssh user and host for the Git repository on Openshift (on a page of the Openshift project you can find the full path which looks like:
ssh://<some_hash>@project_name-acc_name.rhcloud.com/~/git/project_name.git/, but you only need
<some_hash>@project_name-acc_name.rhcloud.com). Using a Codeship script (Project Settings->Deployment) to deploy WAR file in case of Grails we get this:
scp -rp /home/rof/src/<codeship_account>/<codeship_project>/webapps/ROOT.war <some_hash>@project_name-acc_name.rhcloud.com:~/app-root/dependencies/jbossews/webapps/
Now, every time I make a commit to VCS, Codeship prepares the WAR file and performs the deployment to Openshift. Two minutes later I can see a new version of a web application running.
Published at DZone with permission of Ivan Zerin , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.