- Description
- Un porte-conteneurs en pleine mer, vu de l'avant, laissant un large sillage.
- Source
- The U.S. National Archives · original page
- Licence
- PD Public domain
Delivery and Production Release (LIV)
A project only has value once it is delivered and in operation. Production release is the moment when uncertainty becomes real: the rarer and larger it is, the riskier it is. This theme…
Level: 🟢→🔴 · Code: LIV · Matrix: PI
Why this theme#
A project only has value once it is delivered and in operation. Production release is the moment when uncertainty becomes real: the rarer and larger it is, the riskier it is. This theme looks at delivery from a management perspective: pace, preparation, go decision, rollback, communication, stabilization. Technical automation (pipeline, continuous integration) is in the Software Development matrix and its deployment.
What this theme measures#
- Axis: from risky, manual, rare delivery to frequent, uneventful delivery.
- Key indicator: delivery frequency, delivery failure rate, downtime window duration, rollback time (metrics from DORA literature: deployment frequency, lead time for changes, failure rate, recovery time).
- Unit: deliveries per month; % failures; minutes of downtime; minutes to roll back.
The five levels#
| Level | Short name | Promise | Typical indicator (orders of magnitude) |
|---|---|---|---|
| 1 | Risky delivery | Production release is a stressful event, done manually by one or two people. | 1 to 2 per year; failures > 30% |
| 2 | Written procedure | A procedure describes delivery; it can be executed by someone other than the author. | A few times per year; failures 15 to 30% |
| 3 | Regular cadence | Deliveries follow a predictable cadence, with a go decision, documented rollback, and informed users. | Monthly to quarterly; failures 5 to 15% |
| 4 | Measured delivery | Frequency, failure rate, and recovery time are measured and improving; delivery is scripted. | Weekly to monthly; failures < 5%; rollback < 1 h |
| 5 | Uneventful delivery | Delivering is routine: frequent, automated, reversible, with no downtime window; value arrives continuously. | Several per week; failures < 2%; rollback < 15 min |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| PI-LIV-1.1 | Deliveries are dated and versioned. | List of delivered versions with dates. |
| PI-LIV-1.2 | An identified person executes the delivery. | Name recorded in the log. |
| PI-LIV-1.3 | Users are notified of an ongoing delivery if it affects them. | Warning message. |
| PI-LIV-2.1 | A written delivery procedure exists (steps, prerequisites, checks). | Up-to-date document, read by a third party. |
| PI-LIV-2.2 | A third party has already executed the procedure alone successfully. | Log of execution by another person. |
| PI-LIV-2.3 | A post-delivery functionality check is defined. | Post-delivery checklist. |
| PI-LIV-3.1 | A delivery schedule is published (predictable cadence). | 6-month schedule. |
| PI-LIV-3.2 | A go/no-go decision is tracked with criteria (acceptance testing, open risks, operations availability). | Go/no-go minutes. |
| PI-LIV-3.3 | A rollback plan exists for each delivery and has been tested at least once. | Procedure; trace of one test. |
| PI-LIV-3.4 | User-facing release notes are published with each delivery. | Notes for the last 3 versions. |
| PI-LIV-3.5 | Delivery follows an environment separation rule (testing, preproduction, production). | Environment description; promotion traces. |
| PI-LIV-4.1 | Delivery frequency and failure rate are measured by version. | Series over ≥ 8 deliveries. |
| PI-LIV-4.2 | Recovery time after failure is measured. | Durations logged by incident. |
| PI-LIV-4.3 | Delivery steps are scripted (no command retyped manually). | Versioned scripts; execution without free manual intervention. |
| PI-LIV-4.4 | Delivery failures are analyzed and acted on. | Incident reports, closed actions. |
| PI-LIV-4.5 | Data and schema migrations are replayable (idempotent) and tested on a copy. | Copy-based test procedure; replay without side effects. |
| PI-LIV-5.1 | Delivery is end-to-end automated, triggered on demand. | Pipeline triggered with no intervention beyond approval. |
| PI-LIV-5.2 | Deliveries require no service interruption for users. | Downtime measurement ≈ 0 over 6 months. |
| PI-LIV-5.3 | Rollback is automated and practiced regularly. | Tracked periodic exercise. |
| PI-LIV-5.4 | New features can be enabled or disabled independently of delivery. | Parameter-based toggle mechanism; usage example. |
Detailed reading by level#
Level 1. Signs: Friday night, a release weekend, many manual steps kept in memory. Benefit: individual control. Does not guarantee reproducibility. Difficulty: 1/5. Effort: 1/5.
Level 2. Signs: a procedure exists and has served for more than decoration. Benefit: transferability. Does not guarantee speed or absence of failure. Difficulty: 2/5. Effort: 2/5.
Level 3. Signs: version calendar, go/no-go, release notes, tested rollback. Benefit: business trust, predictability. Does not guarantee frequency. Difficulty: 3/5. Effort: 3/5.
Level 4. Signs: scripts, frequency and failure figures, incident analyses. Benefit: visible continuous improvement. Does not guarantee end-to-end flow. Difficulty: 4/5. Effort: 4/5.
Level 5. Signs: uneventful delivery, zero downtime, independent activation. Benefit: value delivered continuously, end-of-cycle pressure gone. Does not guarantee that what is delivered is useful. Difficulty: 5/5. Effort: 5/5. For a datamart with installation kits, a full 5 is rarely achievable (schema migrations, processing windows): target a solid 4.
Partial achievement and rating#
Common rule: see README.
- 0.5: go/no-go practiced but not tracked; rollback documented but never tested.
- 1: an audit of the last 3 deliveries confirms it.
- A partial 5: delivery scripted and replayed on a copy, rollback in under 30 minutes, monthly frequency; end-to-end automation is missing. Score ≈ 4.1.
Datamart delivered in installation kits: one full kit reinstalled on a database copy the day before, then replayed in production with rollback by restore (measured duration: 25 minutes). Each kit is verifiable at output by a control script. This is a level 3 to 4 approach without a continuous deployment pipeline.
Theoretical rollback. Symptom: the plan exists, restore has never been run; during an incident, it takes 6 h instead of 30 minutes. Cause: an untested plan is a hypothesis. Remedy: rollback exercise every quarter.
Goodhart: if delivery frequency becomes the objective, empty versions are delivered or work is split artificially. Always read frequency together with failure rate and delivered value.
An irreversible schema or data migration (column drop, table merge) is delivered in two stages: compatible add, switch-over, then delayed cleanup (expand/contract model). This turns impossible rollback into trivial rollback. See also Deployment and Operations (DL).
Move to the next level#
Possible means (optional)
- 1 → 2: write the procedure by having someone else execute it.
- 2 → 3: delivery schedule, go/no-go checklist, rollback test, release notes; see Project Management Methods Comparison and CI/CD.
- 3 → 4: versioned scripts, DORA-like measurement, incident analysis; see CI/CD for Data: Databases, Datamarts, Pipelines, and Reports and Azure DevOps / TFS.
- 4 → 5: end-to-end pipeline, parameter-based toggles, automated rollback.
Can draft release notes from tickets, review a deployment script, generate a control checklist; must not decide go alone or execute in production without tracked human validation.
See also#
- Related themes: 08 Quality and Acceptance · 05 Risks · 07 Stakeholders · 10 Continuous Improvement.
- Other matrices: Continuous Integration and Delivery (DL) · Deployment and Operations (DL) · DataOps (data) · Report Versioning and Industrialization (BI).
- Practice: CI/CD · CI/CD for Data: Databases, Datamarts, Pipelines, and Reports · Branching Strategies · Glossary.
✻ Written by Claude Sonnet 5.5
