The most probable scenario is that your development team generates two or three releases per year of your business’ software. If it’s not the case, and you are in the hundreds of packages generated yearly: congratulations, you have successfully adopted Continuous Delivery. Otherwise, keep reading, because we might sway you to change your ways.
Deploying more frequently and with more stability, along with the inclusion of automatic testing in your pipeline, allows reducing the risks that usually come along any release. The idea is that all changes made to your code should pass a set of quality gates, potentially creating a full promotion, or either be rejected so the issues found can be fixed.
This also takes a heavy burden out of the shoulders of your teams: in order to make a publish-able package out of all code pushes, this means that they must invest in automation. Though they must spend capacity heavily in the beginning, it quickly returns benefits, as tedious tasks tend to generate human errors (be that due to confidence excesses, lack of attention, stress…). Automation, at its base, means that chores will be repeated in the very exact way each time. So, if it works once, it will succeed a hundred or a million times.
The term “Continuous Delivery” is often confused with “Continuous Deployment”. The difference between both strategies lies in the detail of automation on the promotion level: “Delivery” is about creating packages, while “Deployment” executes the installation on each environment autonomously. The first one is an absolute requirement for an adequate DevOps strategy, while the second one only facilitates deployment. It can be the case that “Continuous Deployment” is not adequate for your company, but “Continuous Delivery” will always be a benefit for you.
Written by Álvaro G. Cachón