I think we should start with questions:
Where do we nowadays deploy our code? Where does it run? Where is it hosted?
Times, when we have manually copied compiled apps to the one, single, runtime environment, are gone. We live in the world of Kubernetes clusters, microservices, serverless, clouds, etc. And even when we look from a single system perspective, we see that probably it is being deployed to multiple environments (development, staging, and production). We live surrounded by multiple runtime environments. Environments that have to be defined, configured, and managed.
We can do this manually, but I think everyone can see that this is not the way. And that is why Infrastructure as code (IaC) concept has been born. Without going into details, IaC gives us the possibility to wrap the definition and configuration of environments into the code. A code that can be executed to create environments for our applications.
So, if we have an infrastructure enclosed in a code, that code (the same as an application code) may be versioned in Git repositories and may be operated by dedicated CI/CD pipelines. And this is what a GitOps is.
To sum up, GitOps is a combination of Infrastructure as Code and Git and CI/CD.
Benefits of GitOps
Let’s think about what benefits give us mentioned combination.
One source of truth
How is our environment configured? Did someone make manual changes in configuration? These questions do not apply when our environments are in the GitOps regime. That is because all changes are now applied through the code as the result of the CI/CD pipelines. There is no place for manual changes because most of the users have no privileges to make them. All rights to make so are now in the hands of CI/CD.
More secure
As mentioned in the point above. All rights to modify environments are now in the hands of CI/CD. It means that most of the users do not need access to the infrastructure. This means that the risk that someone will break something during manual operation on a server/container/cluster is smaller. This also means that the risk of a credential leak is smaller. And last but not least, this also means that managing user privileges and access to the environments is much easier.
Git Merge requests mechanism and team collaboration
All changes in an infrastructure code, when the code is in a Git repository, can be now handled like any other code in Git repositories. I mean, that all changes may be, and should be made in separate branches, which should be merged to the main branch after code reviews. That will for sure increase code quality and will give a possibility to the team to find out some mistakes or poor code parts.
CI pipelines, which can easily test our code
Code reviews do not have to be the only part of a process where bugs are being revealed. We can add tests to a CI pipeline that can find out, for example, some syntax problems. It can be very helpful especially when you think about a YAML syntax that can be very tricky.
Versioning and easy rollbacks
Another benefit of storing your infrastructure code in Git repositories is its versioning. We know what, when, and by whom was changed. If something goes wrong, we can revert our infrastructure to the last working version. Thanks to the automation of CI/CD pipeline deployment and also the rollbacks are easy and fast.
