GitOps is a concept that is meant to supplement your infrastructure as code. To understand the problem that GitOps solves, let's imagine that you work in a team of about 7 people that release code to the wider, large organization that you work in. Since your upper management wanted to invest heavily in having a good test and release infrastructure in place, you spent months setting up clusters, pipelines, and cloud services that automatically test your code before it gets released. Now all this is working fine, and the quality of your releases has gone up considerably. However, some months down the line, other developers change the test infrastructure as your application evolves, and you start noticing that your infrastructure is breaking more often. Now, you are forced to spend more time maintaining your infrastructure as opposed to building your application, which is obviously unacceptable. The problem here lies in the fact that while your release code is well tested and protected, the infrastructure code is not. People tend to do the changes they want and immediately push to master, and they have no way of knowing that their code breaks the infrastructure right until it is broken.
This is where GitOps becomes useful. GitOps dictates that you must treat your infrastructure code in the same way that your normal application code is treated. This includes creating proper branching and reviewing cycles so that all code goes through an extra pair of eyes, as well as creating automated test pipelines that send your code through dev environments to ensure that your infrastructure code is stable before being released.
Once your code is reviewed and merged, your existing system might require you to apply changes to your infrastructure manually (by using kubectl apply, for instance). This is also a problem since this means that every developer will have to manually push their changes to the cluster. Alternatively, you could have your changes automatically applied via a pipeline. A simple Jenkins pipeline that triggers on merge and runs a kubectl apply with the pushed code can apply changes for you. This is generally called the push deployment model, where code is applied upon push. On the other hand, you could also have an agent within your Kubernetes cluster that identifies any changes done in the git repository and pull the changes into the cluster once they are merged. This is generally called the pull deployment strategy. A major advantage of this strategy is the ability to maintain states and roll back to previous states if an issue is found after deployment. This method is also considered a better option, and there are tools such as ArgoCD that help with this type of model. We will be discussing Argo CD in detail in the next section.
Once you follow proper GitOps methodology, you will end up having a single repo that hosts all of your infrastructure code. A single source of truth. Standard git practices similar to those that you maintain in your normal Git repositories will apply, and your infrastructure code can be given the same prioroty as that of your normal application code. Addiotionally, you now don't have to give every developer direct access to your cluster so that they can apply changes, since the application of changes is fully automated and perfomed by the pipeline itself.
Let's move on to talking about a tool that allows you to integrate GitOps into your workflow better: ArgoCD.