Last week I went to the Lean Start-up Meetup in Boston where Florian Motlik of Codeship lead a discussion with Amos Benninga from GrabCad, Dan Rowe from ETSY and Ken Eimer from InsightSquared on Continuous Deployment. The presentation was excellent, a great mix of best practices and practical application. Their comments rang true with our experiences too so I’ve summarized below why Continuous Deployment should matter to you as well.
What is Continuous Deployment
Continuous Deployment is a software development practice is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. After those integrations are automatically tested and approved, they are deployed to production immediately.
Why Continuous Deployment
- Shortens feedback loop with the customer: This is the most obvious and “Lean Start-upy” reason for Continuous Deployment. By pushing features out to customers multiple times a day, you are decreasing the time required to find out how customers are using the code. When code sits in an unpublished branch, it’s not doing your business much good.
- Bug prevention improved: Continuous Deployment means implementing rigorous automated testing. Developers must write test scripts before coding and are constantly enhancing the library of tests for a system that must be passed in order for code to be merged. Developers enhance their skills be improving against tests over time and deliver higher quality code via automated testing. Furthermore, because code is pushed to production more quickly rather than sitting in a branch, conflicts from merging branches are minimized.
- Bug fixing made more simple: By practicing Continuous Deployment, you are sending smaller changes into production more frequently. This means that these changes are easier to examine and pinpoint issues because you have fewer people working on each deployment (it’s easier to talk through the issues with only a few hands on the code) and because the changes are smaller, they can be analyzed more quickly. Furthermore, Continuous Deployment, by it’s nature demands shorter deploy times so fixes can be pushed quickly once a solution is found. Rather than rolling back problem code, in Continuous Deployment, you’re rolling pre-tested code forward(via automated tools).
- Developers love it: Continuous Deployment has the attribute of pushing more responsibility and ownership to developers. In Continuous Deployment, developers must commit their code to the main branch after passing thorough, automated testing. And since their code is not being released with a bunch of changes from other developers, developers can truly have full responsibility for the impact of their code. This responsibility leads to more ownership for developers. Equally important however, is the fact that developers can see their code working in production faster and get the satisfaction of seeing their work in the wild (instead of languishing in a branch).
Tips for getting started with Continuous Deployment
Continuous Deployment isn’t easy. It requires changes for developers as well as product owners. You may encounter resistance from all parts of the business. One of the best ways to counter this resistance and to get started is by continuously deploying to your staging environment. As development teams work through the process of building tests for their code and product owners get used to working in smaller chunks, some of the resistance to continuous deployment should begin to subside. Establishing Continuous Deployment practices with internal users and stakeholders is a great way to leave the training wheels on and build confidence in the tests that you have built to verify your code.
Another great step to take is to create feature flags in the code. Feature flags are used to disable functionality for some or all users. Said another way, feature flags allow developers to turn features on or off at runtime to test out new functionality. They provide a option to remove a feature that is causing problems for a site without the dreaded “roll back”.
Continuous Deployment is not a silver bullet in and of itself. However, when coupled with monitoring and visibility, it can be a powerful tool for driving innovation and delivering high value (and quality) code. Performance monitoring is critical to identifying code that may have passed automated testing standards but is overloading the system. Similarly, business metrics must be monitored (and delivered in a near real time manner) to ensure that new features aren’t hurting the business.
