GitOps and CI/CD
Continuous integration vs continuous delivery vs continuous deployment, infrastructure as code, the four OpenGitOps principles, push vs pull deployment, and how Argo CD and Flux implement GitOps.
Exam tasks: 3.1 (application delivery: CI/CD, GitOps, push vs pull, Argo CD and Flux)
The decision: who applies a change to the cluster, a pipeline pushing it or an agent pulling it from Git, and what keeps the cluster matching what Git says?
CI, CD and CD
| Term | What it automates | Who presses "go" for production |
|---|---|---|
| Continuous integration (CI) | Merge often, then build, unit test, lint and scan every change. Output: a tested artifact, such as an image | Nobody deploys yet |
| Continuous delivery | Every change that passes CI is kept releasable and can reach staging automatically | A human approves the production release |
| Continuous deployment | Every change that passes the pipeline goes all the way to production | Nobody: it's automatic |
- DevOps is the culture behind this: one team owns code from commit to production, with feedback from monitoring flowing back into planning. CI/CD is the toolchain that makes that loop fast.
- Shift left means moving testing, security scanning and policy checks earlier in the pipeline, where failures are cheap to fix.
- Common CI tools: GitHub Actions, GitLab CI, Jenkins, Tekton (a CD Foundation project). In the CNCF, Argo Workflows runs pipelines as Kubernetes-native workflows.
Exam signal
"Code is always in a deployable state but production releases are approved manually" is continuous delivery. "Every merged change reaches production with no manual step" is continuous deployment. The acronym CD covers both, so read the wording.
Infrastructure as code and declarative config
- Infrastructure as code (IaC) keeps infrastructure definitions in versioned files rather than in console clicks or one-off scripts. Examples: Terraform or OpenTofu, Pulumi, Crossplane (CNCF), Ansible.
- Declarative config states the end result ("three replicas of
orbit-api:2.4"). Imperative config lists steps ("scale to three, then set the image"). Kubernetes manifests are declarative, and controllers work out the steps. - GitOps applies the same idea to the whole delivery process: Git holds the declarative desired state, and software converges the cluster onto it.
The four GitOps principles
The OpenGitOps project (a CNCF sandbox project from the GitOps Working Group) defines GitOps with four principles. Learn them by name.
| Principle | Meaning | What breaks it |
|---|---|---|
| 1. Declarative | The system's desired state is expressed declaratively | Shell scripts that run kubectl scale or kubectl set image |
| 2. Versioned and immutable | Desired state is stored so that it's versioned, immutable and keeps a complete history | Editing manifests on a shared drive, or overwriting history |
| 3. Pulled automatically | Software agents pull the desired state from the source automatically | A pipeline pushing changes into the cluster |
| 4. Continuously reconciled | Agents keep observing actual state and act to match the desired state | Applying once and never checking for drift again |
- Git is the usual store, but the principles say "source", so an OCI registry holding manifests also counts.
- Rollback becomes
git revert: the agent sees the older desired state and applies it. - Audit comes free: every change to production is a reviewed commit with an author.
Push vs pull
| Push | Pull (GitOps) | |
|---|---|---|
| Who applies changes | The CI/CD pipeline | An agent running in the cluster |
| Cluster credentials | Stored in the pipeline, outside the cluster | Stay inside the cluster. CI only needs write access to Git |
Drift (someone runs kubectl edit) | Goes unnoticed until the next pipeline run | Detected and, with self-heal, reverted |
| Firewall | Pipeline needs inbound access to the API server | Agent only makes outbound calls to Git and the registry |
| Many clusters | One pipeline step per cluster | Each cluster's agent pulls its own config |
Pull means the cluster pulls images
Every Kubernetes cluster pulls container images from a registry: that's the kubelet's job, push or not. The GitOps "pull" is about the desired configuration: the agent fetches manifests from Git instead of a pipeline pushing them in.
Argo CD and Flux
Both are CNCF graduated, both run as controllers in the cluster, and both implement all four principles.
| Argo CD | Flux | |
|---|---|---|
| Parent project | Argo (also Workflows, Rollouts, Events) | Flux (also Flagger) |
| Core object | Application CRD: a source repo/path plus a destination cluster and namespace | GitRepository or OCIRepository source, applied by a Kustomization or HelmRelease |
| Design | One application with a web UI, CLI and SSO, built around applications | A set of small controllers (the GitOps Toolkit): source, kustomize, helm, notification, image automation |
| Status it shows | Sync status (Synced / OutOfSync) and health (Healthy, Progressing, Degraded, Missing) | Ready conditions on each object, events and alerts |
| Many apps or clusters | ApplicationSet generates Applications from a template | One Kustomization per cluster path, often bootstrapped with flux bootstrap |
| Renders | Plain YAML, Kustomize, Helm, Jsonnet | Plain YAML, Kustomize, Helm |
- Auto-sync applies new commits automatically. Self-heal reverts manual changes in the cluster. Prune deletes objects that were removed from Git. Without prune, deleted files leave orphans behind.
- Flux's image automation controllers can watch a registry and commit a new image tag back to Git, so the change still flows through Git rather than straight into the cluster.
Exam signal
"Visual dashboard showing which apps are OutOfSync" leans Argo CD. "Composable toolkit of controllers" leans Flux. If the question just says "a CNCF graduated GitOps tool", both are right, so look for the option that names one of them and not Jenkins, Helm or Terraform.
Helm as a GitOps tool
Helm packages and templates manifests, and helm upgrade from a pipeline is a push. Helm isn't a GitOps
agent. Argo CD and Flux can render Helm charts, which is how Helm fits into a GitOps setup.
A typical GitOps flow
- A developer merges a change to the app repo. CI builds
registry.example.com/lumen/checkout:1.8.0, runs tests and pushes the image. - CI (or Flux image automation) opens a pull request in the config repo that changes the image tag.
- A reviewer merges it. That merge is the deployment approval.
- The agent notices the new commit, renders the manifests and applies them. The Deployment rolls out.
- Someone hot-fixes replicas with
kubectl scale. The agent marks the app OutOfSync and, with self-heal on, puts it back.
Keeping app code and deployment config in separate repos is a common pattern: CI writes to config, and only the agent writes to the cluster.
Scenarios
The manifests are already declarative and versioned in Git, so the first two principles hold. What's missing is an agent that keeps comparing the cluster with Git and fixes drift, which is continuous reconciliation (and, with it, pulling automatically instead of a one-shot push). Shift left is a testing practice, not a GitOps principle.
In the pull model the agent runs inside the cluster and uses its own in-cluster identity, so CI only needs access to Git. Encrypting the kubeconfig still gives CI cluster credentials. Exposing the API server makes the problem worse. Manual applies from laptops spread credentials further and lose the audit trail.
Continuous deployment removes the manual production gate. Building and testing each commit is continuous integration. Being always deployable with a human deciding when to ship is continuous delivery. Version-controlled infrastructure files are infrastructure as code.
Further reading
Domain 3 · Cloud native application delivery
16% of the exam. How code becomes a running workload through CI/CD and GitOps, how it's packaged with Helm or Kustomize, how releases roll out safely, and how you debug what's running.
Packaging and rollouts
Helm charts, values and releases vs Kustomize bases and overlays, Deployment rolling updates and rollback, blue/green and canary releases, and progressive delivery with Argo Rollouts and Flagger.