"Git is the only source of truth." If you understand that sentence, you know GitOps. Every time we want to apply a change, we need to push a commit to Git. Want to change the configuration of your servers? Commit a change to Git, and let an automated process propagate it to servers. Want to upgrade ChartMuseum? Change requirements.yaml, push the change to the k8s-prod repository, and let an automated process do the rest. Want to review a change before applying it? Make a pull request. Want to rollback a release? You probably get the point, and I can save you from listing hundreds of other "want to" questions.

Did we do GitOps in the previous chapter? Was our continuous deployment process following GitOps? The answer to both questions is no. We did keep the code, configurations, and Kubernetes definitions in Git. Most of it, at least. However, we were updating production releases with new image tags without committing those changes to Git. Our complete source of truth was the cluster, not Git. It contained most of the truth, but not all of it.

Does this mean that we should fully embrace GitOps? I don't think so. Some things would be impractical to do by committing them to Git.

Take installations of applications under test as an example. We need to install a test release inside a test environment (a Namespace), we need to run some automated tests, and we need to remove the applications once we're finished. If we'd fully embrace GitOps, we'd need to push a definition of the application under test to a Git repository and probably to initiate a different pipeline that would install it. After that, we'd run some tests and remove the information we just pushed to Git so that yet another process can remove it from the cluster. Using GitOps with temporary installations would only increase the complexity of the process and slow it down without any tangible benefit. Why would we store something in Git only to remove it a few minutes later?

There are other use cases where I think GitOps is not a right fit. Take auto-scaling as an example. We might want to use Horizontal Pod Autoscaler (HPA) (https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). Or, maybe we want Prometheus to fire alerts which will result in increasing and decreasing the number of replicas of our applications depending on, let's say, response times. If those changes are infrequent (for example, once a month or even once a week), storing them in Git and firing Webhooks that will do the scaling makes sense. But, if scaling is more frequent, the information in Git would vary so much that it would only result in more confusion.

The same can be said to auto-scaling of infrastructure. Should we ignore the fact that GKE (and most other Kubernetes clusters) can automatically increase and decrease the number of nodes of the cluster depending on resource usage and how many pending Pods we have? We probably shouldn't.

Those examples should not discourage you from applying GitOps logic. Instead, they should demonstrate that we should not see the world as black-and-white. The fact that I think that we should not embrace GitOps hundred percent does not mean that we should not embrace it at all. We should always try to strike a balance between different practices and create a combination that best fits our scenarios.

In our case, we'll use GitOps to an extent, even though we might not follow the mantra to the fullest.

Now, let's try to upgrade our production environment by adding the go-demo-5 release to it.