Cruise Control to the rescue
Recently we have been involved in a bit of Java development, using the CMS ‘MagnoliaCMS’. We have not found using this CMS the most enjoyable of experiences. One point of frustration for us was the deployment process. If you are unfamiliar with MagnoliaCMS, it operates with at least 2 instances: 1 author site (where you input the content and test it) and at least 1 public site. The environmental setup we had for this instance was 1 pre production author site, 2 load balanced pre production public sites, 1 live author site, and 2 load balanced live public sites. Because each of these instances has a different repository and SQL server connection they all need to have separate builds made for them. In our setup, we had create build scripts for each of these instances which produced WAR files which could be deployed onto a Tomcat server. Unfortunately each of these builds took about 5 minutes to complete and then after those were created we had to copy them to the off site servers where the preproduction and live sites are hosted. This would take at least a few minutes for the couple hundred MB large WAR files each. Then, if there was a mistake made in the code or a problem with the WAR file we would be in the middle of this long manual process and have to begin from the start again. Not a very enjoyable experience.
Here is what we did to make it better: Used the power of cruise control.
We created a couple of targets for our cruise control project.
- Build
- Deploy
- Build and deploy (just depends on the previous 2)
I will go over our requirements in each step:
1. Build
We needed to be able to get the solution to build on the Cruise Control server. So, what we had to do was install Java JDK and Maven on the CC server as that is the build manager for MagnoliaCMS. We created a batch file which built all the instances:
cd C:\CruiseControlWorkingDirs\JavaSolution\cms
call C:\Maven\bin\mvn clean install -P stageAuthor
call C:\Maven\bin\mvn clean install -P stagePublic1
call C:\Maven\bin\mvn clean install -P stagePublic2
call C:\Maven\bin\mvn clean install -P prodAuthor
call C:\Maven\bin\mvn clean install -P prodPublic1
call C:\Maven\bin\mvn clean install -P prodPublic2
Then, we had to call that batch file from cruise control:
<target name=”build”>
<echo message=”Build All” />
<exec program=”cmd.exe” commandline=”/C C:\CruiseControlWorkingDirs\JavaSolution\builds.bat” />
</target>
What we noticed by building like this rather than through Eclipse, the builds actually took a lot less time (about half) and obviously we didn’t have to click a button to start the next build but it would just rattle through all of them.
2. Deploy
Our next step was to deploy these. However, when I say deploy. It was not actually deploy completely because of the setup of MagnoliaCMS. You can’t deploy MagnoliaCMS through Tomcat like you would another Java site as there are some serious memory leaks in MagnoliaCMS which stay in memory by doing it like this. So, you need to stop the Tomcat service, put the WAR file in the webapps folder, and then start the service again. Because of this needed process and the fact that our client might be working in the author instance and we needed to limit the times when we actually stopped the Tomcat service. We decided that the cruise control deploy process could just upload the files to the servers and then from there it could be a manual process to move the WAR file around and stop and start the Tomcat service.
Our connection to the external servers where preproduction and live instances are deployed are password protected. So, we had to map the drives so that we could put in the username and password. However, we couldn’t always assume that it was going to be connected because of server restarts, etc. So, we created another batch file to do this:
if exist M: net use M: /d
call net use M: \\111.111.111.111\c$ password /user:username
if exist Z: net use Z: /d
call net use Z: \\111.111.111.112\c$ password /user:username
Next, we had to call this batch file and then copy the war files out (I am only showing 3 of the war files being copied as they are all basically the same):
<target name=”deploy”>
<echo message=”Map Drives” />
<exec program=”cmd.exe” commandline=”/C C:\CruiseControlWorkingDirs\JavaSolution\mapDrives.bat” />
<echo message=”Copy Stage Author” />
<copy
file=”C:\MAVEN_TARGET\stage\cms-stage.war”
tofile=”M:\Uploads\stage\cms-stage.war”
overwrite=”true” />
<echo message=”Copy Stage Public 1″ />
<copy
file=”C:\MAVEN_TARGET\stage\magnoliaPublicStage1.war”
tofile=”M:\Uploads\stage\magnoliaPublicStage1.war”
overwrite=”true” />
<echo message=”Copy Prod Author” />
<copy
file=”C:\MAVEN_TARGET\prod\cms.war”
tofile=”Z:\Uploads\prod\cms.war”
overwrite=”true” />
3. Build and Deploy
Cruise control makes it easy to use other targets. The Build and Deploy just combines the previous 2 targets:
<target name=”builddeploy” depends=”build,deploy”>
<echo message=”Built and deployed” />
</target>
This has made our lives so much easier and enjoyable. It turned a 40 minute manual process into the click of a button and then about 20 minutes later we could just remote onto the server and all the WAR files were there ready to be used on Tomcat. Our deployment time was reduced significantly and so was our frustration with the deployment process.
These same techniques could be used in any technologies where you can build the solution by command line and then you can copy to your server, using the built in copy of cruise control or you can use Robocopy as we do for our IIS website deployments from CruiseControl.

