i

Description

Ouvriers sur une chaîne de montage de roues dans une usine automobile

Source

auteur non indiqué · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

CI/CD: continuous integration and continuous delivery

You will be able to precisely define continuous integration (CI), continuous delivery, and continuous deployment (the two “CDs” are different), describe a pipeline and its environments.

In brief

• You will be able to precisely define continuous integration (CI), continuous delivery, and continuous deployment (the two “CDs” are different), and describe a pipeline and its environments.
• You will know deployment strategies (recreate, rolling, blue/green, canary), feature flags, and the five DORA metrics (as of 2026-10).
• You will understand what CI/CD brings to project management (visibility, risk, pace, evidence) — and above all its limits: costs, false sense of security, test coverage, pipeline debt, governance, regulation, legacy, organization.
• The data-specific version is in 11 CI/CD for data: foundations, datamarts, pipelines, and reports; here, the common foundation.

On this page

1. 1. Definitions: CI, continuous delivery, continuous deployment
   1. 🟢 Novice — three concepts often confused
   2. 🟡 Practical — the rule of three “everything”
   3. 🔴 Expert — CI: what automation does not guarantee
2. 2. Anatomy of a pipeline
   1. 🟢 Novice — the pipeline as a chain of checks
   2. 🟡 Practical — pipeline definition “as code”
   3. 🔴 Expert — designing a good pipeline
3. 3. Environments and promotion
   1. 🟢 Novice — why multiple environments
   2. 🟡 Practical — parity and promotion
   3. 🔴 Expert — ephemeral environments
4. 4. Deployment strategies
   1. 🟢 Novice — four ways to replace a version
   2. 🟡 Practical — choosing
   3. 🔴 Expert — rollback, roll-forward, and irreversibility
5. 5. Feature flags and deployment/delivery separation
   1. 🟢 Novice — the switch
   2. 🟡 Practical — uses and types
   3. 🔴 Expert — flag debt
6. 6. DORA Metrics
   1. 🟢 Novice — what we measure
   2. 🟡 Practical — how to measure them without getting it wrong
   3. 🔴 Expert — beyond DORA
7. 7. What CI/CD Brings to Project Management
   1. 🟢 Novice — not just a technical matter
   2. 🟡 Practical — the link with methods
   3. 🔴 Expert — “delivering” and “deploying to production” are not synonyms
8. 8. The limits of CI/CD
   1. 🟢 Novice — what automation does not do
   2. 🟡 Practical — eight limits to know
   3. 🔴 Expert — limits in depth
9. 9. Implementing: a realistic path
   1. 🟡 Practical — a five-step path
10. 10. Practice maturity ratings
11. 11. AI contribution
12. 12. See also

Level: 🟢→🔴

1. Definitions: CI, continuous delivery, continuous deployment#

🟢 Novice — three concepts often confused#

Historically, continuous integration was popularized by Extreme Programming (1990s-2000s); the book Continuous Delivery (Humble and Farley, 2010) formalized the deployment pipeline. These references are solid; keep only the ideas: small batches, fast feedback, everything automated and reproducible.

🟡 Practical — the rule of three “everything”#

A healthy CI/CD follows three principles:

1. Everything is versioned: code, build scripts, configuration, pipeline definition, database scripts.
2. Everything is reproducible: an artifact is built only once then promoted from environment to environment (build once, deploy many); you do not recompile for production.
3. Everything is traceable: from production, you can trace back to the commit, the request, and the person who approved.

🔴 Expert — CI: what automation does not guarantee#

Continuous integration reduces integration risk but does not rule out design errors. A “green” branch means: the existing tests pass. It says nothing about the quality of those tests. The three real CI conditions:

• a main branch that is always deployable (if it breaks, everything stops to fix it: “stop the line”);
• a fast build (ideally under 10 minutes for essential feedback; indicative order of magnitude);
• short-lived branches (a few hours to 2 days) or trunk-based development (trunk-based development) — see Branching Strategies.

2. Anatomy of a pipeline#

🟢 Novice — the pipeline as a chain of checks#

A pipeline is a sequence of automated steps that turns a code change into delivered software, with checks at each step. It fails early and fast: lowest-cost checks first.

🟡 Practical — pipeline definition “as code”#

Generic example in YAML (Azure Pipelines-style syntax, adapt as needed):

trigger:
  branches:
    include: [ main ]
pr:
  branches:
    include: [ main ]

stages:
- stage: Build
  jobs:
  - job: build_test
    pool: { vmImage: windows-latest }
    steps:
    - script: dotnet build --configuration Release
    - script: dotnet test --no-build --logger trx
    - publish: $(Build.ArtifactStagingDirectory)
      artifact: drop

- stage: DeployTest
  dependsOn: Build
  jobs:
  - deployment: deploy_test
    environment: test
    strategy:
      runOnce:
        deploy:
          steps:
          - script: ./deploy.ps1 -Env Test

- stage: DeployProd
  dependsOn: DeployTest
  condition: succeeded()
  jobs:
  - deployment: deploy_prod
    environment: production    # approbation configurée sur l'environnement
    strategy:
      runOnce:
        deploy:
          steps:
          - script: ./deploy.ps1 -Env Prod

Principles: pipeline as code (the YAML is versioned with the product), environments with configured approvals, single artifact published at the Build stage and consumed by the next ones. Tool details: Azure DevOps Server (ex-TFS) in Depth.

🔴 Expert — designing a good pipeline#

Design criteria:

3. Environments and promotion#

🟢 Novice — why multiple environments#

An environment is an isolated instance where the product runs: development, test/acceptance testing, preproduction, production. Each answers a different question.

🟡 Practical — parity and promotion#

The principle of parity: the more an environment resembles production (versions, configuration, volume, permissions), the more predictive testing is there. Typical gaps that break things: engine versions, compatibility level, service account permissions, data volume, time zone/language, regional settings.

Promotion moves the same artifact from one environment to another; what changes is the configuration (connection string, variables), injected at deployment time, never hardcoded in the artifact.

🔴 Expert — ephemeral environments#

Environments created on demand (per pull request) then destroyed remove shared-environment queues and “configuration drift.” Condition: infrastructure defined as code (Bicep, Terraform, scripts) and provisionable test data. Cost: real (compute, licenses); must be weighed. For data, ephemeral setups are difficult (volume, anonymization) — see 11 CI/CD for data: foundations, datamarts, pipelines, and reports.

4. Deployment strategies#

🟢 Novice — four ways to replace a version#

🟡 Practical — choosing#

The key is backward compatibility: if the new version tolerates the old data schema and the old version tolerates the new one, everything becomes possible (expand/contract: expand the schema, deploy, then contract once the old version is gone). This is the bridge to database deployment.

🔴 Expert — rollback, roll-forward, and irreversibility#

• Rollback: return to the previous version. Easy for stateless code, impossible or dangerous as soon as data has been written in a new format.
• Roll-forward: fix with a fast new version. Often safer than rollback on a stateful system, provided the pipeline is fast (time to fix becomes the measure of resilience).
• Disable by flag: in many cases, the best “rollback” is to turn off a feature (next section).

5. Feature flags and deployment/delivery separation#

🟢 Novice — the switch#

A feature flag (or feature toggle) is a switch in code or configuration that enables or disables a feature without redeploying. It lets you deploy code (put it into production) without delivering it (making it visible to users): deployment becomes a technical non-event, delivery becomes a business decision.

🟡 Practical — uses and types#

Minimal example in PowerShell (reading a configuration flag):

$cfg = Get-Content .\config.json -Raw | ConvertFrom-Json
if ($cfg.features.nouveauCalculCouverture) {
    Invoke-NouveauCalcul
} else {
    Invoke-AncienCalcul
}

🔴 Expert — flag debt#

Each flag doubles the code paths to test. Rules: one owner, one removal date planned at creation, an inventory, regular cleanup; limit tested combinations. In data/BI, the equivalent is a versioned alternative measure or rule (configuration parameter selecting the calculation rule), with the same removal requirement — see 11 CI/CD for data: foundations, datamarts, pipelines, and reports.

6. DORA Metrics#

🟢 Novice — what we measure#

DORA (DevOps Research and Assessment) is a research program, taken over by Google Cloud, that has published an annual State of DevOps report since 2014. The book Accelerate (Forsgren, Humble, Kim, 2018) summarizes its findings: certain technical and organizational capabilities are correlated with better delivery performance and better organizational outcomes.

The delivery performance measures (as of 2026-10, after the 2024 evolution):

Verification note: the 2024 report formalized five measures (the fifth, rework rate, is new); the former “MTTR” had already been renamed failed deployment recovery time in 2023, and DORA now classifies it under throughput, alongside change lead time and deployment frequency. The 2025 report, focused on AI-assisted development, dropped the old “elite/high/medium/low” categories in favor of team profiles (archetypes), and concludes that AI is correlated with better throughput but still with more instability (as of 2026-10; cross-checked via web research, secondary sources — to be verified against DORA publications before citing a figure).

🟡 Practical — how to measure them without getting it wrong#

• Data source: the repository (commits, merges), the pipeline (deployments), the incident management system. Define “deployment” and “failure” once for the whole team.
• Use as a team thermometer, never as an individual target or for comparison between teams in different contexts.
• Read as trends and in pairs (throughput and stability): increasing frequency with increasing failure rate is not a win.

🔴 Expert — beyond DORA#

DORA measures flow to production, not value. Fast flow of useless features is a bad outcome. It should be complemented with: delivered value (adoption, usage), perceived quality, team health, and for data: freshness, reliability (see 10 Project Metrics and Reporting). For a data project with infrequent production releases (monthly kit delivery), frequency remains naturally low: focus instead on lead time and failure rate. The SPACE framework (Forsgren et al., 2021) reminds us that productivity has multiple dimensions.

7. What CI/CD Brings to Project Management#

🟢 Novice — not just a technical matter#

CI/CD changes management, not just tooling:

🟡 Practical — the link with methods#

• Scrum: the Definition of Done must include “deployed to acceptance testing through the pipeline”; the increment is only “Done” if it is usable. See Scrum in Practice and Scrum and Data.
• Kanban/Lean: the pipeline makes queues and bottlenecks visible (Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…)).
• Predictive methods: CI/CD reduces the “late integration” effect and makes milestones verifiable (Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI)).
• Governance: pipeline approval gates (gates) materialize reviews and acceptance testing; they can replace an acceptance committee with automated evidence for low-risk cases.

🔴 Expert — “delivering” and “deploying to production” are not synonyms#

In a B2B context with clients on fixed versions or client-installed kits, teams can deliver continuously (a kit always ready) but not deploy continuously at client sites: installation cadence is driven by the client. CI/CD then provides artifact quality and traceability, not production frequency. This is a very common case, poorly covered by SaaS-centered DevOps literature.

8. The limits of CI/CD#

🟢 Novice — what automation does not do#

CI/CD is an amplifier: it makes what is good and what is bad faster. It does not create quality; it executes and measures it. The limits below are reasons not to expect too much from it, not reasons not to adopt it.

🟡 Practical — eight limits to know#

🔴 Expert — limits in depth#

False sense of security and acceleration risk. Delivering faster increases the amount of changes in flight; if incident detection and correction capacity do not keep up, instability rises. Recent DORA work on AI points in this direction: higher throughput, stability not automatically improved (as of 2026-10, see section 6). Practical conclusion: the more you accelerate, the more serious monitoring and testing must be.

Test coverage: the real problem is relevance. Four levels, from least to most useful:

1. line coverage (easy to inflate);
2. branch coverage;
3. business rule coverage (each rule has at least one named test);
4. mutation tests (code is altered, tests must fail).

Pipeline debt. Measurable symptoms: pipeline duration doubles with no scope change; “infrastructure” failure rate (agent, network) rises; number of ownerless scripts. A pipeline is code: it is reviewed, tested (on a sandbox project), and versioned.

Governance and regulation. The pipeline concentrates significant power: it has permission to deploy to production. It is an attack target (software supply chain). Measures: secrets in a vault, short-lived tokens, isolated agents, two-person approval for production, retained audit logs. In a regulated context, CI/CD is an evidence asset (everything is traceable) as much as a constraint — provided it was designed with audit in mind.

Legacy systems. Pragmatic order: (1) put all code and scripts under version control; (2) script deployment (even if it is a manual script at first); (3) build a reproducible build; (4) add characterization tests (freeze current behavior, even if it is “bad”) on risk areas; (5) automate promotion. Trying to redo everything at once is the best way to deliver nothing.

Organization. CI/CD fails first for human reasons: teams that do not integrate often, operations responsibility elsewhere, business acceptance testing that does not want automation, fear of change. An excellent pipeline in a fear-based organization gets bypassed.

9. Implementing: a realistic path#

🟡 Practical — a five-step path#

The matrix 05 Continuous Integration and Continuous Delivery and 06 Deployment and Operations provide verifiable milestones to position the team.

10. Practice maturity ratings#

Expert assessments, contextual (team of 4 to 10 people, internal or B2B product, Microsoft platform). See RATING. The ratings express the value delivered by the practice at reasonable effort and its ecosystem maturity.

11. AI contribution#

Example prompt: “Here is the log of a pipeline failing at the deployment step (secrets masked). List the 3 most likely causes, ranked by probability, and for each one, the check to perform and the corresponding command.”

12. See also#

• Direct continuation: 11 CI/CD for data: foundations, datamarts, pipelines, and reports · 13 Pitfalls and good practices in project management (cross-functional summary)
• Methods: 01 Project Management Fundamentals · 03 Scrum in Practice · 07 Methods Specific to Data Projects · 09 Choosing Your Method and Hybridizing
• Tools: Branching Strategies · Azure DevOps / TFS · TFVC · Git in Depth
• Matrices: Continuous Integration and Continuous Delivery · Deployment and Operations · Testing
• Glossary · Bibliography

✻ Written by Claude Sonnet 5.5