What is continuous delivery?

Continuous delivery (CD) is a software development practice that keeps your code in a deployable state at all times. After CI verifies the code, CD automatically builds, packages, and stages the release in a production-like environment, ready to ship at the push of a button. CD is the bridge between development and release.

What is continuous delivery?

Continuous delivery is the practice of getting verified code from a developer's branch all the way to a release-ready package, automatically and at any time. It picks up where continuous integration ends. Where CI's job is to verify a change is safe to merge, CD's job is to take that verified change and prepare it for production.

The key idea behind CD is "always deployable." At any moment, the team should be able to ship the latest code with confidence. Not "we could ship if we ran a release process for two days." Not "we could ship if we caught up on the testing backlog." Just: ship now if we want to, and the result will be safe.

That's a higher bar than it sounds. It means the build pipeline produces a single artifact that can run in any environment with the right configuration, not separate builds for staging and production. It means tests run continuously, not just before a release. It means deployment is a one-button operation, not a runbook with 40 steps.

CD is the second half of CI/CD. It's often confused with continuous deployment, which is similar but goes one step further by removing the human approval before production. The difference matters and we cover it in detail below.

CD doesn't end the release story. What happens after a build reaches production (phased rollouts, feature flags, monitoring, rollback strategies) is the domain of release management. CD gets the build to the door. Release management decides who walks through it and when.

How does continuous delivery work?

A CD pipeline runs after a CI build passes. It takes the verified artifact and moves it through environment configuration, deployment to staging, post-deployment testing, and final release packaging.

The five stages of a typical CD pipeline are:

1. Promote. A successful CI build produces an artifact: a container image, a binary, or a packaged bundle. CD picks up that artifact and promotes it to the next stage. The same artifact is reused throughout, so what gets tested in staging is exactly what ships to production.
2. Configure. The artifact gets configured for the target environment: database connection strings, feature flag defaults, API endpoints. The principle is "build once, deploy many," with configuration injected at deploy time rather than baked into the build.
3. Deploy to staging. The artifact is deployed to a production-like environment. Staging mirrors production as closely as possible: same infrastructure, same data shape, same security rules. The closer staging is to production, the more issues get caught here.
4. Verify. Automated tests run against the deployed build. Smoke tests confirm the application is up. End-to-end tests verify key user flows. Performance and security tests run on a regular cadence. If any test fails, the pipeline stops and the team gets notified before anything reaches production.
5. Stage for release. The verified build is packaged and held, ready for production release. In continuous delivery, this is where a human approves the final push. In continuous deployment, the final push happens automatically.

‍

The pipeline is defined as code, in a YAML configuration file alongside the application. That makes it auditable, reviewable in pull requests, and reproducible across teams.

The output of CD is a release-ready package. What happens next (deploy to production, observe, react) is where CD hands off to release management practices.

Why continuous delivery matters

CD is what turns "we could release" into "we are releasing." The benefits are practical, and they compound.

Releases stop being events. Without CD, releases are stressful. They take days, involve emergency war rooms, and ship rarely. With CD, releases are routine. They take minutes, ship multiple times a day, and don't require a special meeting. Engineers stop dreading deploy day because there is no deploy day.

Time-to-market drops. A feature that's done shipping the same week instead of the same quarter is a feature that captures value sooner. CD turns the time between "code complete" and "in users' hands" from weeks into hours. For teams competing on speed of iteration, that's a structural advantage.

Rollbacks become easy. When you ship daily, each release contains a small change. If something breaks, the surface area to investigate is small and the path back to the last known-good build is one button. Compare that to a quarterly release where the regression could come from anywhere in 2,000 commits.

Production behaviour gets understood. Frequent deploys generate frequent telemetry. Teams that deploy daily develop strong intuition about how their code behaves under load, which performance characteristics matter, and which user flows are most fragile. Teams that deploy quarterly never build that muscle.

Manual work shrinks. A traditional release process is full of human steps: copying files, configuring environments, running migration scripts, smoke testing in staging, getting sign-off from three teams. CD automates the parts that machines should do and leaves humans to make the decisions that actually require judgement.

Continuous delivery best practices

CD only works if the pipeline is reliable, the staging environment is honest, and the team trusts the deploy process. Here's what works.

Decouple deployment from release. Deploying code to production and releasing a feature to users are two different things. Use feature flags to deploy code with new functionality switched off, then turn it on for specific users, regions, or percentages without redeploying. This means you can deploy continuously without forcing every change to be visible at the same time.

Build once, deploy many. A single artifact should move through every environment. Don't build separate artifacts for staging and production. If staging built the artifact and production rebuilt it, what you tested isn't what you shipped. Configuration belongs at deploy time, not build time.

Make rollback as easy as deploy. A deploy you can't roll back isn't a deploy, it's a commitment. Every deploy should have a documented, tested rollback path. Test it regularly, not just when you need it. The first time you roll back shouldn't be when production is on fire.

Keep staging close to production. Staging that uses different infrastructure, different data shapes, or different security rules will miss the issues you most need to catch. Use Infrastructure as Code (Terraform, Pulumi, CDK) to provision both environments from the same definitions, with environment-specific overrides for capacity and credentials.

Automate smoke tests after every deploy. As soon as a deploy completes, run a small suite of fast, broad tests that confirm the application is up and key user flows work. Treat smoke test failures as a deploy failure: roll back automatically rather than waiting for a human to spot the problem.

Treat the pipeline as a production system. It has access to source code, secrets, build environments, and deploy credentials. Apply the same security standards you would to any other production system: secrets in a vault, least-privilege access per stage, audited logs, and dependency pinning to prevent supply-chain attacks.

Continuous delivery vs continuous deployment

Continuous delivery and continuous deployment are easy to mix up because they share the same abbreviation. The difference is one stage: who pushes to production.

‍

Most teams adopt continuous delivery first because the manual approval acts as a safety net while the team builds confidence in the pipeline. Continuous deployment is where you end up after that confidence is earned.

The choice depends on the team's risk tolerance, regulatory environment, and how much they trust their test suite. A fintech with strict change-control requirements might never move beyond continuous delivery and that's a sensible call. A consumer web team shipping new features daily probably wants continuous deployment. There's also a third option that combines elements of both: progressive delivery.

What is progressive delivery?

Progressive delivery sits between continuous delivery and continuous deployment. The idea is to keep continuous deployment's speed (every change ships automatically) but recover some of continuous delivery's control. Code reaches production as soon as it passes tests, but it's gated by feature flags or rollout rules so only a subset of users see the change at first.

A typical progressive rollout follows a predictable pattern. The change deploys to production with a feature flag switched off. The team enables the flag for an internal cohort first, then 1% of users, then 10%, then 50%, then everyone. If error rates climb or user metrics drop at any stage, the flag flips off and nobody sees the broken version. No redeploy, no rollback, just a configuration change.

Several techniques make progressive delivery work:

• Feature flags. Switches in your code that decide whether new functionality runs. Flags are managed at runtime, so behaviour can change without redeploying.
• Canary releases. A small percentage of traffic gets the new version while the rest stay on the old one. If the canary stays healthy, the rollout expands.
• Blue-green deployments. Two identical production environments run in parallel. Traffic switches from blue to green when the new version is verified, with instant rollback by switching back.
• Ring deployments. New code rolls out to concentric "rings" of users, starting with internal teams and expanding outward as confidence grows.

‍

The pipeline machinery is the same as standard CD. What changes is the rollout strategy after the build reaches production. Progressive delivery is where CD hands off to release management. The pipeline gets the build to the door. Release management decides who walks through it and when.

For mobile teams, the answer is different again. App store review introduces a step that no automated pipeline controls. Apple's TestFlight runs invite-based beta cohorts, and Google Play supports staged percentage rollouts on production releases, but the mechanics are different from web. The mobile CI/CD guide covers what continuous delivery and progressive delivery look like when the final gate is Apple's or Google's review queue rather than your own.

How Bitrise handles continuous delivery

Bitrise is a CI/CD platform that runs workflows defined in a bitrise.yml file. CD workflows on Bitrise pick up from a tested build and route it through the distribution Steps: signed packaging, release notes, and upload to whatever channel you ship through. The platform offers more than 400 pre-built Steps including signing, distribution, release management, and notification Steps, so most teams chain together what they need rather than scripting from scratch.

Release Management on Bitrise extends CD past the deploy. The Release Management dashboard tracks app store submissions, manages staged rollouts, and coordinates cross-platform releases from one place, so a release that goes wrong on one platform can be paused without touching the other. AI Build Summary surfaces context-aware insights into failures and code changes on each build, which cuts the time from "a release just broke" to "here's what changed."

For teams that need more sophisticated rollout patterns, Bitrise Pipelines let workflows run in parallel and pass artefacts between stages, so a single deploy stage can fan out to multiple distribution channels at once. Test results and build artefacts attach to each release through $BITRISE_DEPLOY_DIR so the audit trail stays intact.

Bitrise is built specifically for mobile teams. CD for mobile apps has stages web CD doesn't: code signing on every release build, distribution to TestFlight or Google Play test tracks, app store submission, and phased rollouts gated by store consoles. If you're running CD for a mobile app, the mobile CI/CD guide covers the full iOS and Android distribution path. Otherwise, the bitrise.yml reference covers the configuration details.