Continuous Delivery¶
Humble, J., Farley, & David. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.
Cited by¶
22 citations across 22 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Abstract Work
- In software, the program is the work while a binary build, a running process, and a deployed container are instances; source versioning operates on the work, build pipelines on instances.
This sourceStandard software-engineering reference distinguishing the versioned program/source (operated on by version control) from the build artifacts and deployed instances produced by the build-and-release pipeline — the program-as-work / build-artifact-as-instance separation.
- In software, the program is the work while a binary build, a running process, and a deployed container are instances; source versioning operates on the work, build pipelines on instances.
- Chesterton's Fence
- The portable interventions follow directly from the descriptive prime and recur across substrates. Investigate before removing — in code, read the commit that introduced the line; in policy, read the legislative history; in conservation, study the species' role across seasons; in product, search prior research and incident reports. Record the constraint when erecting — comments that name the race condition a guard prevents, preambles that state a statute's purpose, design-rationale documents in engineering — because future reformers face the problem only when the past failed to encode the reason. Stage removal as an experiment — rather than wholesale removal, disable, shadow, or sunset the artifact and watch what breaks, the discipline behind feature flags and canary deployments.
This sourceDescribes feature flags and canary releases as staged, reversible exposure rather than wholesale change.
- The portable interventions follow directly from the descriptive prime and recur across substrates. Investigate before removing — in code, read the commit that introduced the line; in policy, read the legislative history; in conservation, study the species' role across seasons; in product, search prior research and incident reports. Record the constraint when erecting — comments that name the race condition a guard prevents, preambles that state a statute's purpose, design-rationale documents in engineering — because future reformers face the problem only when the past failed to encode the reason. Stage removal as an experiment — rather than wholesale removal, disable, shadow, or sunset the artifact and watch what breaks, the discipline behind feature flags and canary deployments.
- Controllability
- A platform engineering team at a global e-commerce company builds its "production controllability" initiative around explicit controllability reasoning
This sourceDefines the deployment pipeline and the build/test/deploy automation that make production changes fast, safe, and reversible.; topical/load-bearing for the deployment-control practices described.
- A platform engineering team at a global e-commerce company builds its "production controllability" initiative around explicit controllability reasoning
- Controlled Reentry
- The exit (quarantine, rollback, furlough, shutdown) may be rapid and binary; reentry is deliberately slower and graduated because the system is vulnerable, as Humble and Farley (2010) develop in the deployment-pipeline literature.
This sourceThe deployment-pipeline reference showing release as an active, staged, instrumented process.
- The exit (quarantine, rollback, furlough, shutdown) may be rapid and binary; reentry is deliberately slower and graduated because the system is vulnerable, as Humble and Farley (2010) develop in the deployment-pipeline literature.
- False Dilemma
- Naming the false dilemma forces enumeration of the suppressed residual: ship Friday with the buggy feature behind a feature flag disabled by default; ship a smaller release that excludes only the affected subsystem; ship Friday to a 5% canary cohort and hold the broad rollout one week; fix the specific bug with a two-day hotfix and ship the following Tuesday.
This sourceDescribes incremental release strategies — canary releases, staged rollouts, and decoupling deployment from release — that supply concrete alternatives beyond ship-now-or-slip, supporting the surfaced software-release residual options.
- Naming the false dilemma forces enumeration of the suppressed residual: ship Friday with the buggy feature behind a feature flag disabled by default; ship a smaller release that excludes only the affected subsystem; ship Friday to a 5% canary cohort and hold the broad rollout one week; fix the specific bug with a two-day hotfix and ship the following Tuesday.
- Intervention Stack Accretion
- The pattern recurs in security controls (defence-in-depth deployments each justified by a specific incident, producing alert fatigue and conflicting requirements, with periodic control rationalisation as the inverse), in organisational initiatives (change programmes, meeting cadences, OKRs, and training mandates accreting into "initiative fatigue," with "change moratoria" as the named reverse), in build systems and CI pipelines (pre-commit checks, lints, test stages, and deploy gates accreting, with pipeline-simplification sprints as the inverse),
This sourceTreats feature flags, deployment pipelines, and the combinatorial configuration space (2^N) that accreting flags and pipeline stages create, plus rationalization as the inverse.
- The pattern recurs in security controls (defence-in-depth deployments each justified by a specific incident, producing alert fatigue and conflicting requirements, with periodic control rationalisation as the inverse), in organisational initiatives (change programmes, meeting cadences, OKRs, and training mandates accreting into "initiative fatigue," with "change moratoria" as the named reverse), in build systems and CI pipelines (pre-commit checks, lints, test stages, and deploy gates accreting, with pipeline-simplification sprints as the inverse),
- Logistics Overreach
- from retail and platform engineering it imports roll-out gating and progressive deployment
This sourceEstablishes progressive/staged deployment and release gating as disciplines for advancing change no faster than operational support can sustain.
- from retail and platform engineering it imports roll-out gating and progressive deployment
- Script
- The ordered sequence is the causally chained stages — checkout, build, unit-test, integration-test, deploy-to-staging, deploy-to-production — each whose postcondition is the next stage's precondition:
This sourceDescribes the build-test-deploy pipeline as causally chained stages where each stage's postcondition gates the next and a failed check halts the run.
- The ordered sequence is the causally chained stages — checkout, build, unit-test, integration-test, deploy-to-staging, deploy-to-production — each whose postcondition is the next stage's precondition:
- Stage Gate Process
- Venture capital: pre-seed through later rounds, each committing more capital, requiring more evidence, and applying explicit gate criteria. Software releases: alpha, beta, release candidate, and general availability, each with explicit exit criteria and an escalation in user exposure.
This sourceCodifies the staged software deployment pipeline (build, test, release stages) with explicit exit criteria and escalating exposure from internal testing through release to production.
- Venture capital: pre-seed through later rounds, each committing more capital, requiring more evidence, and applying explicit gate criteria. Software releases: alpha, beta, release candidate, and general availability, each with explicit exit criteria and an escalation in user exposure.
Mechanisms¶
- Atomic Deployment Step
- They use a blue-green deployment.
This sourcePresents blue-green deployment as a release technique using parallel production environments for fast cutover and rollback.
- They use a blue-green deployment.
- Bounded Coupling Pilot
- It resembles a canary release, where a change is exposed to a small population first to bound the blast radius before a full rollout.
This sourceDocuments a canary release; a change is exposed to a small population first; to bound the blast radius before a full rollout.
- It resembles a canary release, where a change is exposed to a small population first to bound the blast radius before a full rollout.
- Canary Handoff Sequence
- This is the discipline of canary releasing / progressive delivery — expose a little, watch, then widen.
This sourceDescribes staged release practice in which a change is first exposed narrowly, observed, and widened only after acceptable results.
- This is the discipline of canary releasing / progressive delivery — expose a little, watch, then widen.
- Canary Reentry Trial
- It is the standard canary release discipline applied to return-from-isolation, and its abort trigger means a bad reactivation is caught by a fraction of the population rather than all of it.
This sourceLimits the effect of a bad release by exposing only a small subset of production traffic before wider rollout and stopping or rolling back on regression.
- It is the standard canary release discipline applied to return-from-isolation, and its abort trigger means a bad reactivation is caught by a fraction of the population rather than all of it.
- CI/CD Pipeline
- The guarding discipline is the canary release: never promote to all users on gate-passage alone; expose the change to a small population
This sourcePresents canary releasing as staged exposure from an initial internal group to a small set of users before the majority.
- The guarding discipline is the canary release: never promote to all users on gate-passage alone; expose the change to a small population
- Cohort-Based Reactivation
- Its strength is that it converts a mass reactivation or migration into a controllable, observable drain in which each wave earns the right to run the next — a natural fit for canary-style early detection.
This sourceAddison-Wesley Professional, 1st ed.. https://www.pearson.com/en-us/subject-catalog/p/continuous-delivery-reliable-software-releases-through-build-test-and-deployment-automation/P200000009113/9780321670229 Presents canary release practices as a low-risk way to expose a limited deployment to production conditions before broader release.
- Its strength is that it converts a mass reactivation or migration into a controllable, observable drain in which each wave earns the right to run the next — a natural fit for canary-style early detection.
- Feature Flag Rollout Threshold
- A Feature Flag Rollout Threshold is the right tool when a change is reversible, its effect is measurable in near-real-time, and the cost of a bad release scales with how many users see it — the textbook conditions for a canary release.
This sourceDescribes canary release as monitoring a change on a small user subset before wider rollout, limiting the impact if problems appear.
- A Feature Flag Rollout Threshold is the right tool when a change is reversible, its effect is measurable in near-real-time, and the cost of a bad release scales with how many users see it — the textbook conditions for a canary release.
- Feature-Flagged Strictness Rollout
- Its strength is that it makes tightening safe to attempt — it converts an all-or-nothing breaking change into a reversible experiment with a bounded blast radius, and the evidence gate means the decision to proceed rests on observed impact rather than hope.
This sourceDescribes reversible, limited-audience deployment with observation and rollback before broader release.
- Its strength is that it makes tightening safe to attempt — it converts an all-or-nothing breaking change into a reversible experiment with a bounded blast radius, and the evidence gate means the decision to proceed rests on observed impact rather than hope.
- Gradual Rollout Intensity
- Its strength is that it bounds the blast radius of a change and makes reversal nearly free — the operational form of a canary release.
This sourceDescribes canary release as deploying to a limited subset before broader rollout to reduce release risk.
- Its strength is that it bounds the blast radius of a change and makes reversal nearly free — the operational form of a canary release.
- Parallel Operation and Staged Cutover
- Its strength is that it proves a change in production, at real scale, while keeping exposure bounded and a fallback always in reach — the safest way to cross when the new version is unproven.
This sourceDescribes two production environments that allow a release to be verified before cutover and rapidly rolled back by switching traffic to the prior environment.
- Its strength is that it proves a change in production, at real scale, while keeping exposure bounded and a fallback always in reach — the safest way to cross when the new version is unproven.
- Phased Rollout Validation
- Its software analog is the canary release — expose the change to a sliver of traffic, watch, and roll forward or back before it reaches everyone.
This sourceDefines canary releasing as routing a small subset of users to a new version, monitoring it, then widening or rolling back before full exposure.
- Its software analog is the canary release — expose the change to a sliver of traffic, watch, and roll forward or back before it reaches everyone.
- Rolling Upgrade
- The discipline that prevents this is the expand-and-contract (parallel-change) pattern
This sourcePresents parallel change as expanding compatibly, migrating consumers while old and new paths coexist, and contracting only after migration.
- The discipline that prevents this is the expand-and-contract (parallel-change) pattern
- Rollout Cap
- A single number is impossible to misread, cheap to enforce, and hard to quietly wave away in a planning meeting — the same discipline behind a canary release, where a change is exposed to a capped fraction of traffic before any wider rollout.
This sourceDescribes canary release as exposing a change to a small subset of users before widening the rollout.
- A single number is impossible to misread, cheap to enforce, and hard to quietly wave away in a planning meeting — the same discipline behind a canary release, where a change is exposed to a capped fraction of traffic before any wider rollout.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 22 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 7 other ways.
- https://www.oreilly.com/library/view/continuous-delivery-reliable/9780321670250/ ×4
- https://www.pearson.com/en-us/subject-catalog/p/continuous-delivery-reliable-software-releases-through-build-test-and-deployment-automation/P200000009113/9780321670229 ×4
- https://www.pearson.com/en-us/subject-catalog/p/continuous-delivery-reliable-software-releases-through-build-test-and-deployment-automation/P200000009113/9780321601919 ×3
- https://books.google.com/books?id=6ADDuzere-YC ×2
- https://search.worldcat.org/title/here-637306927 ×1
- https://www.pearson.com/en-gb/subject-catalog/p/continuous-delivery-reliable-software-releases-through-build-test-and-deployment-automation/P200000009113 ×1
- https://www.pearson.com/en-us/subject-catalog/p/continuous-delivery-reliable-software-releases-through-build-test-and-deployment-automation/P200000009113 ×1
Registry ID ref:08b346f9ea5b · see in the full table