Should you care about GitOps?

2025-08-20

(TL;DR: Yes)

GitOps has long interested me because it spans both applications and infrastructure. It promises more reliable software delivery, stronger infrastructure control, and greater efficiency and productivity.

So, what is it precisely? Let’s take a look.

What’s GitOps?

Let’s start with version control. One of the great principles of software configuration management, of which version control is a part, is to recreate a version of the application, based on specific versions of its component parts. You should be able to say, “Give me precisely the setup that I had on March 31st.”

In the virtual world we now occupy, alongside this comes Infrastructure as Code. Being able to define an environment in Terraform and watch it come to life is another powerful concept.

Managing that definition alongside the application code or libraries that will run within it is particularly compelling. That’s what GitOps principles, practices, and tools bring. They enable you to manage the “source code” for a target environment as a core, version-controlled part of your system.

What really excites me about GitOps is its closed-loop nature. Consider this: once you have deployed an application, you’re unlikely to change the binaries at runtime. More typically, you change the source, then rebuild and redeploy.

However, in infrastructure, you often tweak things, such as where services run, how much memory they use, security settings, and so on. That’s common in physical environments and just as easy in the cloud.

Doing so, however, introduces risk. Unless you keep detailed notes, you won’t know what your runtime environment looks like after reconfiguring it. You’d struggle to rebuild the version you had last Wednesday, never mind last year.

GitOps tools can support the overall approach. Tools like FluxCD and ArgoCD emerged as open-source projects to enable two mechanisms. First: left to right. You edit your configuration in Git and redeploy from there.

But GitOps can also work right-to-left, detecting if a runtime environment has changed, and enabling a comparison with a versioned “last known good” configuration. Some tools do this automatically, and (as with many things open-source) a debate continues about whether this is actually GitOps – but either way, the feature is useful.

What does GitOps look like in practice?

The OpenGitOps Project defines principles to standardize GitOps terminology and approaches. That left-right-left thing is known as the reconciliation loop. If the runtime configuration changes, you receive an alert and have the ability to reconcile the actual state with what’s defined in your config library.

Defining your environment ahead of time is known as a declarative model. According to GitOps, you shouldn’t have to care how it builds it, just what you want built. For the record, that’s known as an “imperative” approach. Versioning is another principle, and the final one is an automated build based on the required configuration.

Thus far, you might say, “I bet GitOps looks good on a whiteboard.” That is, great theory, but does it make a difference? According to a recent report from Octopus Deploy, it absolutely does. If you go to page 49, you’ll see software delivery performance increases in proportion to the depth and breadth of GitOps practices adopted. Not only this, but software reliability, and developer well-being also improve.

To be fair, it would have been shocking if that were not the case. Even the Romans knew it was cheaper to maintain a system than to repair one after it had been broken; and we all know that it’s less stressful. GitOps simply sets out how that maintenance should take place, in relation to this more modern problem space.

It’s worth drilling into breadth and depth. Breadth: Is GitOps being adopted broadly across the organization? Depth: how thoroughly and comprehensively are the GitOps principles being applied?

Something my late colleague, Michael Delzer, learned at American Airlines was: GitOps isn’t just for cloud-native environments. According to Michael, GitOps principles make sense in any environment where you can create and apply an infrastructure definition.

What’s missing from GitOps?

The missing piece, if I may, is that you need a level of ongoing monitoring, not just events triggered by configuration changes. In the real world, things change—whether you like it or not. It is therefore important to track configuration drift over time—that is, the gap between your planned state and actual state.

Drift visibility might be seen as a ‘nice to have’ in GitOps, but it’s a must-have practice. The GitOps model includes alerting on configuration changes, and that’s useful. You also need visibility into how big the drift is today, whether it is increasing over time, and where to focus efforts to reduce it.

Tools do exist to monitor configuration drift outside of GitOps, but they are not embedded in the methodology. We need what I would call GitOps observability, or (dare I say) GitObs, as a core element of the approach.

What to do about GitOps?

To conclude, while we can debate the details, the GitOps approach is no more or less than combining software and (virtualized) hardware configuration management, enabling age-old principles to be applied to modern application deployment.

Ultimately, GitOps isn’t just a ‘thing’—it’s simply best practice by another name. If you follow what it suggests, you’re going to be in a better place – you’ll be able to deliver higher quality software at lower cost and risk, more efficiently and with less stress.

The place to start is to learn how the principles apply to your environment, and (as per my GitObs comment) to ensure that you cover your processes end-to-end, from development to operations.

Embrace GitOps, and both your customers and your developers will thank you for it.