Continuous Delivery

Best Practice: Continuous Delivery

Continuous Delivery (CD) is the discipline of keeping software in a state where it can be released to production at any moment, on demand, with low risk. Defined by Jez Humble and David Farley in their 2010 book, CD extends continuous integration: every change flows through an automated deployment pipeline that proves it is fit for release. The business outcome is shorter lead time, smaller batch sizes, and the freedom to release on a schedule that suits the business rather than the limits of the process.

Step-by-Step Implementation Guidance

1. Establish solid continuous integration as the prerequisite for any delivery automation.
2. Build a deployment pipeline that takes each commit through build, automated tests, and progressively realistic environments.
3. Build artifacts once and promote the same binary through every stage to eliminate environment drift.
4. Automate environment provisioning so test and production environments are configured identically and reproducibly.
5. Automate acceptance and non-functional tests to validate behavior, performance, and security.
6. Keep the pipeline as the only path to production so every release is repeatable and audited.
7. Make releasing a business decision, decoupled from deployment, using techniques like feature flags.

Common Mistakes Teams Make When Ignoring This Practice

• Confusing continuous delivery with continuous deployment and skipping the human release decision when it is needed.
• Manual, undocumented production deployments that cannot be reproduced under pressure.
• Rebuilding artifacts per environment, introducing subtle differences between test and production.
• Large, infrequent releases that batch up risk and make rollback hard.
• Treating non-functional requirements as a manual afterthought outside the pipeline.

Tools and Techniques That Support This Practice

• Pipeline tools: GitLab CI/CD, GitHub Actions, Jenkins, Argo CD, and Spinnaker.
• Infrastructure automation: Terraform, Ansible, and Pulumi for reproducible environments.
• Artifact stores: Artifactory, Nexus, and container registries for immutable, promotable builds.
• Release control: feature flag platforms such as LaunchDarkly to separate deploy from release.

How This Practice Applies to Different Migration Types

• Cloud Migration: Use the pipeline to provision and promote cloud environments identically, making migrations repeatable and reversible.
• Database Migration: Automate and rehearse schema migrations within the pipeline so database changes ship as safely as code.
• SaaS Migration: Automate configuration and integration deployment to SaaS targets so cutovers are scripted and auditable.
• Codebase Migration: Route a migrated codebase through the same pipeline to guarantee it stays continuously releasable during the transition.

Checklist

• Continuous integration is reliable and fast.
• A deployment pipeline gates every change to production.
• Artifacts are built once and promoted unchanged.
• Environments are provisioned automatically and identically.
• Acceptance and non-functional tests run automatically.
• Releasing is a low-risk, on-demand decision.

During modernization and migration work, continuous delivery is most valuable when it is treated as a continuous discipline rather than a one-time setup. Teams that codify the practice, measure its outcomes, and review it regularly keep risk low and feedback fast as systems evolve. Start small with one team or service, prove the value with concrete metrics such as lead time and change failure rate, and then expand the practice across the portfolio. Pair it with the related practices in this library so that build, test, release, and operational concerns reinforce one another. Documenting decisions and automating enforcement makes the practice durable as people and priorities change, which is exactly what large, multi-team migrations demand to stay safe and predictable over time.