What are the advantages of continuous deployment? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

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.)

Answer 1

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."