Saturday, October 26, 2013

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:

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

Environment: ${grails.util.Environment.current.name}

Build Info:

Name

Value

UserName

#${g.meta([name: 'build.userName'])}

Built by

#${g.meta([name: 'build.number'])}

Date

#${g.meta([name: 'build.date'])}

Branch

#${g.meta([name: 'repository.branch'])}

Revision number

#${g.meta([name: 'repository.revision.number'])}

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!

About Me

Alex Staveley is a software professional passionate about software
engineering and technical architecture. He blogs about architectural
approaches, Java topics, web solutions and various technical bits and
pieces.