What is one CI/CD design principle that makes a huge difference?

What is one CI/CD design principle that makes a huge difference?

Blog

I’ve been designing and running CI/CD pipelines for a long time and there’s one principle that makes it so much easier. I wish I had learnt it earlier - it would have saved me so much time!

We’re spoiled for choice with amazing CI/CD engines these days! (Jenkins, GitLab CI, GitHub Actions, you name it). They’re packed with features, DSLs, plugins, and addons… but sometimes, all that power actually makes things worse.

The big problem? Many pipelines treat every change as a full, linear run. Later stages depend on previous ones, making it super hard to iterate, debug, or even add unit tests!
It’s like a domino effect – one small tweak requires rerunning the entire thing.

So, what’s the solution? Keep it simple:

👉 The core principle is to use your CI/CD engine for orchestrating independent steps – steps that could be launched locally, like shell or Python scripts.
Treat the CI/CD system as an orchestrator, not a black box for everything.

Think small, modular, and self-contained units. If you use container images, then ideally build process should be the same when run in CI/CD or on local machine.
By designing your pipelines this way, you gain massive flexibility, testability, and portability.

What do you think? Is this the key to CI/CD sanity? What are your go-to principles for building maintainable pipelines? Share your thoughts in the comments! 👇

Comments