The Unexpected Consequences of Automating our Deployment

Six month ago when I joined DrDoctor we were doing manual deployments into production. It would take us somewhere between two and three days to prepare for, test and release into production. We had no Continuous Integration environment and nowhere to test or demo changes before releasing.

Today it is a very different picture. Each change that we push to our BitBucket repository is picked up by TeamCity, which then does a build and runs an extensive test suite. The build is then made available to Octopus Deploy which we use to deploy into a test environment that very closely mirrors our production server, we can then promote the release to Production.

Here are some of the unexpected consequences that have come about as a result:

1. The quality of the User Stories that our product owners produce has dramatically increased. Our stories are now (generally) focused on a vertical slice
2. When starting new areas of work we factor in the time required to set up the deployment steps necessary to release into production
3. We started off with a test server that kind of looked like our production server, we’ve invested a lot of time in making it mirror production as close as possible
4. We break things from time to time, but we’re okay with that - when we do break things we retrospect and figure out how to avoid it happening that way again
5. We try to be mindful of making architectural decisions that are going to fit with releasing often
6. We are actually able to pursue continual improvement - but after a while we became stuck as to what we needed to improve so we created a release diary which we fill in each time we deploy into production to identify pain points
7. Our deployment system (Octopus Deploy) has become living documentation about our production environment
8. At the beginning deploying database changes was too hard to automate, so we stuck with a manual process. Over time we’ve figured out how to automate right up unto the point of applying the changes
9. We had the mantra - deploy often - but then we found ourselves in the habit of bunching up lots of changes, which made it harder to deploy. To fix this we gave ourselves three days from the time a story had been accepted by the Product Owner (that means demoed in our test environment) to releasing it into Production - we don’t always hit it but we try our best
10. Releasing into production is no longer the job of the individual who had the most experience and knew all the quirks, rather it is something that everyone on the team can all do, with confidence

If you’re interested in how to get started with automating your deployments leave a comment, I would be very happy to help you along the way.