GitOps

The entire desired state of the system—including infrastructure, applications, and configurations—is declaratively described in files (e.g., YAML, JSON). This state is stored in a Git repository. Instead of imperative commands ("run this, then that"), the system is defined by its end goal. An automated operator continuously compares this declared state against the observed state of the live system and reconciles any differences.

• Key Benefit: Provides a complete, versioned history of all changes to the system.
• Example: A Kubernetes deployment is defined by a deployment.yaml file specifying the container image, number of replicas, and resource limits.

A Git repository serves as the canonical, authoritative source for the system's desired state. All changes to the operational environment must originate as a commit to this repository. This principle enforces immutable infrastructure, where changes are made by proposing updates to the Git repo (via pull/merge requests), not by directly modifying running systems.

• Key Benefit: Enables audit trails, peer review via pull requests, and easy rollback to any previous known-good state by reverting a commit.
• Workflow: Developers and operators propose changes via Git, which triggers automated validation and deployment pipelines.

A dedicated controller or operator software agent runs in the target environment (e.g., a Kubernetes cluster). This agent continuously observes the live state of the system and pulls the desired state from the Git repository. It then performs a diff and automatically applies any necessary changes to align the live state with the declared state. This is often called the pull-based model.

• Key Benefit: Ensures self-healing and drift prevention. If the live state is manually altered, the operator will detect the drift and revert it to match Git.
• Common Tools: Flux CD and ArgoCD are popular GitOps operators that implement this reconciliation loop.

The Git repository is integrated into a Continuous Delivery (CD) pipeline. When a new commit is merged to the main branch (or a specific environment branch), it automatically triggers the deployment process. The GitOps operator detects the new state and applies it. This makes the software delivery process observable, repeatable, and traceable directly through Git history.

• Key Benefit: Separates the deployment mechanism from the release decision. Merging to a branch is the act of deployment.
• Practice: Uses environment-specific branches or directories (e.g., ./prod/, ./staging/) to manage promotion of changes.

GitOps promotes the practice of immutable infrastructure. Instead of patching or updating existing servers, new deployments create entirely new, versioned artifacts from the Git commit. In cloud-native contexts, this means deploying new container images with updated tags, not modifying containers in-place. The Git commit hash or tag becomes the immutable version identifier for the entire system state.

• Key Benefit: Eliminates configuration drift and ensures deployments are idempotent and consistent.
• Example: A Kubernetes deployment manifest is updated to point from my-app:1.0.0 to my-app:1.1.0. The operator rolls out the new pods and terminates the old ones.

The GitOps workflow creates a closed feedback loop. The status of the reconciliation process (success, failure, in-progress) and the health of the deployed application are fed back into the Git repository or associated systems. This is often visualized through status badges, commit statuses, or comments on pull requests. Observability tools monitor the live system, and alerts can trigger actions or create issues in the Git repository.

• Key Benefit: Provides operational transparency. Teams can see if the deployed state matches Git and diagnose failures directly linked to a specific code change.
• Integration: Operators like Flux can write back health statuses and alert using tools like Prometheus and Slack.

Infrastructure as Code (IaC) is the foundational practice of defining and provisioning computing infrastructure using machine-readable definition files, rather than manual processes. It enables version control, consistency, and repeatability. GitOps builds upon IaC by using Git as the single source of truth for these definitions and automating their application.

• Core Tools: Terraform, AWS CloudFormation, Pulumi.
• Key Principle: Treat infrastructure like software—versioned, tested, and modular.

CI/CD is a set of practices that automate the software delivery pipeline. Continuous Integration merges code changes frequently with automated testing. Continuous Deployment automates the release of those changes to production. GitOps is often described as a CD implementation pattern, where the Git repository state drives automated deployments, decoupling the deployment mechanism from the development pipeline.

• Pipeline vs. Pull: Traditional CI/CD uses a push model; GitOps often uses a pull model via an operator.

Configuration Drift is the undesirable divergence between the intended, declared state of a system and its actual, running state. It occurs due to manual hotfixes, ad-hoc commands, or inconsistent updates. A primary goal of GitOps is to eliminate configuration drift through declarative management and automated reconciliation. The Git repository serves as the authoritative record, and any divergence is automatically detected and corrected.

• Detection: GitOps operators continuously compare cluster state to Git.
• Remediation: Automated rollback or sync to the declared state.

Declarative Configuration is a paradigm where you specify the desired end state of a system, rather than the sequence of commands (imperative) to achieve it. The system's control plane is responsible for determining and executing the necessary actions. This is the core abstraction enabling GitOps. All infrastructure and application specs are stored as declarative manifests (e.g., Kubernetes YAML, Terraform HCL) in Git.

• Example: A Kubernetes Deployment manifest declares replicas: 3. The system ensures three pods run.
• Benefit: Idempotency—applying the same configuration repeatedly yields the same result.

The Operator Pattern is a method of extending Kubernetes to automate the management of complex, stateful applications. An Operator uses Custom Resource Definitions (CRDs) and a custom controller to encode human operational knowledge (like backups or upgrades) into software. GitOps tools like Flux and Argo CD are themselves implemented as Kubernetes Operators. They watch Git repositories and use Kubernetes' API to reconcile the cluster's state.

• How it works: 1) Watch a Git repo. 2) Detect changes. 3) Calculate diff. 4) Apply changes via K8s API.