Continuous Delivery

Posted by Alex on October 28, 2015

The work that I’ve been doing for the past few months has been pretty interesting. At the moment it takes developers working on one of our ventures about an hour and a half to two hours to deploy code to a test or prod machine. It used to take a second venture a similar amount of time to do the same task, but the process we’ve implemented for them has reduced that significantly. Once the process is completed across both ventures, our team will have reduced that deployment time enough, that the product owners for those ventures will effectively gain 20% more points for work per sprint.

*That’s a pretty huge productivity increase*

Especially given that it was two juniors and two seniors across three months that did this work.

We’re not done yet, we’ve still got some UAT and final bits and pieces to deal with, but I’m proud to say that we’re mostly there.

Here’s a basic run down of how we did it:

We chose Atlassian’s Bamboo as our general purpose task runner. It’s the backbone of our process. We chose it because it’s got a nice interface, awesome integration with Bitbucket (which all of our repos are hosted on) as well as Jira and Confluence.

It can provide us with automatically generated information about the issues addressed by a deployment, link back to repos if we need to sanity check source code and a bunch of other cool stuff. We’ve also added webhooks to our deployment channel within Slack, so Bamboo posts alerts to that channel when a deployment completes.

We’re stuck with a bunch of technologies that aren’t being used correctly (Like using Puppet to manage individual machines rather than types of machines) and Bamboo is going to give us freedom to swap out discrete pieces of the process as and when we need.

We’ve got a bunch of scripts and SSH tasks that reach out to our repos, check file versions, run puppet agents (yes, manually running rather than every n minutes), stop queues, dump databases for backup purposes, start queues and all sorts of other nebulous tasks.

The end result is that to build a venture project, all a developer needs to do is commit code. To cut a release they need to select a branch to build. To deploy to a dev, test or staging environment they need to select a build result and click deploy, same deal for pre-prod and prod (with a few additional caveats).

The great thing is, the teams are onboard with it.

This is a huge amount of disruption to the way 80% of our team does business. It affects developers, testers, BAs and product owners. Without exception, everyone that I’ve talked to is pumped. It’s a credit to the guys here that they aren’t stuck in a process but are always looking to improve. It makes me happy.