Designing a CI/CD pipeline developers will not route around
A pipeline succeeds when it is fast enough to trust and strict enough to matter. Getting that balance wrong is why teams disable checks.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Desired state in version control, reconciled continuously by an agent.
- Audit trail and rollback come free from the version control model.
- Pull-based deployment removes credentials from the pipeline.
- Secrets and environment promotion need deliberate design.
The core idea
Desired state lives in a repository. An agent running in the target environment continuously compares actual state against it and reconciles any difference.
This makes deployment a merge rather than a command, which means every change is reviewed, attributed and revertible through the same mechanism as code.
What it gives you
- An audit trail that exists by construction rather than by discipline.
- Rollback as a revert, using a mechanism the team already knows.
- Drift correction — manual changes are reverted automatically.
- No deployment credentials in the pipeline, because the agent pulls rather than the pipeline pushing.
That last point is a genuine security improvement that is easy to overlook.
Where it gets awkward
Secrets need a solution, because plain values cannot sit in the repository — sealed secrets or an external store with references. Promotion between environments needs a deliberate structure rather than copying files around.
And automatic drift correction, while usually desirable, can fight an engineer making an emergency change. Decide in advance how that is handled.
Whether it suits you
GitOps fits declarative targets well, Kubernetes especially. It fits less naturally where deployment is imperative or where the platform has no reconciliation agent.
For teams already comfortable with pull requests and code review, the model tends to feel natural quickly, because it reuses habits they already have.
Structuring environments and promotion
The most common early difficulty is how to promote a change from one environment to the next without copying files by hand or maintaining three divergent copies of everything.
A workable structure keeps a shared base configuration with per-environment overlays holding only genuine differences. Promotion becomes updating an image reference in the next environment's overlay, which is reviewable and revertible.
Avoid branching per environment. It looks tidy and produces merge conflicts and drift, because environments then differ by whatever failed to merge rather than by intent.
Frequently asked questions
It is most mature there because Kubernetes is declarative and has reconciliation built in. The principles apply elsewhere, but tooling is thinner.
Separating application code from deployment manifests is common and keeps concerns clear. A single repository is simpler for small teams. Both work; consistency matters more than the choice.
Define the path in advance: either make the change and immediately reconcile it back into the repository, or temporarily suspend reconciliation for that component. Undocumented emergency changes are what GitOps is designed to eliminate.
