GitOps is focused on infrastructure and is related to DevOps. You can practice GitOps and not practice DevOps. You can do DevOps and not do GitOps. HOWEVER, they are very similar and complement each other.
Specifically, it is an operational framework that combines DevOps best practices for application development (version control, collaboration, CI/CD tooling, etc) and applies it to infrastructure automation.
There are 4 key concepts to GitOps. A system (infrastructure) being managed by GitOps should:
- have its desired state (all configuration data that is sufficient to recreate the system so that instances of the system are behaviourally indistinguishable from each other) expressed declaratively (Infrastructure as Code).
- That desired state should be immutable and versioned (the connect to “git” in GitOps)
- Approved changes to the desired state should be automatically applied to the system
- Software agents continuously observe actual system state and attempt to apply the desired state
The key benefits is reduction in drift between your systems, less error prone, and reduced recovery time from failures. But the big one for me is that you’re able to push down a lot of the management of a stack down to the developer, while maintaining control of the parts they don’t, nor should they need to care about. This allows the developers to experiment and iterate more quickly.
GitOps is a form of CD specifically. Where the state of your applications is always reflected in Git, and some external process is reconciling that state with your environments constantly. CI/CD itself doesn’t always work that way, and historically hasn’t.
GitOps requires drift correction, which CICD doesn’t provide most of the time. Apps like ArgoCD, Flux etc correct the actual state of the application to be the same as defined in declarative source of truth, which may be git, doesn’t have to (it may be hełm chart registry, other git-like tools etc). Standard CI/CD doesn’t make that drift correction, if you do for example hełm install at the end of the pipeline, nothing stops someone from deleting service and making your app useless. GitOps would correct that and spawn new service.
TL;DR:
GitOps is defined by Weaveworks as ‘a way to do Kubernetes cluster management and application delivery’.
A placebo is defined by Merriam Webster as ‘a usually pharmacologically inert preparation, prescribed more for the mental relief of the patient than for its actual effect on a disorder’.
GitOps is a placebo. Its usage may make people happy, but it offers nothing that cannot be achieved with Continuous Delivery principles and Infrastructure as Code practices as is.