For many developers and IT professionals engrained in the day-to-day of the evolving DevOps industry, you regularly read about continuous delivery (CD) as it relates to DevOps. There might even be an understanding of what it is but, the question remains, are you actually executing continuous delivery or are you still knee deep in continuous integration (CI).

Based on reports and anecdotal evidence, a sizable number of today's organizations are trying hard but still falling short of following all of the accepted tenets of CI. However, the good news is you are not alone.

To start, lets take a step back and first look at what exactly CI and CD are.

Back to the Basics

Continuous delivery extends CI principles and practices further to the right in the software delivery process - continuously testing and deploying code to ensure that with each change software is in a release ready state. CD enables changes to move into pre-production or production environments, and eventually into the hands of users, in a rapid, repeatable and reliable way. Like CI, this enables to teams to "fail fast" based on real-world feedback, and thus improve the value they deliver to customers.

Continuous integration is an automated process practiced by a development team. Frequently, developers commit source code changes to a central repository and the changes are then continuously built and validated.  This enables errors to be found and fixed as early as possible. A CI mantra is "fail fast." This practice speeds up the development process and helps ensure high quality code.

According to the DZone 2016 Guide to Continuous Delivery, half of all professionals surveyed thought they were following CD practices but only 10 percent actually were, based on the three criteria. (That number actually improved from 8 percent in 2014.)

1.    Is your software in a release ready state after every change?:  Simply put, if the answer to this is yes then your organization is almost surely doing continuous delivery.

2.    Do all stakeholders have visibility in the releasability of the software?: 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.

3.    Can a push-button deployment be performed at any time?: Can a push-button deployment be performed at any time? This is based on the CD 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.

So now that we're all on the same page for the definition and criteria, here are six simple fundamental steps you can take to assess whether you are performing CD and to ensure you are implementing it correctly.

Rightsize your changes

One of the first tasks is to express your changes or user stories so they can be delivered rapidly through your CD pipeline, supporting test automation, and minimizing risk. This allows you to isolate, easily integrate, test and deploy with less risk. Plus, it forces you to think in terms of incremental value delivered to your customers.

Use a tracking system

With CD, 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

Version control enables teams to understand at any given time what in a 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 build

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.

Deploy into a production-like environment

This one is important because the goal with CD 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 which claim to practice CD, promote source code between teams and environments, rebuilding the software at each stage. This is a major CD anti-pattern. Every time you rebuild source code the chance for errors to be introduced and/or missed increases considerably. 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.

Continuous integration is a precursor to continuous delivery. Those who aren't doing CI and CD 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.

##

About the Author

Brian is currently a DevOps evangelist and practitioner at CloudBees where he helps the open source community and CloudBees customers in the implementation of agile, continuous integration (CI), continuous delivery (CD) and DevOps practices. Before CloudBees, Brian spent over 22 years as a software professional in multiple domains including QA, engineering and management. Most recently he led an agile transformation consulting practice helping organizations small and large implement CI, CD and DevOps.