Lean Continuous Deployment

The quick, proven way to continuously deliver software on practically any team

Continuous Deployment (CD) is the conceptually-simple practice of automatically deploying software changes immediately after merge to mainline. It is widely accepted as one of the most effective ways to increase velocity of software delivery, reduce risk, lower defect count, and increase developer satisfaction.

But when it comes to actually implementing CD, there are many reasons people come up with not to do it yet, or not on their particular project.

The road to CD…

Despite the nearly universal acceptance of CD as a good idea, actual adoption rates remain surprisingly low. One reason is that migrating to CD is often viewed as too risky or too by many teams, with the typical migration path looking something like this:

  1. Write a bunch of automated tests. Aim for 100% test coverage.
  2. Magic happens!
  3. Continuous Deployment!

Somewhere there in the middle step, we have some complicated CI/CD pipelines, static analysis, automated UI tests, DAST, and about a thousand other buzzwords, that would make Google envious.

”CD just isn’t practical for small teams,” you might think. “We have features to deliver! Maybe when we’re bigger, we can afford this investment…”

What if there were a better way?

I’m sure you won’t be surprised when I say: There is a better way!

Put simply: contrary to conventional wisdom, Continuous Integration and test automation are not strictly needed prior to the transition to Continuous Deployment. All those confusing buzzwords can be simply ignored for now.

By taking a page from the lean startup methodology, and implementing a sort of CD minimum viable product, we can jump to the end goal of working CD much faster. Then we can fill in all the missing pieces as time permits and business priorities dictate.

My Lean Continuous Deployment Bootcamp is a free guide to implementing this approach.

What is a Minimum Viable Product?

The Lean Startup by Eric Ries introduced the concept of an MVP, or minimal viable product, a “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

The book offers examples of businesses in highly-automatable industries, doing manual labor to prove that a market exists for their new product. One famous example is that of Nick Swinmurn, founder of Zappos. To prove that consumers would buy shoes online, he photographed the inventory of a local shoe store, posted them online, and when an order came through, he purchased the requested shoes at full price, and shipped them to the buyer, at a per-unit loss.

While this scheme lost money on a per-sale basis, it was ultimately much cheaper and less risky than the more obvious alternative: building an entire eCommerce platform to sell shoes, hoping there would be a market.

How does MVP apply to software delivery?

Continuous Integration, Delivery, and Deployment are all proven techniques in the field of software delivery. So why would we need an MVP?

There are two related reasons I like to apply the MVP approach to proven techniques like this:

  1. Every software project is unique. A snowflake. While there are common patterns across most projects, practically by definition, no two software projects are the same, so should not use the same release process. Starting with an MVP allows each project to prove which technique(s) are actually effective in its unique context.

  2. Another benefit of the MVP, even its original context, is that it’s a complete (though minimal) working product or service. This allows the flexibility to incrementally improve whatever parts of the system are most painful, without worrying about the other working parts, even if they’re less than optimal.

With an MVP CI/CD pipeline in place, a software team is free to focus on optimizing only the most painful parts at any given moment, while reaping the benefits of CD much sooner as compared with the traditional approach of complete automation first.

A typical starting point

Fig 1. A typical software delivery lifecycle, as with GitFlow.

Let me make this a bit more concrete with an example. Figure 1 illustrates what may be a typical software delivery lifecycle, with three distinct “checking” phases: Code review, Quality Assurance testing (QA), and User Acceptance Testing (UAT). When using a workflow such as GitFlow, each of these stages is often a gate-keeping stage immediately before advancing a piece of code to the next stage, the final stage being deployment to production, where users of the software can benefit.

This is pretty nearly the antithesis of continuous deployment. Even if the final build and deployment are automated, the existence of manual gatekeeping stages between the initial code merge and the final deployment means the project is still held back by multiple potential bottlenecks.

The goal

Fig 2. A reorganization of manual gatekeeping, shifted left of the initial merge.

The goal, then, of the lean CD approach, is not to automate all of the testing or other gatekeeping activities. This is a laudable goal, but comes later. Rather, the goal is simply to shift left these stages, and allow them to happen before the initial code merge, as illustrated in Figure 2.

By far the most common objection I hear to continuous deployment is “But we need to do more testing before we can deploy!”

This diagram should immediately put such concerns to rest: The exact same testing is happening, as in a non-CD scenario. The only difference is the order in which the testing occurs!

Clearing the technical obstacles

Naturally, there’s a certain amount of technical engineering work to be done before most teams can start doing this form of Lean CD.

The biggest, and most obvious obstacle to this new workflow is the need for some way to allow the QA team or other stakeholders access to a running version of the software with the proposed changes, before the changes are merged.

There are two approaches to this problem, and most teams use both, in order. And transitioning to these two approaches constitutes the majority of the technical work of implementing Lean CD.

Preview environments

Many teams already have a designated staging environment, which can be used for this purpose. The key is to re-purpose it slightly, to allow its use prior to merge, rather than after merge.

Of course this does introduce a certain contention, when multiple developers are waiting in line for the staging environment.

But this can actually be thought of as a good thing. The truth is, that this contention already exists, prior to re-ordering of the manual gatekeeping. The difference is that prior to re-ordering, generally multiple changes are being tested together, rather than in isolation. This serves to muddle the situation, hiding the inefficiency inherent in the system. After re-ordering, the inefficiency, and the true bottlenecks, are much more evident.

When the team experiences serious contention on a single staging environment, it’s time to work on automating ephemeral review environments, which is the “Gold Standard” when employing the lean CD approach.

Start your own Lean CD Journey

If this approach to Continuous Deployment adoption appeals to you, then my Lean CD Bootcamp is for you. It’s a free daily email course to guide you through the steps necessary to transition your team to Lean CD.