Is Continuous Deployment (CD) genuinely beneficial to organizations or just a technical geek obsession that doesn’t really provide value?

I will answer that question by describing Industrial Logic’s experience with CD, which began in 2010.

To get CD to work, we first had to make our Continuous Integration rock solid.

Doing that forced us to fix several pesky Selenium false-positives which would randomly break our build.

Learn Continuous Deployment

continuousDeployment_Python

Want to learn how to continuously deploy large, non-incremental features, make safe schema changes, perform zero downtime deployments and optimize your deployment pipeline?

Timothy Fitz, an early practitioner/inventor of CD, will be teaching our Continuous Deployment Workshop in Austin, Texas, June 10-11, 2014.

Our release process now looked like this:

stage1

Next, we needed to make sure we had zero-downtime deploys before we could fully implement CD.

At the time, we released weekly and had very short downtimes: it took a few seconds of manual work to switch from one version of our software to the next.

Nevertheless, this switch interrupted our active users because we had to tell them that a new version of the software was being released and could they please log off and log in again in a few minutes.

Because we didn’t like to interrupt active users, especially many of them at once, we looked for low-usage windows of time to do releases.

That usually meant that we would release at odd times of day or sometimes on weekends.

Getting to zero-downtime deploys removed this interruption to users and gave us the freedom to release at any time, even during heavy usage periods.

We built a cluster of active and inactive production servers to support zero-downtime deploys:

stage2

At this point, we had still not implemented CD but were already deriving value:

  • Fewer Disruptions: A rock solid build meant that we no longer got disrupted by broken builds, which gave us more time to focus on important work.
  • Freedom to Release: We could release changes, improvements or bug fixes without interrupting users and searching for low-usage windows of time.

We were now ready to make the final push to CD.

This work only took three weeks and resulted in a completely automated release-to-production process.

Here is what our release now looked like:

stage3

One of the most unexpected benefits from fully implementing CD was a noticeable reduction in our stress.

Releasing no longer involved coordination with other people, or searching for low-usage windows of time, or performing manual steps.

We simply checked code into version control, which kicked off a build, and if the build was successful and all automated tests passed, the release to production magically happened.

Releasing was now a boring, non-event.

We settled into the habit of continuously integrating to production and were soon releasing many times per day.

CD further refined our ability to break work down into small, valuable pieces that could be deployed.

It helped us derive these benefits:

  • Lower Stress: By making deployment a boring, non-event, we could stay calmly focused on delivering value to our users.
  • Greater Flow: We now had a way to quickly flow valuable improvements and fixes to our customers.
  • Less WIP: CD enabled us to have far less work-in-process. Now we would thin-slice some work and deploy it.
  • Easier Recovery: Because we release small amounts of code, it’s easier to discover any problems and fix them quickly.

The benefits of CD are compelling.

As a business owner and developer, I would say that we’ve had an extremely good return on investment from implementing Continuous Deployment.