GitOps.dk

Self-Evolving Delivery: GitOps Beyond CI/CD

Notes on moving from pipelines that push to systems that reconcile, heal and promote themselves.

GitOps.dk

CI/CD answered a question from a previous era: how do we get code from a laptop to production reliably? GitOps answers the question this era is actually asking: how does the system keep itself in the state we declared, without humans in the loop?

Push is a liability

Every push-based pipeline holds production credentials and makes imperative changes. It is, in effect, a standing privilege and a standing source of drift. Reconciliation flips the model: the cluster pulls its desired state from Git and continuously closes the gap between what is and what should be.

Self-healing as a side effect

Once desired state lives in Git and a controller enforces it, self-healing is no longer a feature you build — it is a property you get. Manual changes are reverted. Drift is surfaced as a diff. The audit trail is the commit history.

Progressive, policy-driven promotion

The next step beyond reconciliation is letting the system promote itself: canaries judged by SLOs, promotions gated by policy-as-code, rollbacks triggered by signals rather than people. This is where delivery stops being a process and becomes a control system.

  • Git as the single source of truth for app and infra.
  • Policy-as-code as the gate, not a wiki page.
  • SLOs as the promotion signal, not a release manager's calendar.

What this demands of you

Self-evolving delivery is less a toolchain and more a discipline: everything-as-code, small reversible changes, and the humility to let the system do the work humans were never good at.

Turning these ideas into a platform?

For platforms where failure has consequences.

Start an Architecture Conversation