Introduction

GitOps is a way of working where everything in your infrastructure is controlled by git operations. Hence the abbreviation GitOps. To my knowledge it is mainly used in the kubernetes ecosystem and this is also where I use it. If done correctly your repository always reflects what is live. Git being the single source of truth.

When to use this?

When you are in a DevOps team, you really want to be able to most things within the team. Sometimes a large enterprise structure prevents this or facilitates parts for you. But when you do have a large control scope you want to keep things organized and neat. The GitOps way of working allows you to achieve this.

Via pull-request you ensure at least 4-eyes on your infrastructure changes. Therefor have a audit trail of when someone did what change. But also you can easily identify what components are deployed and their configuration.

How to use this?

First you need a proper development environment. Because if you start with this you need to be able to test the code. Testing is important! Especially in Infrastructure as Code (IaC) concepts. This environment should reflect the majority of what the code will face.

Second you need a git repository that is setup correctly. One where the primary branch, master or main in these days, are protected for changes by humans. Human changes need to be submitted via pull-request.

Third is your tooling stack, for kubernetes GitOps I recommend using Flux. And I will post about this at a later date. But to have a look on what I use please check it here.

Fourth and this is the most important one, make sure the autonomous process, flux or another form, writes the changes back into the repository. Preferably straight into the primary branch. If this does not work, how is your repository the single source of truth?

Fifth, make sure you set up proper notifications. Because you need to know when something went wrong. And quickly you need to know why. This process should not be stuck long as this is the aorta of your team.

And lastly, enjoy watch the process go. The ease of deployments and updates is valuable. This improves the focus so you can do what you do best.

Things to be aware of

This way of working is not for everyone or in every organization. For example in a large enterprise that is slowly evolving in a more mature / autonomous state of IT infrastructure you’ll find that change management is a thing. And they like to have their own log if what went live when. The idea is that you integrate them somehow, via CI/CD pipelines on PR merge as an example.

Educate the team and organization if you are thinking to implement this. The greater the education, the easier it will be in the end. There will always be struggles while implementing such a process where it is not used yet. Try to avoid the “under the radar” approach, or do that exact thing… Depending on the collective mindset of the organization.

Do not do GitOps because it is a “hot topic”. Be smart and of GitOps is a way that might work, be my guest and implement it.

Kubernetes Tooling

There are multiple tools to do GitOps with. But the below tools I can vouch for.