GitOps

The entire desired state of the system—including applications, infrastructure, and policies—is declaratively described in files (e.g., YAML, JSON) stored in a Git repository. This is the single source of truth. Instead of imperative commands ("run this, then that"), the system specifies what the end-state should be, not how to achieve it. This enables version control, audit trails, and reproducibility for the entire operational environment.

Git provides the canonical, immutable version history for the system's desired state. Every change is a commit with a unique hash, author, timestamp, and message. This creates a complete audit trail for compliance and enables powerful operations:

• Rollback: Revert to any previous known-good state instantly.
• Blame/Investigation: Trace any configuration change to its origin.
• Peer Review: All changes flow through pull requests, enforcing code review and collaboration before deployment.

A dedicated controller agent (e.g., Flux, Argo CD) runs in the target environment. It continuously:

1. Pulls the desired state from the Git repository.
2. Observes the actual, live state of the system (e.g., in a Kubernetes cluster).
3. Compares the two states.
4. Takes action to reconcile any drift, automatically applying changes to make the live state match the declared state in Git. This creates a self-healing loop that corrects unauthorized changes or failures without human intervention.

The pull-based model is a key security and stability differentiator. The deployment agent inside the cluster pulls updates from the Git repo, rather than an external CI/CD server pushing changes. This offers critical advantages:

• Enhanced Security: The cluster does not need inbound write access; it fetches updates using its own credentials.
• Improved Stability: The agent only applies changes it has successfully fetched and validated, acting as a circuit breaker against faulty deployment pipelines.
• Environment Consistency: The same agent and process work identically across development, staging, and production.

The system provides continuous feedback on the reconciliation process. The controller monitors application health and emits events and metrics, answering key questions:

• Is the system in sync? (Sync status)
• Is the deployed application healthy? (Health status)
• What was deployed, when, and by whom? (Audit log) This observability is typically surfaced in dashboards (like the Argo CD UI) and integrated into monitoring systems, making the state of deployments and their compliance with Git explicit and verifiable.

This is the primary implementation pattern in Kubernetes. A custom controller (the "operator") is installed in the cluster. It watches for changes to Custom Resources (CRs) in the Kubernetes API. These CRs, which are also stored in Git, declaratively describe an application's source (Git repo, Helm chart) and destination (target cluster/namespace). The operator then manages the full lifecycle—deployment, health monitoring, and state reconciliation—of that application based on the CR's specification. This pattern extends Kubernetes' native declarative API to manage complex applications.

The reconciliation loop is the core control mechanism in GitOps and declarative systems like Kubernetes. It is a continuous process where a controller observes the actual, live state of a system (e.g., a Kubernetes cluster) and compares it to the declared desired state stored in Git. If a drift is detected, the controller automatically takes corrective actions—such as creating, updating, or deleting resources—to converge the live state with the declared state. This loop enables the self-healing property central to GitOps, as it automatically corrects configuration errors, manual changes, or failed deployments without human intervention.

Immutable infrastructure is a deployment model where servers, containers, or application artifacts are never modified in-place after they are deployed. Instead of patching or updating a running instance, changes are made by building a new, versioned artifact (like a container image) from the source of truth in Git and then replacing the entire old instance with the new one. This pattern is foundational to GitOps because:

• It guarantees that the deployed state exactly matches the version-controlled source.
• It eliminates configuration drift caused by ad-hoc server changes.
• It enables rollbacks by simply redeploying a previous, known-good artifact version.
• It works seamlessly with the reconciliation loop to replace non-conforming resources.

Declarative configuration is a paradigm where you define the desired end state of a system (the what), rather than writing step-by-step instructions to achieve it (the how). In GitOps, all infrastructure and application configurations—Kubernetes manifests, Helm charts, Terraform HCL—are written declaratively and stored in Git. Key characteristics include:

• Idempotency: Applying the same configuration multiple times yields the same result.
• Statefulness: The system's controller is responsible for figuring out the operations needed to reach the declared state.
• Version Control Friendliness: Declarative files are ideal for diffing, reviewing, and rolling back in Git. This contrasts with imperative commands (e.g., kubectl run), which are instructions for a one-time action and are not suitable as a source of truth.

Infrastructure as Code is the practice of managing and provisioning computing infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. GitOps can be viewed as an evolution of IaC principles applied to operations and deployment. While traditional IaC tools (like Terraform, Ansible, Pulumi) define infrastructure, GitOps adds a rigorous operational layer:

• Git as the Single Source of Truth: All IaC definitions must be in a Git repository.
• Automated Reconciliation: The IaC is not just applied manually; a controller automatically applies it and enforces it continuously.
• Extended Scope: GitOps applies IaC principles not just to servers and networks, but to the full application deployment (Kubernetes resources, service meshes, etc.).

Continuous Delivery is a software engineering approach where teams produce software in short cycles, ensuring that the software can be reliably released at any time. GitOps operationalizes and automates the deployment aspect of a CD pipeline. In a GitOps workflow:

• The CD pipeline's output is a declarative configuration change committed to Git (e.g., updating a container image tag in a YAML file).
• The Git commit acts as the release trigger. A separate, automated process (the GitOps operator) detects this change and deploys it to the target environments.
• This decouples the build/test stages (CI) from the deploy/reconcile stage (CD), making the deployment process auditable, reversible, and consistent across all environments (dev, staging, production).

A canary deployment is a release strategy where a new version of an application is deployed to a small, selected subset of users or servers (the "canary") before rolling it out to the entire infrastructure. GitOps tools and patterns provide a structured, declarative way to manage canary releases:

• Canary configuration (traffic split rules, pod selectors) is defined declaratively in Git.
• A GitOps controller (like Flagger with Flux) watches for new image versions in Git.
• It automatically orchestrates the canary rollout, gradually shifting traffic while analyzing key metrics for success (latency, error rate).
• Based on the metrics, the controller can automatically promote the canary to a full rollout or roll it back—all by updating the desired state in Git. This integrates progressive delivery directly into the GitOps reconciliation cycle.