La CI/CD n’est pas une priorité !

Summary

In many of the teams I have helped through a DevOps transformation, the first initiative was to set up CI/CD. It looks like proof of seriousness and modernity. Too often it was premature, misunderstood or incomplete, and this article is what I wish those teams had read first.

A pipeline deserves the name only if three things hold: it starts on its own on every change, a failing test, quality gate or security scan stops it, and it deploys with a strategy that fits, Blue/Green, canary, rolling update. A chain that carries on despite failing tests or known vulnerabilities is not CI/CD, and a chain that can break production without being able to roll back is incomplete. Mastering CI without CD, or the reverse, is perfectly serious work.

Before automating, four things must be settled: the architecture, the persistence layer, the quality and security controls, and the deployment and rollback strategy. Otherwise the pipeline simply ships mistakes faster than value. The persistence layer is the part everyone forgets and the one that is often irreversible: databases, message buses, configuration, file storage, search indexes, access models, each with its own risk and its own practice, from versioned schemas to logical deletions kept for a few releases.

Two more lessons from the field. Application and infrastructure must not share a pipeline: they change for different reasons, at different rhythms, and infrastructure work stays orchestrated rather than continuous, with manual validation where the blast radius is wide. And the deployment strategy can be chosen per feature, in configuration, from a small catalogue of strategies each with its own ease of recovery. CI/CD is not a box to tick; it is a reliable, traceable execution frame, built progressively and on shared standards.

Key ideas

• A pipeline is CI/CD only if it starts on every change by itself, stops on any failed test, quality or security check, and deploys with a strategy that allows a rollback.
• Settle the architecture, the persistence layer, the quality controls and the deployment strategy first, or the pipeline ships errors faster than value.
• The persistence layer is the forgotten risk because it is often irreversible: version the schemas, keep old consumers alive, delete logically before deleting physically.
• Application and infrastructure deserve separate pipelines: different triggers, different content, different cadences, and manual validation where the impact is wide.
• The deployment strategy can be selected per feature in configuration, among recreate, rolling update, Blue/Green, feature toggle, canary, A/B testing and shadow release.

Why I wrote this