.NET › CI/CD, Publishing & Deployment

How does GitOps (e.g., using Flux or ArgoCD with Kubernetes) change the deployment model compared to traditional push-based CI/CD pipelines?

Advanced

Answer

In GitOps, a Git repository is the single source of truth for the desired deployment state (Kubernetes manifests, Helm charts), and a controller running inside the cluster continuously reconciles the actual cluster state to match what's declared in Git (pull-based), rather than a CI pipeline directly pushing changes to the cluster (push-based) -- this provides a full audit trail via Git history, easy rollback (revert the Git commit), and eliminates the need to grant CI systems direct write credentials to production infrastructure.
# GitOps flow:
# 1. Developer merges PR updating image tag in deployment.yaml
# 2. Flux/ArgoCD controller (running IN the cluster) detects the Git change
# 3. Controller pulls the new manifest and reconciles cluster state to match
# CI pipeline never has direct cluster write access
Real-world example A platform team adopts ArgoCD so that rolling back a bad .NET microservice deployment is as simple as reverting a Git commit, with the in-cluster controller automatically detecting and applying the reverted state within seconds, without needing direct pipeline access to production credentials.

Common follow-ups: How does GitOps improve the security posture compared to push-based deployment?;What happens if someone makes a manual, undocumented change directly to the cluster?