platform-engineering · intermediate
GitOps Fundamentals
Quick answer
GitOps keeps desired system state in Git and uses controllers to reconcile clusters toward that state. Deploy becomes merge; rollback becomes revert; drift becomes visible.
Why this matters
- Snowflake clusters are unreviewable.
- PR-based changes add auditability.
- Works well with Kubernetes and progressive delivery.
Learning objectives
- Separate app CI from env reconciliation. 2. Model desired state. 3. Handle secrets safely. 4. Detect drift. 5. Know when GitOps is overkill.
Explain like I am 5
The drawing of the LEGO castle is the truth—if reality differs, rebuild to match the drawing.
Mental model
flowchart LR
Git --> Controller
Controller --> Cluster
Cluster --> Drift
Drift --> Controller
Core concepts
Desired vs live state
Git is source of truth; controllers converge.App CI vs GitOps CD
Build/test in CI; CD updates manifests/tags in Git.Environments
Dirs or branches per env; promotion via PR.Secrets
Sealed secrets / external managers—not raw secrets in Git.Drift & rollback
Alert on drift; revert commit to roll back.Worked example
K8s service deploy: CI builds image, PR bumps tag in deploy/prod; Argo/Flux applies; bad release → revert PR.
Trade-offs
| Pure GitOps | Push-from-CI only |
|---|---|
| Strong audit | Simpler early on |
Failure modes
| Mode | Mitigation |
|---|---|
| Secrets in repo | SOPS/ESO |
| Manual kubectl drift | Forbid + alert |
| Huge mono-blast | App-of-apps modularity |
Interview mode
Skeleton: "Git desired state + reconcile loops; deploy by merge; rollback by revert."
Knowledge check
Git repositories describing desired configuration
Random SSH sessions only
Verbal agreements in chat
Unversioned notepad files on laptops only
By Shubham Jain