Are you actually doing continuous integration? And, if so, have you extended your organization’s processes to the point where you’ve controllered the next step: continuous delivery?
In our last blog, we focused on the first question . Based on reports and anecdotal evidence, a decent number of today’s organizations are trying hard but still falling short of following all the accepted tenets of continuous integration.
In this article, we’ll look at continuous delivery (CD). The good news is, organizations are making progress. The bad news: As with continuous integration (CI), many believe they’re doing a lot better with continuous delivery than they really are.
So, specifically, what are continuous integration and continuous delivery? Continuous integration is an automated process practiced by the development team - developers frequently commit source code changes to a central repository, and the changes are continuously built and validated. This enables errors to be found and fixed as early as possible. A continuous integration mantra is “fail fast.” This practice speeds up the development process and helps ensure high quality code.
Continuous delivery extends continuous integration principles and practices further to the right (downstream) in the software delivery process – continuously testing and deploying code to ensure that, with each change, software is in a release-ready state. Continuous delivery enables changes to be moved into pre-production or production environments, and eventually into the hands of users, in a rapid, repeatable and reliable way. Like continuous integration, this enables teams to “fail fast” based on real-world feedback and, thus, improve the value they deliver to customers.
Strongly opinionated definitions of continuous delivery state that to truly practice CD, teams should be able to positively answer the following three questions with a "yes":
Is your software in a release ready state after every change?
i.e., you can confidently deploy the software to production at any time.Do all stakeholders have visibility in the releasability of the software?
i.e., the process is automated, repeatable and traceableCan a push-button deployment be performed at any time?
i.e., the software deployment and configuration is automated and repeatable.
Based on the recent attention the industry has focused on continuous delivery, one would think the vast majority of organizations would have fully and accurately implemented the common best practices. The 2010 book by Jez Humble and Dave Farley, Continuous Delivery , popularized the term, and A-list tech companies like Netflix and Flickr have educated the world on how to achieve dozens of deployments per hour.
The numbers tell a different story. According to the DZone 2016 Guide to Continuous Delivery , half of all professionals surveyed thought they were following continuous delivery practices but only 10 percent actually were, based on the three criteria. (That number actually improved from 8 percent in 2014.)
First and simply put, if an organization ensures that software is always in a release-ready state, it is almost surely doing continuous delivery.
The second criteria from above - all stakeholders have visibility into the releasability of the software – while not absolutely required, is important. If an organization is continuously building, testing, measuring and delivering software successfully, it may not be as important. However, such visibility is often integral to establishing the trust between Dev and Ops which enables the automation of the process. Shared visibility also supports vital feedback back loops.
The third definition – a push-button deployment be performed at any time is based on the continuous delivery principle that deployment should be a non-event. Your software is always in a release-ready state, implying that you’ve tested in a production environment and tested in a deployment process.
Continuous delivery, is defined simply with criteria above, and described in detail in many writings, however what are simple fundamental steps you can take to implement it correctly?
Here I provide you a list of six steps that will help you truly assess whether you are performing continuous delivery:
Rightsize your changes
One of the first tasks is to express your changes or user stories so they can be delivered rapidly through your continuous delivery pipeline, supporting test automation, and minimizing risk. This allows you to isolate they can be easily integrated, tested, and and deployed with less risk, plus it forces you to think in terms of incremental value delivered to your customers. Do this by shifting from a waterfall development process to of lean or agile methods like Kanban or Scrum.Use a tracking system
With continuous delivery, the ability to track the movements of changes through the system is critical. Using a tracker like Bugzilla or Jira gives stakeholders the ability to collaborate across the delivery process and measure important key performance indicators (KPIs) such as the cycle time of a change.Implement a version control system
Similar to using a tracker to enter and track changes through your pipeline, those changes specified in your tracker system ultimately represent code changes made by the development team. Version control enables teams to understand at any given time what in our code base has changed, and it enables them to rapidly roll back. Modern version control systems such as Git offer collaborative features such as pull requests, which increase quality by enforcing a peer-auditing.Automatically deploy your builds
To move the build downstream, it’s important to be able to automate the deployment of the build to an environment like the one where it will run. A key aspect to this is not just the function of deploying, but also providing access to the infrastructure and environment you’re going to deploy to. In legacy processes, this used to be static. Because of the pace at which we are delivering changes in a continuous delivery pipeline, we now need immediate and constant access to environments.Deploy into a production-like environment
You must provide access to these production-like environments as early as possible in the pipeline, ideally all the way back to development. This is important because our goal with continuous delivery is to shift right and find problems fast. If we are deploying our software to environments different from that of production, there will always be unknowns when it comes time to deploy. Therefore, we can’t claim that our software is always in a release-ready state. One way of achieving this is using infrastructure as code or configuration management solutions to define your production environment and then using those same configurations to define your pre-production environments for development, test and stage.Build once and promote the binaries
Many organizations I work with which claim to practice continuous delivery, promote source code between teams and environments, rebuilding the software at each stage. This is a major continuous delivery anti-pattern. Every time you rebuild source code the chance for errors to be introduced and/or missed increases considerably. Potential differences in build scripts, environments etc, render upstream tests and validation as untrustworthy. The proper approach is to build once, and promote your binaries. This ensures that each downstream step builds on the confidence in the release created by earlier steps.
Conclusion
Continuous integration is a precursor to continuous delivery. Those who aren’t doing continuous integration and continuous delivery correctly aren’t going to gain the business value that these processes bring: faster time to market, increased competitive advantage, improved software quality and higher employee satisfaction.
Additional resources
Learn more about CloudBees Core CI/CD product line .
Download the whitepaper on technologies driving DevOps transformation .
Brian Dawson is a DevOps evangelist at CloudBees.
Folllow him on Twitter.