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.
Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.
Heard about SRE? Learn how it relates to DevOps in my new series: Cloud Service Reliability: Apollo 13 to Google SRE
Related Posts
Understanding DevOps:
- Understanding DevOps – Part 1: Defining DevOps
- Understanding DevOps – Part 3: The Battle of Dev vs Ops
- Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
- Understanding DevOps – Part 5: Infrastructure as Code
- Understanding DevOps – Part 6: Continuous Deployment
- Understanding DevOps – The Video (6 minute Intro to DevOps)
Adopting DevOps:
- Adopting DevOps – Part I: Begin with the Why
- Adopting DevOps – Part II: The Need for Organizational Change
- Adopting DevOps – Part III: Aligning Dev and Ops Teams
- Adopting DevOps – Part IV: Adopting Continuous Deployment
- Adopting DevOps – Where to start? (Video blog)
- DevOps vs Outsourcing
DevOps books I have written:
Other DevOps Posts:
- What is Water-SCRUM-Fall?
- Leveraging DevOps in a water-SCRUM-fall world
- Monetate’s 12-step program for Continuous Delivery
- The State of DevOps (by PuppetLabs)
- DevOps for Mobile Apps – Slides from IBM Pulse 2013
- Chef for DevOps – An Introduction
Home: sdarchitect.blog 
I agree that Continuous Integration and Continuous Deployment are imperative to successful ALM. However, the database is still overlooked. Coordinating and deploying database changes is a challenging – yet critical – component of ALM and must be considered in order for Continuous Integration and Continuous Deployment to deliver the desired benefits. Read my thoughtshere
The information looks really good. But there is a broken link in the Part 1 – Defining DevOps – https://sdarchitect.wordpress.com/2012/07/24/understanding-devops-part-1-defining-devops/ – this links broken, has this page moved or removed ? if someone can look into the issue and get the page back to Active stage, it will be really great.
@Krishnaswamy, the link works fine for me. May have been a glitch. Can you try again?
@sanjeev, tried again, not working for me, may be am i missing / mis-splet the URL, pls guide me with appropriate link, if so.
Hi Sanjeev,
I am introducing DevOps in my team, as a part of which I am writing an executive summary on DevOps. One of the challenges I came across while researching, from many sources is that of changing requirements until the last minute. Where would requirements sit (Requirements life cycle) in the DevOps initiative? In Part 6 of your presentation you have shown a diagram (https://sdarchitect.wordpress.com/2013/10/16/understanding-devops-part-6-continuous-deployment/), which starts with the Dev environment. I was just wondering, since requirements impact Dev cycle, should we not include requirements cycle in DevOps also? To give you a brief idea of environment where we are. Our Dev team is still evolving in to an Agile model. My question may be very basic or out of context but we are impacted by changing requirements. Can you please throw some light on this please. Thanks.
Ashish, you are bang on. Good requirements management are a pre-requisite to good DevOps adoption. The focus around needs to be two-fold – making sure you are building the right thing, and you are building it right. Fortunately Agile methodologies have a good handle on effective requirements management. The only additional point I would highlight would be to ensure traceability all thru the delivery pipeline. Every asset should be traceable back to requirements. Not an easy task, but something to aspire for. Using an integrated ALM toolset will certainly help here.
Good insight in this, however given your portrayal of DevOps and the link with fast paced, continuous, development and delivery I am thinking that the actual pioneers of that “philosophy” would have been the likes of Semantic, MacAfee or even earlier companies than this that needed to deliver multiple releases a day in response to specific stimulate or vulnerabilities. Its unfortunate that people feel the need to jump on the high profile buzz companies of what they believe are new generation and “sexy”, whilst forgetting that most “new” miracle philosophies/methodologies are just rehashes of old ones with a slightly different twist.