Foundation
Infrastructure as Code
GitOps does not replace IaC, but adds a continuous reconciliation model and delivery governance to it.
GitOps is an operating model where the state of the platform is managed through Git, and clusters are automatically brought to the desired state. The key value is predictable, verifiable and reproducible changes in production.
GitOps model
- Git is the single source of truth for the desired state of the platform.
- Delivery works in a pull model: the agent in the cluster itself synchronizes the state from Git.
- Any change goes through a pull request, review and audit trail.
- Drift between cluster state and git state is detected automatically and corrected by reconcile-loop.
Building blocks
What it does
Separate app configs, platform baseline, and environment overlays so team ownership does not conflict.
Operational focus
Standardize directory structure and naming conventions before team scale-up.
Anti-pattern
Mixing app and platform changes in one layer makes reviews harder and increases blast radius.
SRE
SRE and reliability
GitOps reduces manual changes in production and improves traceability of incident actions.
Operational patterns
Enter progressive delivery (canary/blue-green) and explicit rollback strategy for each service.
For incidents, use emergency branch and post-incident revert PR instead of manual hotfix in the cluster.
Synchronize secrets processes with GitOps: encryption/external secret-stores and short-lived credentials.
Determine ownership: who is responsible for platform overlays and who is responsible for app-level manifests.
Practical checklist
- All deployment changes can be reproduced via PR without manual kubectl patches in production.
- There is drift monitoring and alerting when there is a discrepancy between the desired/actual state.
- Rollback procedures are clearly defined and tested on game day.
- There is a consistent branching/promotions process between dev/stage/prod.
- Secrets and sensitive values are not stored in cleartext in Git.