Continuous Delivery and GitOps: CNPA practice questions

GitOps is one way of doing continuous delivery, and in Kubernetes-based platforms it is the most common one. Continuous delivery is the goal: DORA defines it as the ability to release changes of all kinds on demand, quickly, safely and sustainably. GitOps is a set of operating principles for reaching that goal, in which the desired state of the system lives in a versioned store such as Git and software agents keep the running system in line with it.

The OpenGitOps project publishes four principles in its version 1.0.0. Declarative: a system managed by GitOps must have its desired state expressed declaratively. Versioned and immutable: desired state is stored in a way that enforces immutability and versioning and retains a complete version history. Pulled automatically: software agents automatically pull the desired state declarations from the source. Continuously reconciled: software agents continuously observe actual system state and attempt to apply the desired state. Each principle matters on its own. Without the history you cannot audit or roll back; without automatic pulling a person or a pipeline has to push changes in; without continuous reconciliation, manual edits in the cluster quietly become the real state.

Argo CD and Flux implement these principles for Kubernetes. Argo CD describes itself as a declarative, GitOps continuous delivery tool and runs as a controller that compares the live state of each application with the target state in Git, marking it OutOfSync when they differ and syncing it automatically or on request. Flux defines GitOps as describing the whole system declaratively under version control, with an automated process that makes the deployed environment match the state in one or more repositories; its sources fetch from Git repositories, OCI repositories, Helm repositories and buckets, and its Kustomization and HelmRelease reconcilers apply what was fetched. Flux also describes what it calls Gitless GitOps, in which OCI registries hold the configuration artifacts while Git stays the authoring interface.

Progressive delivery extends continuous delivery by rolling a change out gradually to a subset of users and watching it before releasing to everyone. Canary and blue-green releases are the usual patterns. Argo Rollouts provides them as a Kubernetes controller with its own custom resources, Flagger offers canary releases alongside Flux, and Argo CD's PreSync, Sync and PostSync hooks can support such rollouts.

Misconceptions are common. GitOps does not strictly require Git; the principles talk about a versioned, immutable source. GitOps does not replace CI: images are still built and tested by pipelines, and GitOps takes over at deployment. Continuous delivery is also not the same as continuous deployment, which DORA describes as deploying every change to production as soon as possible. And storing YAML in a repository is not GitOps by itself if a pipeline still pushes it with kubectl and nothing corrects drift.

At associate level, expect to name or recognize the four principles, to distinguish the pull model from push-based deployment, and to identify what an agent does when the live state differs from the declared state.