One of the cool things about working at Secret Escapes – apart from playing Fifa and FPS shooters over LAN – is we have a ‘hackday’ every other Friday, something other innovative companies like Netflix and Google do. We basically get a whole day to work on anything innovative for the company whether its fully automating our deployment process, creating a Google chrome extension plugin for the site, monitoring a users heart-rate with a FitBit to show them which sales got them most excited, making a Facebook game, or automating our release notes. Not all of the stuff we work on is incredibly fancy, but its refreshing and rewarding to have the freedom to work on anything we want.
So, the way we did our release notes previous to the most recent hackday was developers would fill in a ‘Release Version’ field on the Jira ticket they were working on and a short summary about the ticket. After a release we would go into Jira and search for any tickets associated with the release version that had just gone out. We would then copy and paste the search results into an email and chuck the email out to everyone. This had a couple of problems:
- Repetitive manual work – Searching for tickets on Jira, copying + pasting content, writing/sending off an email. It is not unusual to sometimes have 3 releases in one day.
- Inconsistent release notes formatting – They would look slightly different each time they were sent which made them slightly less pleasing to digest, and did not give a very professional look to the team.
- Looked ugly – This again made them slightly less pleasing to digest. Release notes can already be pretty boring to read, so having them look ugly doesn’t help either.
So how did we address these issues during our hackday? We made a small Groovy/Gradle application that would talk to the Jira REST API and extract the release notes for us, format it into a pretty HTML template designed by one of our designers, and save the html file. The application takes in one parameter – the release version number.
To automate things further, we put this application onto our Git repository and created a new Jenkins job that would pull the application from the repository, run it, and then send the email off to the company using the html template produced by the app. This is done using the Jenkins Email-ext plugin.
For a bit of added extra security we have the email first sent to the person who kicked off the job to verify the expected content appeared in the email, and then after manually verifying we give Jenkins the go ahead to send the the email off to the rest of company. If you’re curious, the manual verification step was added into our Jenkins job using the Jenkins Workflow Plugin – a plugin we’re starting to use more frequently now which is pretty cool and I definitely recommend checking out. We plan to later remove this manual step once a few more releases have gone out and we’re confident it works as expected, and actually integrate it in with our deployment process so you can deploy a release and send all the release notes with one simple click!
So now we just need to click a button on Jenkins and our release notes get sent to the whole company looking like this: