When I started my career in web development, we delivered software once it was completed. This would often mean many months of work would get delivered all in one felt swoop.
The problem with this should be obvious. When there are bugs, it’s very hard to understand which changes caused these bugs, because the entire system has changed. Like a needle in the haystack.
Additionally, the client has to wait for months to receive their product. Plus, often times the product is delivered quite a bit differently than the client expected. Perhaps we missed the mark?
From here, many companies transitioned into sprints or iterations. This allowed us to deliver software on a more frequent time schedule. If a feature was done, it’d go live within weeks.
This is where many companies get stuck. It is hard to imagine going any faster than this, but it is possible, and that’s where continuous delivery comes into play. But what is continuous delivery?
Continuous delivery is, just as the name suggests, continuously delivering software as soon as it is ready. Ready is defined as implemented, code reviewed, and tested.
So, let’s say I’m working on a story to add some field to some form. It takes me 30 minutes to code. Then it takes an hour to get code reviewed. Then it takes a few more hours to get tested.
At this point, the new form field is implemented, reviewed, and tested. Thus, it would be automatically deployed into production and available for the client to begin using immediately.
Continuous delivery really stands on the shoulders of a strong automated testing strategy. If you have to manually test all of your work, it’s just going to become infeasible to do this.
Many people consider continuous delivery a pie in the sky, but it is honestly not that difficult. Here are a few steps I would take to get there:
- Make sure your code has strong unit test overage (90+%)
- Make sure your code has service-level (integration) tests
- Make sure the product has automated end-to-end tests
- Use an automated build system like Jenkins to run these tests.
With the proper testing strategy in place, continuous delivery is more of a simple choice than an unobtainable goal.
I started thinking about continuous delivery after reading Henrik Warne’s blog. For another (similar) perspective on continuous delivery, check out his recent post: Benefits of Continuous Delivery: