Chapter 24 Flashcards — Continuous Delivery
flashcards seg continuous-delivery cd feature-flags release-train
What is Continuous Delivery (CD)?
?
The practice of keeping every code change in a state where it can be deployed to production at any time, and of deploying frequently to deliver value to users rapidly. CD extends CI’s principle — verify everything automatically, fail fast — into the deployment and production monitoring dimensions. CI asks “Is the codebase green?” CD asks “How do we get green builds to users quickly and safely?”
What is the relationship between CI and CD?
?
CI is the prerequisite for CD. CI continuously certifies the codebase as releasable (green). CD builds on that foundation: if every green build is deployable, the question becomes how frequently and automatically to advance builds into production. Without CI establishing a trustworthy green state, CD cannot safely function. CI produces release candidates; CD deploys them.
What does “velocity is a team sport” mean in the context of CD?
?
Engineering velocity in CD is determined by the system — integration cycles, deployment process, batch size, and verification loops — not by individual coding speed. A team where engineers write code twice as fast but deploy monthly is not high-velocity. The bottlenecks are typically: large infrequent deployments, slow manual sign-offs, and long integration cycles. CD addresses velocity at the system level by making each step in the pipeline automated, fast, and low-stakes.
What is a feature flag (feature toggle), and what problem does it solve?
?
A feature flag is a conditional in production code that controls whether a feature is active for a given user or environment without requiring a deployment. It solves the coupling between deployment (putting code in production) and release (activating features for users). With flags, code can be deployed safely while inactive, then released gradually by enabling the flag — enabling gradual rollouts, instant rollbacks, and isolated feature evaluation.
What does “flag-guarding” a feature mean, and what does it enable?
?
Flag-guarding means wrapping a new feature in a feature flag so that the code is deployed to production but the feature is invisible to users (flag off). This enables: (1) safe deployment of incomplete features; (2) graduated rollout (1% → 10% → 100% of users); (3) instant rollback by disabling the flag without a deployment; (4) A/B testing by activating the flag for selected user segments; (5) dark launches — running the feature on real traffic without surfacing results, to validate performance.
What is a graduated rollout, and why is it valuable in CD?
?
A graduated rollout is the practice of activating a new feature for a progressively larger fraction of users — e.g., 1% → 10% → 50% → 100% — using a feature flag. It is valuable because: (1) problems affect only a small user fraction before full deployment; (2) real-world metrics (error rates, performance, engagement) can be measured at each stage before proceeding; (3) roll-back is instant (disable the flag) if metrics show problems. It converts “all-or-nothing” releases into low-risk, observable steps.
What is a release train, and what problem does it solve?
?
A release train is a scheduled, regular release cadence — e.g., “we release every Tuesday” — where whatever is ready at the departure time ships, and whatever is not ready waits for the next train. It solves the “just one more feature” trap: without a fixed schedule, teams delay releases repeatedly to include nearly-ready features, causing releases to grow larger, riskier, and more delayed. The train does not wait; features miss the train and ship (flag-guarded) on the next one.
What are the key properties of a release train?
?
(1) Fixed schedule — releases happen on a defined cadence regardless of feature readiness; (2) No waiting — the train departs on time; unready features ship with their flag off or don’t ship at all; (3) Predictable — stakeholders and users know when to expect releases; (4) Low stakes per release — because each release contains only what was ready since the last departure, each is individually low-risk and easy to roll back.
What does “no binary is perfect” mean as a CD philosophy?
?
It is the empirical observation that in complex systems with many users and edge cases, every release will contain some defects that testing did not catch. Waiting for perfection means waiting forever — while existing bugs in production continue to affect users and unreleased changes accumulate, increasing release risk. The correct response is to ship frequently (keeping each release small), invest in rapid detection and monitoring, use gradual rollouts to limit blast radius, and treat post-release response capacity as a first-class engineering investment.
What cultural discipline does the release train model require from engineers?
?
Engineers must structure work so that changes are independently mergeable and deployable before the train departs. Concretely: features not yet ready are flag-guarded so they can be deployed without being released; changes are kept small enough to fit within a single release window; work in progress that is not safe to deploy lives in a feature branch or behind a flag — not uncommitted on a laptop. This is the operational meaning of “meet your release deadline.”
What is the “ship only what gets used” principle?
?
The principle that deployment velocity must be paired with user-focused validation. Fast shipping without user feedback produces a codebase of unused, unmaintained features that become permanent maintenance burden. Teams must measure whether users actually engage with features after release and remove features that do not meet usage or impact thresholds. The goal of CD is delivering value to users, not merely deploying code.
What mechanisms help enforce “ship only what gets used”?
?
(1) Usage metrics — instrumentation measuring whether users actually engage with a feature; (2) A/B experiments — comparing feature users against a control group to measure user outcome improvement; (3) Graduated rollouts — measuring engagement at 1% or 10% before committing to full rollout; (4) Sunset criteria — defining in advance what a feature must achieve to remain in the product; (5) Feature removal — actively removing features that don’t meet the bar rather than leaving them as dead code.
What does “shifting left” mean in the context of CD?
?
Shifting left means moving quality and user-impact validation decisions earlier in the pipeline — closer to development — rather than discovering problems at staging, beta, or post-launch. Examples: running automated performance tests in CI before staging (quality gate), using canary deployments to validate with production traffic before full rollout, running A/B tests on a small user cohort before building a full feature, and using monitoring during graduated rollout to confirm before proceeding.
Why does shifting left require a cultural change, not just a technical one?
?
Teams must be willing to: (1) kill features based on early data, even after significant investment; (2) make release decisions based on metrics rather than intuition or schedule pressure; (3) treat measurement and instrumentation as first-class engineering work (not a post-launch afterthought); and (4) accept that a feature that does not show positive early signal should not proceed to full rollout, even when it was expensive to build.
How do large deployments compare to small, frequent deployments in CD?
?
Large deployments: bundle many changes (hard to attribute failures), are high-stakes (teams are reluctant to deploy), require more manual review, and produce complex rollbacks when they fail. Small, frequent deployments: individually low-risk, failures are attributable to specific changes, can be automated (low consequence), and produce clean rollbacks. CD’s fundamental operational premise is replacing large infrequent deployments with small frequent ones.
What is a “dark launch” and when is it used?
?
A dark launch deploys a feature to production and runs it against real traffic — processing requests and producing results — but does not surface those results to users (flag is off for display). It is used to validate a feature’s performance, correctness, and resource consumption at real production scale before exposing it to users. Dark launches catch performance problems and data correctness issues that staging environments, with synthetic traffic, cannot surface.
What is the relationship between feature flags and technical debt?
?
Feature flags carry a flag debt risk: flags that are never cleaned up after their rollout is complete accumulate as conditional branches in the code, making it harder to read, maintain, and test (each flag typically requires tests for both on and off states). The discipline is to treat flags as temporary: once a feature is fully rolled out and stable, the flag must be removed and the conditional eliminated. Permanent flags are a form of technical debt.
Why must monitoring be considered a component of CD, not a post-deployment add-on?
?
CD defines release as complete when production behavior is confirmed, not when code is deployed. This requires monitoring that makes confirmation fast and reliable. Without monitoring, teams deploy and hope; with monitoring, teams deploy and observe — and act immediately when signals indicate a problem. Monitoring also closes the feedback loop that shift-left depends on: early metrics during a graduated rollout are only useful if the instrumentation exists to surface them.
What are the cultural practices that support a healthy CD culture?
?
(1) Deployment as routine — frequent, automated deployments should be unremarkable, not celebrated or feared; (2) Engineer ownership through deployment — engineers who write features should deploy and monitor them; (3) Monitoring ownership — release is not complete until production behavior is confirmed; (4) Blameless post-mortems — deployment failures should improve the system, not punish engineers; fear of blame creates fear of deployment, the opposite of CD.
What makes CI and CD culturally different requirements?
?
CI’s cultural requirement is that engineers write tests — a practice at the individual contributor level. CD’s cultural requirement is broader: engineers deploy frequently, own releases through monitoring, keep changes small, clean up flags, and accept that “no binary is perfect.” CD requires organizational discipline around the entire delivery pipeline, not just one engineering practice. CD culture is about making deployment a routine, low-stakes, engineer-owned act rather than a high-stakes, infrequent, operations-team-owned event.
Total Cards: 20
Review Time: ~15 minutes
Priority: HIGH
Last Updated: 2026-06-02