Article Written by Brian Dawson, DevOps evangelist, CloudBees
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.