We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A cluster had been modified by 8 different engineers over 6 months. Some used kubectl apply from their laptops. Some edited resources directly with kubectl edit. Some used Helm. Nobody knew the true state of the cluster: what was running, what version, what configuration. When an audit required proving the state of production, the team spent a week running kubectl get commands and comparing against what they thought should be deployed.
GitOps makes Git the single source of truth for everything running in production. The desired state of your infrastructure and applications lives in a Git repository. A GitOps operator (ArgoCD, Flux) runs inside the cluster, continuously watches Git, and reconciles. If someone modifies the cluster directly, the operator reverts the change within minutes. The only way to change production is to change the Git repository.
Weaveworks coined the term "GitOps" in 2017. Since then, Intuit (makers of TurboTax) has adopted ArgoCD as their standard deployment tool for 100+ Kubernetes clusters. Alibaba runs Flux across thousands of clusters. The CNCF has accepted both ArgoCD and Flux as graduated projects.
GitOps is built on four principles that work together. Drop one and you lose the benefits.
| Principle | What It Means | What Breaks Without It |
|---|---|---|
| Declarative | Desired state described in files (YAML, Helm charts, Kustomize overlays) | Imperative scripts cannot be diffed or reconciled |
| Versioned | All state changes tracked in Git history | No audit trail, no git blame, no git revert |
| Automated | Changes in Git are automatically applied to the cluster | Manual applies defeat the purpose |
| Reconciled | Continuous monitoring ensures actual state matches desired state | Manual changes persist as drift |
Push vs pull deployment:
| Aspect | Push (traditional ) | Pull (GitOps) |
|---|---|---|
| Who deploys | CI pipeline pushes to cluster API | Agent inside the cluster pulls from Git |
| Credentials | Pipeline needs cluster credentials | Only the in-cluster agent has credentials |
| Drift detection | None. Manual changes stick. | Agent reverts drift automatically |
| Audit trail | CI/CD logs (often not long-term) | Git history (permanent) |
| Security | CI server is a high-value target | CI never touches the cluster directly |
The security improvement is significant. In a push model, your CI/CD system (GitHub Actions, Jenkins) needs credentials. If your CI system is compromised, the attacker has cluster access. In a pull model, the CI system builds images and updates Git. The GitOps agent inside the cluster pulls the changes. The CI system never has cluster credentials.