Continuous deployment require a lot of effort, beyond what is needed for continuous integration.

  • Since every change corresponds to a release (more or less), there is far less time and resources available for manual testing. They need to be almost entirely replaced by automated tests, which in some cases can be very difficult to do well, and can require extensive development of automated tools. (CI encourages this too. But in CD it becomes absolutely essential, and mistakes are much more damaging.)

  • Since deployments are far more frequent, there is much less allowable downtime or disruption during a deployment. It requires better automated architecture management and deployment strategies.

Continuous deployment is popular, so clearly there are some great benefits to offset these costs.

What are the advantages of continuous deployment?

(Specifically, I am curious about benefits unique to continuous deployment, that wouldn't be obtained by continuous integration alone.)

  • 2
    Continuous deployment is popular, so clearly there are some great benefits to offset these costs -- Or, folks are just following the herd. – Robert Harvey Dec 6 '14 at 18:19
  • 1
    Also, it appears that you're using the wrong term. You might have better luck in your internet searches using "continuous delivery." The Wikipedia article under that moniker gives a fair summary of the advantages. – Robert Harvey Dec 6 '14 at 18:42
  • @RobertHarvey, true, cargo-cult does happen...a lot :) More accurately, "there must be some great benefits at least some of the time". – Paul Draper Dec 6 '14 at 20:41
  • @RobertHarvey, though they are very similar, continuous delivery and continuous deployment are different: Continuous Delivery Vs. Continuous Deployment: What's the Diff? and Practical Continuous Deployment I read the Wikipedia article. I couldn't see the advantages spelled out. – Paul Draper Dec 6 '14 at 20:43

Continuous deployment or continuous delivery is very common in web services and SaaS apps. Amazon, Facebook, Github, Google...they're all deploying all the time. Some operators deploy a handful or even dozens of updates a day for each very narrowly-defined service. I'm not even sure you could easily count the number of deployment events massive shops like Amazon and Google have, per day, in aggregate across their entire estate.

Why do it that way?

  1. Users have fixes, updates, improvements, and new features in their hands early and often. The "patch" and upgrade cycles are integrated into everyday use, not spaced out in major releases.

  2. Internal managers (product owners for individual lines of business, marketing campaigns, etc.) see their projects decoupled from all the other projects in the organization, therefore are ready to be presented to customers immediately as they are ready, not dependent on numerous other variables or "release trains."

  3. There is less "dump a lot of new features, fixes, etc. all in one shot" phenomenon. Both users and support teams learn to hate "release day" when it's periodic, because that's when the most bugs, new breakage, unknown new features/behaviors, etc. manifest themselves. Continuous deployment spreads those release moments out in many, very small chunks. (That may have its own drawbacks, but the pain is more evenly spread.)

  4. For agility. Agile techniques of all kinds require feedback loops from users. If you have a few main stakeholders, you can ask them "What do you think of this idea?" How would Amazon do that? Hold the world's largest focus group? No, they publish and go. They get feedback based on how things go, based on detailed analytics rather than direct customer feedback. Content-heavy organizations seem especially likely to become eager, active publishers with analytics-based feedback loops.

  5. For A/B testing or its multivariate equivalents. It's hard to manage complex businesses with thousands or millions of products, product options, and product possibilities "by the seat of your pants.". They need to be data driven. While related to the previous point about feedback loops, continuous delivery makes the room necessary to be continuously testing multiple options in the real-world laboratory of customer behavior. Without the ability to constantly deliver and measure changes, there would be much less opportunity to test different hypotheses and options, and thus much less opportunity to gather valuable business analytics.

  6. Fighting the nightmare of "version drift." Those running Web-facing services and apps get pretty good at slipstreaming and managing version drift--situations where there may be multiple logical versions of an app simultaneously in use. But even those good at running a dozen or two different versions don't want there to be 200, 2,000, or 20,000 different version configurations extant. The configuration management hassles and support costs become too great. Constantly deploying new code (and retiring old versions) keeps the number of actually-in-use versions to a dull roar.

  7. Build best practices and organizational fitness. Just like when you introduce automated testing techniques or continuous integration, it isn't a simple change. You don't just do a dab here and there. You have to commit to the idea of testing, or testing everything. You have to get good at it, be disciplined about it, and make sure you have the right tools, environment, and culture to become efficient and effective at that style of operation. Web properties, by virtue of their massive customer bases and constant need for new content, new services, and patches/updates to be deployed, not only have to do a huge number of updates, they have to get really good at always updating things. That leads shops like Netflix to make a continuous "build-bake-deploy" cycle part of their people and their process--not just a technical feature, but part-and-parcel of their development and operations culture.

While continuous deployment is popular in Internet-faced apps, nothing is ever perfectly continuous. There are always internal services, capacity moves, organizational readiness, and other infrastructure changes that can delay or be a prerequisite of various releases. Even for services for which many updates are continuously delivered, for technical, marketing, training, and support purposes, when there are "big" changes, it's still convenient to present, promote, train, and deploy those as a bundle.

Some changes change the nature or interface of an app. It's not wise to have that look and work one way one minute, then have it work and look different on the next page reload or AJAX call. Some features or elements only make sense in the context of having other features available. Finally, many big changes require different backend services to be assembled, or different data schema. These are all situations in which always deploying continuously doesn't make sense. Limiting the number of "major versions" in play can help users consume, and operators effectively deliver, the service. So even in the most aggressive cases, it's "continuous with occasional bumps."

| improve this answer | |
  • 1
    Both users and support teams learn to hate "release day" when it's periodic, because that's when the most bugs, new breakage, unknown new features/behaviors, etc. manifest themselves. Continuous deployment spreads those release moments out in many, very small chunks. -- So instead of dealing with the bugs in a single, concentrated, focused effort and time period, you're basically having to deal with them continuously? – Robert Harvey Dec 6 '14 at 19:12
  • 2
    Yep. And, a lot of companies that employ continuous delivery understand that they're not going to be able to deliver 100% correct code. They're all about 99.XYZ% success and moving quickly to fix whatever they break. They don't have the enterprise, life-critical, or fiduciary-responsiblity mindset in most of these services. "Works mostly, for bazoodles of users" rather than "works always." – Jonathan Eunice Dec 6 '14 at 19:28
  • 2
    Well, there is something to be said for fixing bugs early, though fixing them after deployment hardly qualifies as early. – Robert Harvey Dec 6 '14 at 19:29
  • 1
    @RobertHarvey you make some good points, but I can see the benefit of this point. After release: "Our databases have 50% higher load. What going on? I don't know. It was fine in staging, with different customer data. Hm, well it must be one of the 479 code changes we made." I've seen crap like this happen a lot. No one knows what when wrong, or who should look at, so everyone has too, but more often no one does. Recovery from "bugs", of whatever nature, is easier in CD. – Paul Draper Dec 6 '14 at 20:35
  • 1
    To @PaulDraper's point, continuous delivery shops are much more likely to pursue "canary deployments," in which changes as phased into operation. One server or subset of customers e.g. shifts to the new version; this "canary instance" or "canary users" are watched for problems. Deploy, then watch...then continue when it seems to be working (or rollback if not). – Jonathan Eunice Dec 6 '14 at 20:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.