Skip to content

Deployment Strategies

Deployment used to be an event. A release was planned, scheduled, communicated, and executed, often outside business hours, with a rollback plan and people standing by. Each deployment was rare, big, and risky.

Modern deployment practice runs in the opposite direction. Deployments happen many times a day, in small pieces, automatically, with monitoring catching problems as they appear. The change is not just operational. It is what makes the rest of modern engineering practice possible: trunk-based development, fast feedback, feature flags, and the ability to recover quickly from production problems all depend on deployment being routine.1

The strategies in this chapter are the operational techniques that make routine deployment safe.

Continuous Delivery vs. Continuous Deployment

The two terms are easy to confuse:

  • Continuous delivery means every change is built, tested, and ready to be deployed at any time. The decision to actually deploy is still a human one.
  • Continuous deployment means every change that passes the pipeline is automatically deployed to production, without a human gating step.

Continuous delivery is the discipline most teams should adopt. Continuous deployment is a further step that some teams choose, and that requires a higher level of test coverage, observability, and automated recovery than continuous delivery alone.

A team can be doing continuous delivery without doing continuous deployment. The reverse is not really possible: continuous deployment without continuous delivery is just shipping unreviewed work directly to customers.

The Strategies in the Toolkit

A few patterns recur in modern deployment practice. Most production systems use several of them in combination:

  • Rolling deployment. New code is rolled out to instances of the service one at a time, with health checks between each. If a problem appears, the rollout halts. The cost is that the system runs with mixed old and new code during the rollout.
  • Blue-green deployment. Two full copies of the production environment exist (blue and green). New code is deployed to the inactive one; traffic is switched to it once verified. Rollback is a traffic switch, not a redeploy. Expensive on infrastructure; cheap on rollback time.
  • Canary release. A small percentage of traffic is routed to the new version while the rest stays on the old. The team watches metrics on the canary before promoting it to the full fleet. Catches problems before they affect everyone.
  • Shadow / dark traffic. New code receives a copy of production traffic but does not affect user-facing responses. Used to validate that new code behaves correctly under real load before any user is exposed.
  • Feature-flag-gated rollout. Code is deployed in a disabled state, then enabled progressively (by user, by region, by percentage) using feature flags. The deployment and the release are independent events.2
  • Ring deployment. Concentric rings of users (internal, then beta, then early adopters, then everyone) receive the new code on a schedule. Used in larger products where staged exposure matters.

These patterns are not mutually exclusive. A blue-green deployment can use feature flags. A canary release can use shadow traffic. The discipline is matching the combination to the system's actual risk profile.

Zero-Downtime Deployment

Most modern deployments are expected to happen without taking the system offline. This is not magic; it is a set of constraints that the application and the deployment process have to satisfy:

  • Backward and forward compatibility. During a rolling or blue-green deployment, old and new code run simultaneously. Both must understand the data formats, message contracts, and API versions in use.
  • Schema changes via expand-contract. Database changes cannot break either the old or the new code. The pattern is to expand the schema first, deploy code that handles both, migrate data, then contract.3
  • Idempotent operations. A request that gets retried during a deployment cutover should not cause the wrong thing to happen twice.
  • Graceful shutdown. Instances being replaced should finish their in-flight work, drain connections, and exit cleanly.
  • Health checks that mean something. A health-check endpoint that returns 200 OK regardless of actual health is worse than no health check, because it gives the deployment system false confidence.

Common Anti-Patterns

  • Deployment as theatre. Each release is a high-stakes ritual with a deployment plan, a war room, and a rollback rehearsal. The team is investing in managing the risk of large, infrequent deployments rather than in eliminating it by making deployments small and frequent.
  • Big-bang releases. A quarter of work shipped in one deployment. Anything that goes wrong is hard to attribute and harder to fix.
  • Manual coordination across services. Releases that require careful sequencing of multiple deployments by hand. The cost is paid every time, plus the cost of the inevitable mistakes.
  • Pipelines that are never actually green. A CI/CD system in which the build is "usually broken" provides no signal. The team learns to deploy past it, which means the safety net is no longer catching anything.
  • No path to rollback or rapid recovery. Releases that cannot be undone if they go wrong. Some changes (data migrations especially) require this, but it should be a deliberate choice with eyes open.

What This Looks Like in Practice

  • Aim for deployment to be routine. If a deployment requires a meeting, the system is not ready for frequent deploys. The work is to remove that friction, not to schedule fewer deploys.
  • Decouple deploy from release. Feature flags, ring deployments, and canary releases all make the moment of code-going-live and the moment of users-seeing-it independent. The risk of each is lower in isolation.
  • Invest in monitoring at the deploy boundary. The metrics that matter during a deploy (error rates, latency, throughput) should be visible in real time, and auto-rollback should trigger when they spike.
  • Practice rollback. A rollback path that has never been exercised is not a rollback path. Teams should know how to roll back, ideally automatically, and verify it works in staging.
  • Treat the deployment pipeline as production infrastructure. It is the most-used path to production. Its reliability matters as much as the reliability of the application itself.

Operational reality

Deployment should become routine, not theatrical. A team that ships many small deployments confidently is operating from a different risk posture than a team that ships rare large ones nervously, even when the underlying systems are the same.

See also: Trunk-Based Development, Feature Flags, Expand-Contract Migrations, Fix Forward, Observability.

  1. Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley, 2010). The canonical text on the pipeline practices, deployment automation, and operational discipline that make routine production deployment safe. ↩

  2. See Feature Flags for the longer treatment. ↩

  3. See Expand-Contract Migrations for the longer treatment. ↩