Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery

In Part 1 of this series on Understand DevOps, I introduced the definition of the term DevOps. In Part 2, I am going to extend that definition to include two key components of a DevOps solution – Continuous Integration and Continuous Delivery. These are two concepts that focus on minimizing 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 (while you impatiently wait for say the App store to approve the new version of your App…). More on Cycle time in a later post.

Continuous Integration – Agile in practice:

Continuous Integration is a key component of Agile Development practices. Consider the scenario – You are a developer working on a Agile team. In fact, it is a large project, so there are multiple teams developing different components of the software application you are building. You do 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 others as early as possible. This exposes 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 is leaving unaddressed, in fact, 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 integrated their work and fix any issues. Agile methodologies require that this be avoided by integrating regularly and exposing and addressing any issues regularly, hence reducing risk.

Continuous Delivery – Extending Agile beyond Development:

Continuous Delivery is nothing but taking this concept of 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 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 test area which is production like. This practice of regularly delivering the application being developed to QA and Operations for validation and potential release to customers is what is referred to as Continuous Delivery.

Some organizations have taken this notion of Continuous Delivery to the extreme. They really do deliver every update made by developers out to users on a regular basis. Flikr is one such example. They deliver multiple updates a day! While this works great for a website, it is probably not going to be viable for enterprise or mission critical software. In fact, I don’t want my bank to be updating their customer account management software several times a day. Take your time… I want access to my money NOW; I can wait for the latest feature.

More about DevOps and how Continuous Integration and Continuous Delivery fit into the broader DevOps practices and also how to best implement these two capabilities, in future posts. Follow this blog and me on Twitter to get latest updates.