Continuous Delivery GitOps

In this lesson we cover GitOps with Argo CD: the Git-centric, pull-based pattern for continuous delivery that platform engineering teams use to deliver reliable, auditable, and repeatable Kubernetes deployments. You’ll learn core concepts, the Argo CD architecture, repository organization patterns, security and rollback benefits, and how the reconciliation loop maintains the desired cluster state. GitOps treats a Git repository as the single source of truth for infrastructure, Kubernetes manifests, and deployment configuration. Git provides versioning, an auditable change history, and familiar collaboration workflows for both development and operations teams.

What belongs in Git

Kubernetes manifests (YAML, Helm charts, Kustomize overlays).
Environment-specific configuration (dev, staging, production).
Policies, RBAC configuration, and promotion workflows.

For example, the Sparkle Pony Ranch (SPR) platform objectives are reliable, repeatable deployments across dev/staging/production; full audit trails of who changed what; and low operational friction. These are delivered by storing declarative configuration in Git and letting a reconciler continuously enforce that desired state.

Reconciliation loop (pull-based model)

The reconciliation loop is central to GitOps: a reconciler continuously compares the desired state in Git against the actual cluster state and corrects any drift. This is usually a pull model — an in-cluster controller or agent reads Git and applies changes — which contrasts with traditional push-based CI/CD where pipelines need external cluster access. Benefits of the pull/reconciler model:

Less exposed cluster surface area (no external push access needed).
Continuous enforcement of declared state and automatic drift correction.
Clear audit trail through Git history and easier rollbacks.

A slide titled "GitOps vs Traditional Deployment Models" comparing Traditional CI/CD (push model) on the left with GitOps (pull model) on the right. The bullets note push pipelines require external cluster access and are hard to audit/rollback, while GitOps agents pull state from Git, need no external access, and provide an audit trail with easy rollbacks.

Argo CD overview

Argo CD is a CNCF‑graduated GitOps continuous delivery tool for Kubernetes. It is Kubernetes-native, declarative, and Git-driven, and it offers a Web UI and CLI, multi-cluster support, and multiple operating modes for different organizational needs.

Argo CD core components

Component	Responsibility
API server / Web UI	User and automation interaction (REST API, dashboard)
Repository server	Clones and reads Git repositories; prepares manifests
Controller	Runs the reconciliation loop and applies changes to clusters
Identity/SSO (Dex, OIDC, etc.)	Optional authentication and SSO integration

Argo CD Application resource

An Argo CD Application is the declarative object that maps a repository path to a target Kubernetes cluster and namespace. It declares the repoURL, path to manifests, targetRevision (branch/tag), and destination. Example minimal Application for the pony-spawner service:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: pony-spawner
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/spr/pony-services
    path: pony-spawner/manifests
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production

Developers commit code and CI produces artifacts (images, charts). The GitOps repo holds the desired manifests (which typically reference built artifacts). Argo CD watches Git, detects changes, and syncs the cluster to match the declared state. Sync can be manual (safe default) or automatic when teams are confident in automation and monitoring.

Team roles in a GitOps workflow

Role	Typical responsibilities
Developers	Write application code; update manifests or image tags in Git
Platform / GitOps owners	Manage Argo CD, repository layout, RBAC, and platform patterns
SRE / Ops	Monitor cluster health, respond to incidents, execute rollbacks if needed

Repository layout and environment separation

Common patterns:

Single repo with environment directories:
- services/foo/dev, services/foo/prod
One repo per environment for strict isolation.
Per-service repositories with shared charts/bases.
Use shared Kustomize bases, Helm charts, or reusable templates to avoid duplication.
Enforce RBAC so teams can push to dev but require approvals for production changes.

A presentation slide titled "GitOps Repository Organization" with a section called "Access Control Benefits." It lists benefits like teams having different permissions per environment, extra approvals for production changes, and clear audit trails for compliance.

Deployment manifests are reconciled

Any Kubernetes manifest stored in the repo is compared and applied by Argo CD. Example Deployment manifest reconciled from Git:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pony-spawner
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pony-spawner
  template:
    metadata:
      labels:
        app: pony-spawner
    spec:
      containers:
      - name: pony-spawner
        image: registry.spr.com/pony-spawner:v2.1.0
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"

Reconciliation process (high level):

Poll the configured Git repository for changes.
Compare desired state (Git) with actual cluster state.
Detect drift or differences.
Sync resources (apply manifests) to remove drift.
Perform post-sync health checks and report status.

A slide titled "How ArgoCD Maintains the Desired State" showing the "Reconciliation Process." It displays a five-step timeline: Poll Git Repository, Compare States, Detect Drift, Sync Resources, and Health Check.

Argo CD’s UI shows sync status, diff views, and a deployment history — useful for troubleshooting and audits.

A presentation slide titled "ArgoCD User Interface – Features" showing two UI screenshots labeled "Sync Status" and "History," describing real-time deployment state info and complete deployment/rollback history.

Managing multiple environments

Options to structure environments and promote changes:

Strategy	Description	Trade-offs
Separate Applications	One Argo CD Application per environment	Clear separation; more objects to manage
Different Git paths	Environment-specific manifest directories in same repo	Easier promotion; risk of accidental cross-env changes
Promotion workflow	Move changes through dev → staging → production with CI checks	Safer promotion but requires tooling/process

You can also run separate Argo CD instances per environment for full isolation or create a single central Argo CD that targets multiple clusters.

A presentation slide titled "Managing Multiple Environments With ArgoCD" showing an "Environment Strategy" with three colored options: "Separate Applications" (one ArgoCD application per environment), "Different Git Paths" (environment-specific manifest directories), and "Promotion Workflow" (changes flow through environments). The slide is branded © KodeKloud.

Security, governance, and policy enforcement

GitOps improves security and governance by:

Eliminating the need for direct cluster credentials for most developers.
Providing an auditable history of changes in Git.
Enabling RBAC at the repository and Argo CD levels.
Integrating policy gates (pre-commit checks, CI tests, policy-as-code, admission controllers).

A slide titled "GitOps With ArgoCD – Security Benefits" showing four numbered cards. The cards list No Direct Cluster Access, Complete Audit Trail, Role-Based Access, and Policy Enforcement with short explanatory text.

Rollbacks and recoverability

Rollbacks with GitOps are straightforward: revert to a known-good commit in Git and let Argo CD re-sync the cluster to that commit. This makes rollbacks auditable and reproducible. Note: application-level concerns such as database migrations still need careful planning and possibly specialized migration tooling.

A presentation slide titled "Easy Rollbacks With Git History" that outlines a four-step rollback process: Identify Issue, Find Last Good State, Revert Git Commit, and ArgoCD Auto-Sync. A gray footer notes "Phuong can quickly roll back pony spawning issues by reverting Git commits."

A presentation slide titled "Easy Rollbacks With Git History" showing a two-column comparison: a gray panel listing traditional rollback problems (complex procedures, DB migration concerns, configuration/state management, manual coordination) and a blue panel listing GitOps rollback advantages (single Git command, automatic coordination, audit trail, consistent procedures). Copyright KodeKloud appears at the bottom.

Platform engineering considerations

GitOps is often provided as a platform service: a central Argo CD instance (or a set of instances) enables self-service deployment while platform teams enforce standards and guardrails. Benefits include multi-cluster support, standardized application templates, and reduced operational ticketing. Agreeing early on repository layouts, RBAC, and promotion workflows reduces friction.

A presentation slide titled "GitOps as a Core Platform Service" with the heading "Self‑Service Benefits." It shows two numbered cards: "Teams can deploy independently" and "Platform team maintains centralized control."

Key takeaways

Git-driven: Git is the single source of truth for desired system state.
Pull-based: a reconciler continuously enforces the declared state (Argo CD is a common implementation).
Declarative: manifests express the desired state rather than imperative commands.
Continuous reconciliation: drift is detected and corrected automatically.

Value summary

Using GitOps with Argo CD:

Automates and standardizes deployments.
Improves reliability and observability.
Makes change history auditable and rollbacks simple.
Enables teams to deploy independently within platform guardrails.

Thanks for reading.

Remember: Be prepared to explain the difference between push-based CI/CD and pull-based GitOps, how the reconciliation loop works, and why storing the desired state in Git improves auditability and rollback safety.

Links and references

Argo CD documentation: https://argo-cd.readthedocs.io/
GitOps concepts: https://www.weave.works/technologies/gitops/
Kubernetes documentation: https://kubernetes.io/docs/

Pre-requisites

Domain 1 - Platform Engineering Core Fundamentals

Domain 2 - Platform Observability, Security, and Conformance

Domain 3 - Continuous Delivery & Platform Engineering

Domain 4 - Platform APIs and Provisioning Infrastructure

Domain 5 - Internal Developer Platforms & Developer Experience

Domain 6 - Measuring Your Platform

Mock Exams & Final Prep

Continuous Delivery GitOps

Reconciliation loop (pull-based model)

Argo CD overview

Argo CD Application resource

Team roles in a GitOps workflow

Repository layout and environment separation

Deployment manifests are reconciled

Managing multiple environments

Security, governance, and policy enforcement

Rollbacks and recoverability

Platform engineering considerations

Key takeaways

Value summary

Links and references

Watch Video

​Reconciliation loop (pull-based model)

​Argo CD overview

​Argo CD Application resource

​Team roles in a GitOps workflow

​Repository layout and environment separation

​Deployment manifests are reconciled

​Managing multiple environments

​Security, governance, and policy enforcement

​Rollbacks and recoverability

​Platform engineering considerations

​Key takeaways

​Value summary

​Links and references

Watch Video

Reconciliation loop (pull-based model)

Argo CD overview

Argo CD Application resource

Team roles in a GitOps workflow

Repository layout and environment separation

Deployment manifests are reconciled

Managing multiple environments

Security, governance, and policy enforcement

Rollbacks and recoverability

Platform engineering considerations

Key takeaways

Value summary

Links and references