> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Continuous Delivery GitOps
> Overview of GitOps with Argo CD, a Git‑centric pull based continuous delivery approach for Kubernetes covering reconciliation, repository patterns, security, rollbacks, and platform practices.
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.
## 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:
```yaml theme={null}
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.
## Deployment manifests are reconciled
Any Kubernetes manifest stored in the repo is compared and applied by Argo CD. Example Deployment manifest reconciled from Git:
```yaml theme={null}
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):
1. Poll the configured Git repository for changes.
2. Compare desired state (Git) with actual cluster state.
3. Detect drift or differences.
4. Sync resources (apply manifests) to remove drift.
5. Perform post-sync health checks and report status.
Argo CD’s UI shows sync status, diff views, and a deployment history — useful for troubleshooting and audits.
## 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.
## 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).
## 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.
## 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.
## 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/](https://argo-cd.readthedocs.io/)
* GitOps concepts: [https://www.weave.works/technologies/gitops/](https://www.weave.works/technologies/gitops/)
* Kubernetes documentation: [https://kubernetes.io/docs/](https://kubernetes.io/docs/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.