What was your most embarrassing moment in your career as a software engineer? Mine was when I deployed an application to production and it didn’t even start.
Early in my career deploying an application usually involved a fair bunch of manual steps. Logging in to a remote server via ssh and executing various commands. After a while repetitive steps were bundled in shell scripts. But mistakes happened. That’s normal. The solution is to automate as much as we can. So here are the steps to automatic deployment happiness.
Build
One of the oldest requirements for software development mentioned in The Joel Test is that you can build your app in one step. With Grails that’s easy just create a build file (we use Apache Ant here but others will do) in which you call grails clean, grails test and then grails war:
<project name="my_project" default="test" basedir=".">
<property name="grails" value="${grails.home}/bin/grails"/>
<target name="-call-grails">
<chmod file="${grails}" perm="u+x"/>
<exec dir="${basedir}" executable="${grails}" failonerror="true">
<arg value="${grails.task}"/><arg value="${grails.file.path}"/>
<env key="GRAILS_HOME" value="${grails.home}"/>
</exec>
</target>
<target name="-call-grails-without-filepath">
<chmod file="${grails}" perm="u+x"/>
<exec dir="${basedir}" executable="${grails}" failonerror="true">
<arg value="${grails.task}"/><env key="GRAILS_HOME" value="${grails.home}"/>
</exec>
</target>
<target name="clean" description="--> Cleans a Grails application">
<antcall target="-call-grails-without-filepath">
<param name="grails.task" value="clean"/>
</antcall>
</target>
<target name="test" description="--> Run a Grails applications tests">
<chmod file="${grails}" perm="u+x"/>
<exec dir="${basedir}" executable="${grails}" failonerror="true">
<arg value="test-app"/>
<arg value="-echoOut"/>
<arg value="-echoErr"/>
<arg value="unit:"/>
<arg value="integration:"/>
<env key="GRAILS_HOME" value="${grails.home}"/>
</exec>
</target>
<target name="war" description="--> Creates a WAR of a Grails application">
<property name="build.for" value="production"/>
<property name="build.war" value="${artifact.name}"/>
<chmod file="${grails}" perm="u+x"/>
<exec dir="${basedir}" executable="${grails}" failonerror="true">
<arg value="-Dgrails.env=${build.for}"/><arg value="war"/><arg value="${target.directory}/${build.war}"/>
<env key="GRAILS_HOME" value="${grails.home}"/>
</exec>
</target>
</project>
Here we call Grails via the shell scripts but you can also use the Grails ant task and generate a starting build file with
grails integrate-with --ant
and modify it accordingly.
Note that we specify the environment for building the war because we want to build two wars: one for production and one for our functional tests. The environment for the functional tests mimic the deployment environment as close as possible but in practice you have little differences. This can be things like having no database cluster or no smtp.
Now we can put all this into our continuous integration tool Jenkins and every time a checkin is made out Grails application is built.
Test
Unit and integration tests are already run when building and packaging. But we also have functional tests which deploy to a local Tomcat and test against it. Here we fetch the test war of the last successful build from our CI:
<target name="functional-test" description="--> Run functional tests">
<mkdir dir="${target.base.directory}"/>
<antcall target="-fetch-file">
<param name="fetch.from" value="${jenkins.base.url}/job/${jenkins.job.name}/lastSuccessfulBuild/artifact/_artifacts/${test.artifact.name}"/>
<param name="fetch.to" value="${target.base.directory}/${test.artifact.name}"/>
</antcall>
<antcall target="-run-tomcat">
<param name="tomcat.command.option" value="stop"/>
</antcall>
<copy file="${target.base.directory}/${test.artifact.name}" tofile="${tomcat.webapp.dir}/${artifact.name}"/>
<antcall target="-run-tomcat">
<param name="tomcat.command.option" value="start"/>
</antcall>
<chmod file="${grails}" perm="u+x"/>
<exec dir="${basedir}" executable="${grails}" failonerror="true">
<arg value="-Dselenium.url=http://localhost:8080/${product.name}/"/>
<arg value="test-app"/>
<arg value="-functional"/>
<arg value="-baseUrl=http://localhost:8080/${product.name}/"/>
<env key="GRAILS_HOME" value="${grails.home}"/>
</exec>
</target>
Stopping and starting Tomcat and deploying our application war in between fixes the perm gen space errors which are thrown after a few hot deployments. The baseUrl and selenium.url parameters tell the functional plugin to look at an external running Tomcat. When you omit them they start the Tomcat and Grails application themselves in their process.
Release
Now all tests passed and you are ready to deploy. So you fetch the last build … but wait! What happens if you have to redeploy and in between new builds happened in the ci? To prevent this we introduce a step before deployment: a release. This step just copies the artifacts from the last build and gives them the correct version. It also fetches the lists of issues fixed from our issue tracker (Jira) for this version as a PDF. These lists can be sent to the customer after a successful deployment.
Deploy
After releasing we can now deploy. This means fetching the war from the release job in our ci server and copying it to the target server. Then the procedure is similar to the functional test one with some slight but important differences. First we make a backup of the old war in case anything goes wrong and we have to rollback. Second we also copy the context.xml file which Tomcat needs for the JNDI configuration. Note that we don’t need to copy over local data files like PDF reports or serach indexes which were produced by our application. These lie outside our web application root.
<target name="deploy">
<antcall target="-fetch-artifacts"/>
<scp file="${production.war}" todir="${target.server.username}@${target.server}:${target.server.dir}" trust="true"/>
<scp file="${target.server}/context.xml" todir="${target.server.username}@${target.server}:${target.server.dir}/${production.config}" trust="true"/>
<antcall target="-run-tomcat-remotely"><param name="tomcat.command.option" value="stop"/></antcall>
<antcall target="-copy-file-remotely">
<param name="remote.file" value="${tomcat.webapps.dir}/${production.war}"/>
<param name="remote.tofile" value="${tomcat.webapps.dir}/${production.war}.bak"/>
</antcall>
<antcall target="-copy-file-remotely">
<param name="remote.file" value="${target.server.dir}/${production.war}"/>
<param name="remote.tofile" value="${tomcat.webapps.dir}/${production.war}"/>
</antcall>
<antcall target="-copy-file-remotely">
<param name="remote.file" value="${target.server.dir}/${production.config}"/>
<param name="remote.tofile" value="${tomcat.conf.dir}/Catalina/localhost/${production.config}"/>
</antcall>
<antcall target="-run-tomcat-remotely"><param name="tomcat.command.option" value="start"/></antcall>
</target>
Different Environments: Staging and Production
If you look closely at the deployment script you notice that uses the context.xml file from a directory named after the target server. In practice you have multiple deployment targets not just one. At the very least you have what we call a staging server. This server is used for testing the deployment and the deployed application before interrupting or corrupting the production system. It can even be used to publish a pre release version for the customer to try. We use a seperate job in our ci server for this. We separate the configurations needed for the different environments in directories named after the target server. What you shouldn’t do is to include all those configurations in your development configurations. You don’t want to corrupt a production application when using the staging one or when your tests run or even when you are developing. So keep configurations needed for the deployment environment separate and separate from each other.
Celebrate
Now you can deploy over and over again with just one click. This is something to celebrate. No more headaches, no more bitten finger nails. But nevertheless you should take care when you access a production system even it is automatically. Something you didn’t foresee in your process could go wrong or you could make a mistake when you try out the application via the browser. Since we need to be aware of this responsibility everybody who interacts with a production system has to wear our cowboy hats. This is a conscious step to remind oneself to take care and also it reminds everybody else that you shouldn’t disturb someone interacting with a production system. So don’t mess with the cowboy!
Schneide Blog 