Occasionally, when I buy some food I check the label to see how unhealthy it is in an effort to remind myself to eat better. I probably should do this more often but that’s another story.
With software, I take a more strict approach. I like to know exactly what version of what I am using and if it pertains to a build coming from a project I am working on, I like to know even more:
- the branch it came from
- any code or config changes
- the time the build was done
- the person who did the build
- the commit revision it corresponds to
The advantages of this are obvious but worth re-stating.
- While you are in development, if you have multiple deployments and see something unusual you will immediately want to compare them.
For example say you have:
- build #349 on box 1
- build #352 on box 2 (which includes development changes from a feature branch Y)
You notice some strange behaviour for an error message on box 2 but don’t on box 1. You can immediately check which box has what version, then check the changes and then try to rationalise the difference.
- You can be sure your latest code check-in is deployed
- All this build information should be in official release notes, so if you can automate it as part of your development process you have saved yourself having to automate it as part of your release
- In enterprise architectures where you have multiple components developed from different teams integrating with each other, all components should make it easy to get this information. This helps to manage the stack and for everyone to be able to immediately check if new versions of any components have been deployed or to roll back to stable versions if problems with any upgrades of components happen.
So away with the opinions and now with some examples. The project that I am currently working uses a Grails based architecture and Atlassian’s Bamboo for builds and deploys. I wanted to get this information I described into every build – and yes that includes every development build. I will now outline the steps.
Step 1
Write an event handler to execute when the war is being created. This should read a bunch of system properties (which you’ll set in bamboo) and put them in your application.properties of your war file. Example:
eventCreateWarStart = { warName, stagingDir ->
def buildNumber = System.getProperty( "build.number", "CUSTOM" )
def buildTimeStamp= System.getProperty("build.timeStamp", "")
def buildUserName= System.getProperty("build.userName", "")
def repositoryRepositoryUrl= System.getProperty("repository.repositoryUrl", "")
def repositoryRevisionNumber= System.getProperty("repository.revision.number", "")
def repositoryBranch= System.getProperty("repository.branch", "")
ant.propertyfile(file: "${stagingDir}/WEB-INF/classes/application.properties") {
entry(key:"build.number", value:buildNumber)
entry(key:"build.timestamp", value: buildTimeStamp)
entry(key:"build.userName", value: buildUserName)
entry(key:"repository.revision.number", value: repositoryRevisionNumber)
entry(key:"repository.branch", value: repositoryBranch)
}
}Step 2
Update your bamboo build to set these system properties when the war is being built. To do this, update the build war task to something like:
war -Dbuild.number=${bamboo.buildNumber}
-Drepository.branch=${bamboo.repository.git.branch}
-Dbuild.userName=${bamboo.ManualBuildTriggerReason.userName}
-Dbuild.timeStamp=${bamboo.buildTimeStamp}
-Drepository.revision.number=${bamboo.repository.revision.number}This will mean when bamboo builds you war all the above properties will be put in your application.properties file.
Step 3
Now all you need to do is make it easy for a Grails GSP to read these properties and display them. This means that when deployed all anyone will have to do is hit a special URL and then they’ll get all the build info for the deployed WAR.
...
... Some CSS and JavaScript
<h1>
Environment: ${grails.util.Environment.current.name}</h1>
<hr>
<h4>
Build Info:</h4>
<table class="altrowstable" id="alternatecolor">
<thead>
<tr><td>Name</td><td>Value</td></tr>
</thead>
<tbody><tr><td>UserName</td><td>#${g.meta([name: 'build.userName'])}</td></tr>
<tr><td>Built by</td><td> #${g.meta([name: 'build.number'])}</td></tr>
<tr><td>Date</td><td>#${g.meta([name: 'build.date'])}</td></tr>
<tr><td>Branch</td><td>#${g.meta([name: 'repository.branch'])}</td></tr>
<tr><td>Revision number</td><td>#${g.meta([name: 'repository.revision.number'])}</td></tr>
</tbody></table>And in the spirit of food analogies… Here’s one I made earlier and how it looks
So there you go, software taken more seriously than food. I’m off to get a Big Mac!
