This article is a key component in connection to my earlier post “Defining DevOps“.
Continuous Integration and Continuous Delivery are the two key components of a DevOps solution that focuses on minimizing Cycle Time.
Cycle Time: The time from the inception of a requirements or user story to the time that capability is in the hands of the customer, or at least is integrated, tested and ready to be deployed to the customer.
Consider the scenario – a large project with multiple Agile teams developing different components of the software application. You are an agile developer that finished your work, based on the user stories you and your team are working on. At the end of the day, you do a ‘private build’ of your work to verify it builds and ‘deliver’ it to a team build server. Other team members also deliver their work. You all ‘integrate’ your work in the common build area and do an ‘Integration Build’. As you are working with other teams, you would then ‘deliver’ your teams work to a common cross team build server and do a system wide or application wide ‘Integration Build’. Doing these integrations and builds to verify them on a regular, preferably daily basis, is what is known as Continuous Integration.
The value that Continuous Integration brings to the table is that it forces developers and team of developers to integrate their individual work with each other’s as early as possible exposing integration issues and conflicts on a regular basis.
To make continuous integration work, developers have to communicate more and ensure that their work includes changes from other developers that may impact the code they are working on. Developers are not only able to find and address integration issues regularly but also verify that the integrated application or component functions as designed.
If one does not practice continuous integration, the process of integrating ones’ work with that of other developers on the team would probably only happen at the end of the sprint or worse – a multi-month iteration. This leaves unaddressed or undiscovered risk in the application till too late. This would require developers to dedicate potentially significant time at the end of every sprint just to integrate their work and fix any issues.
Agile methodologies require these situations be avoided by integrating regularly and exposing and addressing any issues regularly, hence reducing risk.
Continuous Delivery – Extension beyond Continuous Integration:
Continuous Delivery is taking Continuous Integration to the next step. Once the application is built, at the end of every Continuous Integration build, deliver it to the next stages in the application delivery lifecycle. Deliver it to the QA team for testing and then to the operations team (the Ops in DevOps) for delivery to the production system.
The goal of Continuous Delivery is to get the new features that the developers are creating, out to the customers and users as soon as possible.
Now, all builds that come out of a Continuous Integration effort do not need to go to QA, only the ‘good’ ones with functionality that is at a stage of development that it can be tested needs to go to QA.
Similarly, all the builds that go thru QA do not need to go to production. Only those that are ready to be delivered to the users, in terms of functionality, stability and other NFRs should be delivered to production.
To test out that the builds coming out are ‘production-ready’ they should be delivered to a staging or pre-production or production like test lab. This practice of regularly delivering the application being developed to QA and Operations for validation and potential release to customers is referred as Continuous Delivery.
Some organizations have taken this notion of Continuous Delivery to the extreme.
I shall be writing another article as a continuation of DevOps and CI/CD.