CI/CD Theatre

I often hear engineers complain about inefficiencies in their pipelines. And they’re right — most companies that claim to do “CI/CD” (and even demand it in job specs) aren’t actually doing either.

CI means integrating into trunk several times a day. CD means always keeping the system in a releasable state. Both exist to help us go to production often.

CD doesn’t always mean every commit hits production, but if releases don’t happen in a continuous way, those practices lose their meaning.

CI is not feature branches that live in isolation for weeks before a big merge. CD is not a pipeline that builds artefacts rarely deployed to production.

If our test suite takes an hour to run, whether we shave it down to 5 minutes or not barely matters if new features sit on a shelf for weeks (or even months) before reaching a customer. In fact, over-optimising a process to pile up features that don’t ship can do more harm than good.

If our North Star becomes delivering to production as often as we can, then every other optimisation will be a natural consequence of that.

The real goal is simple: deliver value to customers continuously. Build with them, release often, get feedback, adapt, repeat.

Without that, what we call “CI/CD” is just theatre.

Originally posted on LinkedIn.