Continuous integration/continuous delivery contributes to fast development as well as to resilient operations because the deployments are more reliable. The code commit triggers the automated build functionality to extract the latest code commit from the shared version control repository and to build, test, and validate the full master branch (aka trunk).
Continuous Integration emerged as a practice due to the isolated nature of software development whereby developers require constant integration points of their changes with the rest of the development team’s codebase. Long waiting cycles become the cause of several merge conflicts, bugs with difficult resolution paths, diverging code strategies, and duplicated efforts.
One of the main aims of Continuous Integration is to keep the master branch free of exceptions and errors. Software development teams can establish branch policies to ensure that the master branch meets certain pre-agreed and pre-authorized quality criteria.
Continuous Delivery (CD) regards the process of building, testing, and promoting to production environment new releases. This requires staging environments that become part of a Release Pipeline to automate infrastructure provisioning and deployment of new releases. Continuous Delivery is a lean practice. The goal of Continuous Delivery is to keep an incident-free production environment running on a healthy status. This is achieved by discovering the shortest path from the availability of new code in the version control repository right through to package management for deployment purposes.
Continuous Delivery relies heavily on the progressive deployment rings for the deployment model it utilizes e.g. new features. The first deployment ring is often a ‘canary release’ in a production environment that is accessible by e.g. the software developer’s team IT organization. Consecutive deployment rings welcome wider user populations. Those next deployment rings may require an approval point by a key decision-maker. Another deployment model regards ‘Blue/Green deployment’ whereby the existing version (blue) keeps running in production while a new one (green) is deployed. Typically, load balancing is used to redirect a limited number of users to the green deployment. If monitoring identifies an ongoing incident, traffic can be rerouted to the blue deployment as a backout plan activation mechanism.
About the author
As an IT Service Management trainer, consultant and line manager with over 25 years of experience in IT, Marcel has performed strategic and tactical assignments in a wide variety of areas. For the ITIL 4 update, Marcel has been part of the ITIL 4 Lead Architect Team and Review Team at AXELOS. Through his association with AXELOS, Marcel comprehends the background, the architecture, and the underlying reasons of the ITIL 4 update.