Traditional software release model is organized around ‘big bang’ releases. An application has new features, fixes developed over months or even years, tested and then releases all at once. If bugs are found after release it may take some time before end users received fixes again.
This model is still used by many companies and it comes from times when the software was distributed on floppy disks. But nova days we have high-speed network connections (both in datacenters and at homes) and we believe it’s time to use it! Software deployed to servers, or installed by end users over the internet has the ability to be easily upgraded. There is no need for a product recall or aftermarket upgrades to bring new features or performance upgrade when a new version can be deployed over the network as frequently as necessary.
Continuous delivery is different model for software release (deliver) that aims to reduce the amount value-added-but-not-yet-delivered-to-users by cutting the time between releases. This can be seen as outgrowth of agile software development with it’s aim of developing software iteratively and seeking continual validation and feedback from users in order to avoid the increased risk of redundancy or features that are not fit for the purpose associated with large, infrequent software releases.
Teams using continuous delivery push features and fixes live when they are ready without batching them into formal releases. It is not unusual for continuous delivery teams to push updates live multiple times a day.
Continuous deployment goes even further than continuous delivery, automatically pushing each change live once it has passed the automated tests, canary analysis, load testing, and other checks that are used to prove that no regressions were introduced.
Continuous delivery and continuous deployment rely on the ability to define an automated and repeatable process for releasing updates. At a cadence as high as tens of releases per week it quickly becomes untenable for each version to be manually deployed in an ad hoc manner. What teams need are tools that can reliably deploy releases, help with monitoring and management if there are problems, and otherwise stay out of the way.
Benefits of Continuous Delivery:
Continuous delivery removes the ceremony around the software release process. There are several benefits to this approach: - Innovation. Continuous delivery ensures quicker time to market for new features, configuration changes, experiments, and bug fixes. An aggressive release cadence ensures that broken things get fixed quickly and new ways to delight users arrive in days, not months.
Faster feedback loops. Smaller changes deployed frequently makes it easier to troubleshoot issues. By incorporating automated testing techniques like chaos engineering or automated canary analysis into the delivery process, problems can be detected more quickly and fixed more effectively.
Increase reliability and availability. To release quickly, continuous delivery encourages tooling to replace manual error-prone processes with automated workflows. Continuous delivery pipelines can further be crafted to incrementally roll out changes at specific times and different cloud targets. Safe deployment practices can be built into the release process and reduce the blast radius of a bad deployment.
Developer productivity and efficiency. A more frequent release cadence helps reduce issues such as incompatible upstream dependencies. Accelerating the time between commit and deploy allows developers to diagnose and react to issues while the change is fresh in their minds. As developers become responsible for maintaining the services they deploy, there is a greater sense of ownership and less blame game when issues do arise. Continuous delivery leads to high performing, happier developers.
If you still have questions about CI/CD feel free to contact us.