In my last post, I detailed how our deploy process is integrated with Hipchat. One of the key benefits of this integration is the visibility that it gives to all members of the team; everyone in the company (from development to operations to sales) has visibility into changes that are being pushed into production.
But we can take this a step further. There are some members of the team who don’t spend much time in Hipchat and still need visibility as to what functionality is being pushed to production. And there are various other reasons why someone could miss notifications in the Development room that a deploy occurred.
In this post, I’m going to detail a few of the creative ways the we communicate out deploy summaries to the entire team in pursuit of the highest level of visibility possible as it pertains to production deploys. Moreover, this is another example of how we put one of our core Fundbase cultural beliefs into practice - automation.
Similar to our now completely automated Standup (to be detailed in a future post and perhaps our best example of us putting automation into action), at one time, our CTO would manually communicate out what code was deployed at the end of each day via an email with the subject:
Daily Deploy Notes. What I mean by deployed code is tasks relating to specific tickets. This could be bug, regression issue, improvement, new feature, etc that is tied to a specific JIRA ticket. This means that we would have to look back through the PR descriptions, gather all the ticket numbers, transfer these to an email, address and send. Every. Single. Day.
I should also briefly mention that the PR description, which could sometimes contain 10 tickets, used to be contructed manually, but thanks to Funbot, it is auto-generated now. Refer to my previous post for more details. Funny how one step in automation leads to the next.
An example production PR:
The old daily deploy notes:
Now this wouldn’t be much of a post if that’s all I had to say about deploy notes, would it? Because this is frequent, repetitive, and has high visibility and importance, it is a prime candidate for automation. So here is how we do it now…
When we create a PR from funbot:
@funbot deploy prepare
First, notice that funbot asks for an Email Subject - more on this later.
Secondly, the PR description is formatted in a very clear way. But it’s not only formatted like this to be readable.
Following a successful deploy, we automagically send out the daily deploy notes email to the entire company with the subject
Daily Deploy Notes - Add info/warning and possibility to report CR:
The process of sending out the Daily Deploy Notes now has 0 human involvement and is entirely automated.
Here’s out it works: We use the Git API to fetch the PR. Then we pass the PR body to a GitParser module which uses a series of Regex patterns to parse the JIRA task links and descriptions and group them by type. This is why the generated PR description is so important - it’s not just readable, it’s parsable in a consistent way. We add a touch of humanization. We also parse the PR title and use it in the email subject, hence why Funbot asks for it when preparing the deploy. Finally, the output for the GitParser is passed to ActionMailer which does the rest.
So what are some key takeaways from this story of progression from mundane drudgery to automatical enlightenment? Always be on the lookout for tasks that meet the criteria for automation. And if it can be automated, it MUST be automated.