GitOps

The entire desired state of a system—infrastructure, applications, network policies—is expressed declaratively as code stored in Git. Instead of imperative scripts that define how to achieve a state, declarative configs define what the state should be.

• Single Source of Truth: The Git repository is the sole authority for the desired state
• Version Controlled: Every configuration change is tracked with commit history, authorship, and timestamps
• Self-Documenting: The repo itself serves as living documentation of the system's intended architecture
• Example: A Kubernetes manifest declaring 3 replicas, specific resource limits, and a particular container image tag

A software agent (such as Flux or ArgoCD) continuously monitors both the Git repository and the live environment. When a drift is detected between the declared desired state and the actual running state, the agent automatically corrects the divergence.

• Convergence Guarantee: The system constantly pulls toward the declared state
• Self-Healing: Manual changes to live infrastructure are automatically reverted
• Drift Detection: Alerts are generated when the live state cannot be reconciled
• Idempotency: Applying the same configuration multiple times produces the same result

Unlike traditional push-based CI/CD where an external pipeline reaches into environments, GitOps uses a pull-based mechanism. The agent deployed inside the runtime cluster pulls configuration changes from the Git repository and applies them internally.

• Reduced Attack Surface: No external credentials stored in CI systems to access production clusters
• Agent Residency: The reconciler lives within the target environment, not outside it
• Firewall-Friendly: Only outbound Git access is required, not inbound deployment connections
• Separation of Concerns: CI builds and tests artifacts; GitOps deploys them

Every state transition is observable through Git history and controller logs. This provides a complete, immutable audit trail for compliance and debugging.

• Who Changed What: Git commit authorship maps configuration changes to individuals
• When It Changed: Precise timestamps for every deployment event
• Rollback as Git Revert: Returning to a previous state is a standard git revert operation
• Compliance Ready: Auditors can verify the entire change history without accessing production systems

GitOps enforces a strict boundary between the CI pipeline (which builds, tests, and publishes artifacts) and the deployment process (which references those artifacts from a registry).

• Artifact Immutability: Built images are never mutated; new builds produce new tags
• Configuration vs. Code: Application source code lives separately from environment-specific configuration
• Promotion Workflows: Promoting from staging to production is a configuration change, not a rebuild
• Registry as Intermediary: Container images are pushed to a registry, then referenced by GitOps configs

GitOps naturally integrates with progressive delivery strategies like canary deployments and blue-green releases. The desired state definition can specify weighted traffic splitting and automated rollback conditions.

• Flagger Integration: Tools like Flagger automate canary analysis and promotion
• Metric-Driven Promotion: Traffic shifts based on real-time observability signals (error rates, latency)
• Automated Rollback: Failed canary releases trigger automatic reversion to the stable configuration
• Git as Control Plane: The promotion decision itself can be recorded as a Git commit

The foundational principle of GitOps where the desired state of a system is specified in code rather than through imperative commands. Instead of running kubectl apply manually, you commit a YAML file to Git. The system then continuously reconciles the live state to match this declaration.

• Idempotency: Applying the same config twice yields the same result
• Self-healing: Drift from the declared state is automatically corrected
• Auditability: Every desired state change is a version-controlled commit

A control loop that continuously compares the desired state stored in a Git repository against the actual state running in the target environment. When divergence is detected, the loop takes corrective action to converge the live system toward the declared configuration.

• Polling: Agents periodically check the Git repo for new commits
• Webhook-driven: Git pushes trigger immediate reconciliation
• Convergence: The loop runs until actual state equals desired state

GitOps favors a pull-based model where an in-cluster agent actively pulls the desired state from Git. This contrasts with traditional CI/CD push-based pipelines that externally push changes into the environment.

• Pull: Agent runs inside the trusted boundary; no external credentials needed
• Push: CI system requires write access to production; larger attack surface
• Hybrid: Some architectures push artifacts to a registry, then pull config from Git

The mechanism by which a GitOps operator identifies that the live state of a system has diverged from the desired state in Git. Drift can occur due to manual hotfixes, failed rollbacks, or unauthorized changes.

• Out-of-sync status: Operator flags resources that no longer match Git
• Automatic correction: Prune mode removes resources not defined in Git
• Alerting: Notifications via Slack, PagerDuty, or webhooks on drift events