GitOps

The entire desired state of the system—including infrastructure, applications, and configuration—is declaratively described in files (e.g., YAML, JSON) stored in a Git repository. This contrasts with imperative commands, which specify how to achieve a state. The repository acts as the single source of truth, providing a complete, versioned history of all changes.

• Example: Kubernetes manifests defining deployments, services, and config maps.
• Benefit: Enables reproducibility, auditability, and rollback to any previous known-good state.

A dedicated controller or operator (e.g., Flux, Argo CD) runs in the target environment, continuously comparing the live state of the cluster with the desired state declared in Git. When a drift is detected, the controller automatically takes action to reconcile the live state to match Git. This creates a closed feedback loop, ensuring the system self-heals and converges on the declared configuration.

• Pull vs. Push: In the pull model, the controller fetches changes from Git, enhancing security by not requiring write access to the cluster from external CI/CD systems.

All changes to the system must be initiated via Git operations (commit, push, merge, revert). This centralizes all change management, making Git the approval and workflow engine. Developers use familiar tools like pull requests, code reviews, and branch protection rules to manage deployments. The Git history provides a full audit trail of who changed what, when, and why.

• Process: A developer modifies a YAML file in a feature branch, opens a PR, gets approval, and merges to main. The controller detects the merge and applies the change.

Because the desired state is versioned and changes are automated, continuous delivery becomes a natural outcome. Every approved merge to the main branch can trigger a deployment. If a deployment causes issues, rollback is performed by reverting the Git commit to a previous version. The controller will then automatically revert the live state to match, providing a fast and reliable recovery mechanism.

• Key Distinction: This separates the deployment mechanism (the controller) from the release decision (the Git merge), enabling safer, more controlled releases.

A core security and robustness pattern where an agent deployed inside the cluster actively pulls updates from the Git repository. This model:

• Enhances Security: The cluster does not need inbound firewall rules; the Git repo only needs to be readable.
• Improves Reliability: The agent is responsible for its own synchronization, making the system more resilient to external CI/CD service outages.
• Enables Multi-Cluster Management: A single Git repo can serve as the source of truth for many clusters, each with its own agent pulling the relevant configuration.

GitOps extends beyond deployment to include observability of the applied state. The controller monitors the health of deployed resources (e.g., pod status, service availability). Health status can be reported back to the Git repository or a dashboard. This creates a verification loop, ensuring not only that manifests were applied, but that the application is running correctly.

• Integration: Often integrates with Prometheus for metrics and Alertmanager for notifications if the deployed state becomes unhealthy, closing the full observe-orient-decide-act (OODA) loop.

This pattern defines how the desired state is applied to the runtime environment. Pull-based is the canonical GitOps model, while push-based is a common hybrid approach.

• Pull-Based (Agent Inside): An operator (e.g., Flux) inside the cluster periodically pulls changes from Git and applies them. This enhances security as the cluster does not need inbound write permissions.
• Push-Based (CI-Driven): A CI pipeline (e.g., Jenkins, GitHub Actions) pushes changes to the cluster after merging to Git. This is easier to start with but dilutes the GitOps principle by making the CI system, not Git, the direct deployment trigger.

GitOps manages progression through environments (dev, staging, prod) using Git workflows. The desired state for each environment is defined in version-controlled branches or directories.

• Branch-per-Environment: Each environment (e.g., main, staging) maps to a Git branch. Promotion is achieved via pull/merge requests between branches.
• Directory-per-Environment: A single branch (e.g., main) contains separate directories (/dev, /staging, /prod) with environment-specific configs. Promotion is done by copying or kustomizing manifests between directories.
• Tag-based Promotion: A single manifest source is promoted by applying different Git tags, which are referenced by the GitOps operator.

GitOps repositories store declarative manifests. Kustomize and Helm are the dominant tools for managing and templating these YAML configurations.

• Kustomize: A native Kubernetes tool for customizing raw, template-free YAML files using overlays and patches. It follows a declarative patch model.
• Helm: A package manager for Kubernetes that uses templated YAML files (charts). The GitOps operator (Flux/Argo CD) renders the Helm charts, keeping the rendered templates out of Git, storing only values and chart references.
• Best Practice: Store only the minimal configuration (Kustomize patches, Helm values) in Git, not generated YAML.

A core GitOps benefit is automatic drift detection—identifying when the live cluster state diverges from the Git-defined desired state.

• How it Works: The GitOps operator continuously performs a reconciliation loop, comparing the live state to the source in Git.
• Alerting: Tools like Flux and Argo CD can emit Kubernetes events and metrics, which can be integrated with Prometheus and Alertmanager.
• Response: The operator will automatically revert drift if configured for auto-reconciliation, or it will flag the state as OutOfSync for manual intervention.
• Audit Trail: Every change and sync event is logged with the Git commit SHA, providing a complete audit trail.

Continuous Deployment (CD) is the automated process of delivering software changes to production after passing automated tests. GitOps operationalizes CD for both application and infrastructure changes by using Git pull requests as the deployment mechanism. The Git repository defines the desired state, and automated operators (like Flux or Argo CD) continuously synchronize the cluster to match it.

• GitOps vs. Traditional CD: In GitOps, the deployment control loop is pull-based from the cluster, enhancing security and auditability, whereas traditional CD often uses push-based pipelines.

Declarative Configuration is a paradigm where a user specifies the desired end state of a system, and a separate controller is responsible for realizing and maintaining that state. This contrasts with imperative configuration, where the user specifies the exact sequence of commands to execute. GitOps is fundamentally declarative.

• Example: A Kubernetes YAML manifest declares that 5 replicas of a pod should run. The GitOps operator ensures there are always 5, automatically replacing failed instances.
• Benefit: The system becomes self-healing and drift-resistant.

Immutable Infrastructure is a model where deployed components (servers, containers) are never modified after creation. Updates are performed by replacing the entire component with a new version built from a validated image. GitOps strongly aligns with this pattern. The Git commit hash serves as the immutable reference for the desired state, and rolling out a change means deploying a new, versioned set of artifacts.

• Advantage: Eliminates configuration drift, simplifies rollback (revert to a previous Git commit), and ensures consistency from development to production.