Continuous deployment

How does continuous deployment work?

Continuous deployment is the practice of automatically releasing every code change that passes the pipeline straight to production, with no human approval step in between. A developer merges a pull request to the main branch; seconds later, an automated workflow runs the test suite, builds an artifact, deploys it to production, runs a health check, and either declares the release successful or rolls it back. The next merge does the same thing, and the one after that. The pipeline, not a release manager, decides what reaches users.

In practice a continuous-deployment pipeline has four stages, each of which has to be trustworthy enough that no human needs to look at it on the happy path:

• Verify. Unit tests, integration tests, lint and type checks, and a security scan run on the merge commit. A failure here stops the pipeline before anything is built. The test suite is the only gate keeping bad code out of production, so it must be both comprehensive and reliable - a flaky test is not just annoying, it is a hole in your release process.
• Build. A single, versioned artifact is produced from the commit - a container image, a tarball, a static-site bundle, a serverless package. That artifact is the immutable thing that will be deployed; the same bytes that pass staging are the bytes that reach production. Rebuilding for production is forbidden because it reintroduces drift.
• Deploy. The artifact is rolled out using a strategy that limits blast radius: usually a rolling deployment, canary release, or blue-green switch. The deploy is gated by automated health checks - readiness probes, smoke tests, error-rate and latency SLOs - against the live environment.
• Verify in production, or roll back. A failing health check triggers an automatic rollback to the previous artifact within seconds. The pipeline does not page a human first; it reverts, then pages. Humans investigate why; they do not stand between users and a recovered system.

The cultural prerequisite, often understated, is trunk-based development with very small, frequently-merged changes. Long-lived feature branches and continuous deployment are mutually exclusive: a big-bang merge cannot be safely shipped on auto-pilot. Small commits behind feature flags can.

Why does continuous deployment matter?

Continuous deployment compresses the gap between writing a change and learning whether the change works in production from weeks (or quarters) to minutes. That single property reshapes how an engineering organisation behaves:

• Smaller batches, smaller incidents. When every merge ships, every merge is small. A small change with a 1-line diff is dramatically easier to debug, review and roll back than a quarterly release bundling 200 of them. Industry research (DORA's "State of DevOps" reports, year after year) finds that the elite teams - the ones with the lowest change-failure rate - are also the ones deploying multiple times a day. The two things are not in tension; they reinforce each other.
• Feedback loops collapse. A developer who shipped at 10:14 and sees the error spike at 10:17 is in the best possible position to fix it: the context is fresh, the diff is small, the rollback is one command. A developer who shipped two weeks ago alongside 30 other changes is investigating an outage as an archaeologist.
• Release ceremony stops being a bottleneck. "When is the next release window?" disappears as a question. Marketing, support and product teams stop building schedules around a delivery cadence; the cadence is "as soon as it's ready".
• The pipeline becomes the contract. Because the pipeline is the only path to production, every quality, security and compliance concern gets implemented in the pipeline rather than relied on as tribal knowledge. That makes the controls testable, auditable and uniformly applied - which is exactly what regulators, security teams and on-call engineers want.

The honest trade-offs are real. Continuous deployment is unforgiving of a weak test suite: anything you don't catch in CI, your users will catch in production. It places a hard requirement on observability (you cannot trust the pipeline to roll back what your monitoring cannot see) and on rollback automation (the recovery has to be faster than the user complaint). And it forces a discipline of feature flags and backward-compatible changes - especially for database migrations - that not every team is set up for on day one. Teams that try continuous deployment without those foundations usually retreat to continuous delivery and a manual approval until the foundations are in place. That is not failure; that is the right order of operations.

Continuous deployment vs continuous delivery vs continuous integration

The three "CI/CD" practices sit on a spectrum and are routinely conflated, including by vendors who should know better. The distinction matters because each one demands a different level of automation maturity.

• Continuous integration (CI). Every commit is merged into a shared mainline and immediately built and tested. The goal is to catch integration problems within minutes of them being introduced. CI says nothing about deploying; a team can practise excellent CI and still release once a quarter from a release branch.
• Continuous delivery. Adds a pipeline that, on every green build, produces a deployable artifact and (often) deploys it to staging or pre-production automatically. Production deploys remain a one-click - but human-initiated - action. The codebase is always shippable; whether it ships today is a business decision.
• Continuous deployment. Removes the human click. Every green build that crosses the production gate is a production deploy. The codebase is not just shippable; it is continuously shipping.

The path most organisations walk is CI → continuous delivery → continuous deployment, adding one layer of automation at a time as confidence grows. Skipping straight to continuous deployment from a world of quarterly releases almost always ends with the team adding a manual approval back in after the first bad incident - which is fine, it just means they are now doing continuous delivery, which is a perfectly respectable destination in its own right.

How do popular CI/CD tools handle continuous deployment?

Almost any modern CI/CD platform can be wired up for continuous deployment, but the amount of integration work you do, and where the deployment logic lives, varies a lot.

• GitHub Actions is the default for projects already on GitHub, with a huge marketplace of pre-built actions for AWS, GCP, Azure, Kubernetes, Vercel and almost any cloud target you care about. Triggers on push to main are trivial; the trade-off is that the actual deploy strategy (canary, rolling, health checks, rollback) is usually pieced together from third-party actions and lives across multiple workflow files. Excellent if your team is happy maintaining that YAML and the marketplace has the deploy primitives you need.
• GitLab CI/CD treats environments and deployments as first-class concepts - the environment:, deployment: and auto_rollback keywords make CD pipelines feel native, and the merge-request UI shows the deployment status of every environment. If your team already lives in GitLab end-to-end, GitLab CI is the better fit - the integration with merge requests, environments and the security dashboard is genuinely best-in-class for that workflow. That is the honest concession: nothing beats GitLab CI inside a GitLab-centric org.
• Jenkins can do continuous deployment with declarative pipelines and plugins for every imaginable target. It is the most flexible option here and the one most likely to fit a genuinely weird environment - at the cost of running the Jenkins controller, keeping plugins current, and writing more of the deploy-and-rollback glue yourself.
• CircleCI has fast cloud-hosted runners and good caching, and is a popular choice for teams that want a pure-CI/CD vendor without operating a control plane. Deploy strategies are typically delegated to the target (Kubernetes manifests, aws ecs deploy, etc.); the platform supplies the orchestration around them.
• Argo CD and Argo Rollouts are the Kubernetes-native answer: a GitOps controller continuously reconciles the cluster to the repo, and Rollout resources model canary and blue-green strategies as Kubernetes objects. If you are all-in on Kubernetes, the Argo stack is the right tool - dedicated, mature, deeply integrated with the platform. Continuous deployment outside K8s is a different problem and the Argo answer doesn't apply.
• Spinnaker remains a strong choice for very large organisations that need multi-cloud, multi-region pipelines with rich pre-production and bake stages. The operational footprint is the well-known cost.
• Buddy is one of the options we'd recommend when the goal is to get a real continuous-deployment loop running quickly - build, deploy, health-check and rollback - without standing up a separate orchestration platform. Buddy ships first-party actions for the parts you'd otherwise wire together: HTTP_REQUEST for smoke tests, BUDDY_CLI actions for distribution routing and weighted artifact targets, ON_EVERY_PUSH triggers per branch, and run_only_on_first_failure actions that fire the rollback automatically when a health check fails. The whole loop - merge to main, build, publish a versioned artifact, deploy, verify, auto-rollback on failure - lives in one .buddy/buddy.yml reviewed alongside the code change. That makes it a reasonable fit for teams that want continuous deployment as a pipeline feature rather than a platform engineering project. It is not the right pick if you need deep, opinionated Kubernetes-native rollout primitives - that is what Argo Rollouts is for.

The honest summary: pick the tool that already fits where your code, your environments and your team's daily work live. The continuous-deployment practice is the hard part; the tooling difference between any two reasonable platforms is small once the test suite, observability and rollback are in place.

Example

The pipeline below implements an end-to-end continuous-deployment loop for a web service. Every push to main runs the tests, publishes a versioned artifact, deploys it to production, runs a smoke test against the live URL, and - if the smoke test fails - automatically re-points the production route at the previous stable artifact. No human approval, no batched release.

# .buddy/buddy.yml - continuous deployment: merge to main goes straight to production
- pipeline: "continuous-deployment"
  trigger: "ON_EVERY_PUSH"
  refs:
    - "refs/heads/main"
  fail_on_prepare_env_warning: true
  actions:
    - action: "Test"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      execute_commands:
        - "npm ci"
        - "npm run lint"
        - "npm test -- --ci"

    - action: "Build"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      execute_commands:
        - "npm ci --omit=dev"
        - "npm run build"

    - action: "Publish versioned artifact"
      type: "BUDDY_CLI"
      execute_commands:
        - "bdy artifact publish web-app:$BUDDY_RUN_ID ./dist --create"

    - action: "Deploy to production"
      type: "BUDDY_CLI"
      execute_commands:
        - "bdy distro route update prod-distro
             --domain=example.com
             --target=artifact=web-app:$BUDDY_RUN_ID"

    - action: "Smoke-test production"
      type: "HTTP_REQUEST"
      url: "https://example.com/healthz"
      expected_status_code: 200
      retries: 6
      retry_delay: 10

    - action: "Promote to stable tag"
      type: "BUDDY_CLI"
      execute_commands:
        - "bdy artifact tag web-app:$BUDDY_RUN_ID stable"

    - action: "Automatic rollback on smoke-test failure"
      type: "BUDDY_CLI"
      run_only_on_first_failure: true
      execute_commands:
        - "echo 'smoke test failed - reverting prod-distro to previous stable'"
        - "bdy distro route update prod-distro
             --domain=example.com
             --target=artifact=web-app:stable"

Three properties make this a real continuous-deployment pipeline rather than a glorified deploy script. First, there is no manual gate anywhere - a green test stage is the only thing standing between a developer's merge and a live user request. Second, the artifact is immutable and versioned: the exact bytes that the test stage saw are the exact bytes promoted to stable; nothing is ever rebuilt for production. Third, the rollback step uses run_only_on_first_failure: true, so a failing smoke test triggers an automatic revert to the previous stable artifact before the pipeline notifies a human - the recovery is part of the pipeline, not a runbook. Combined with a strong test suite and feature flags for half-built features, this loop is what lets a team merge dozens of times a day and still sleep through the night. See Buddy's deployment docs for the trigger-and-event details behind ON_EVERY_PUSH.