GitOps: A Git-Centric Approach to DevOps

Three years ago, I was the guy everyone blamed when deployments went sideways. And trust me, they went sideways a lot.

Picture this mess: We had a deployment process that involved copying files to a shared folder, running a shell script that hadn’t been updated since 2019, and praying to whatever deity handles server deployments. The script had comments like “TODO: fix this hack” and “this shouldn’t work but it does.”

Our Friday deployments were legendary. Not in a good way. More like “hey, remember that time we took down the entire customer portal because someone typoed an environment variable?”

I was spending more time firefighting broken deployments than actually building features. Something had to give.

In this article, we will delve deep into GitOps, exploring its origins, principles, benefits, and best practices. By the end, you’ll have a comprehensive understanding of how GitOps can streamline your DevOps pipeline and help your organization achieve faster and more reliable software releases.

My manager came back from some conference talking about GitOps. Honestly? I rolled my eyes. Hard. Another buzzword to add to our already bloated tech stack.

But then I actually looked into it. And damn, it made sense.

The core idea is embarrassingly simple: What if we treated infrastructure changes exactly like code changes? Pull requests, code reviews, version control – the whole nine yards.

No more SSH-ing into production servers. No more “oops, I ran that command on the wrong environment.” No more deployment scripts that only work on Dave’s laptop because he has some mystery dependency installed.

Here’s GitOps in plain English:

Everything lives in Git. And I mean everything – your app code, your Kubernetes manifests, your database migration scripts, even your monitoring configuration.

When you want to deploy something, you don’t run commands. You commit to Git.

Then some automated system watches your Git repo like a hawk and makes sure your actual infrastructure matches what’s written down. It’s like having a really obsessive-compulsive robot that can’t stand when things are out of place.

I’m working on a new API endpoint. Along with the code changes, I need to update some environment variables and maybe tweak our load balancer config. In the old days, that meant three different systems and two manual steps.

Now? It all goes in the same pull request. Code review covers everything – the business logic AND the infrastructure changes. Revolutionary, right?

Sarah approves my PR. I merge it. Within about thirty seconds, our CI system starts building and testing everything. No buttons to click, no Jenkins job to babysit.

Meanwhile, our production cluster is checking Git every few minutes. Sees the new changes. Validates them. Rolls them out automatically.

Last month we deployed a change that made our API super slow. Like, “customers are calling to complain” slow.

In the before times, this would’ve been panic mode. Conference calls, people frantically trying to remember what changed, someone inevitably suggesting we “just restart everything.”

Instead, I opened my laptop, ran git revert, and pushed. Two minutes later, we were back to the previous version. Crisis averted. No conference call required.

You know how Git tracks every change to your code? Now it tracks every change to your infrastructure too. When did we change that timeout value? Who updated the database connection string? It’s all there, with timestamps and commit messages.

Remember environment drift? That thing where your staging environment worked perfectly but production was mysteriously different? Yeah, that’s basically impossible now. If both environments are syncing from the same Git repo, they’re going to be identical.

Before GitOps, if Jake quit, we’d be screwed. He was the only one who really understood our deployment process. Now that everything’s in Git with proper documentation, anyone can make infrastructure changes.

We deploy to production probably fifteen times a day now. Not because we’re reckless, but because each deployment is small, predictable, and easily reversible. It’s actually boring. And boring deployments are the best kind.

We made this mistake early on. Application code, infrastructure code, documentation, configuration files – all mixed together in one massive repository. Every tiny config change triggered a full application rebuild. Learn from our pain.

GitOps doesn’t magically solve the problem of where to store passwords and API keys. You still need a proper secrets management solution. We use HashiCorp Vault, but there are other options.

Moving from “run this script when you want to deploy” to “commit this YAML file and let the robots handle it” is a bigger mental shift than you’d think. Some people on our team struggled with it initially.

What happens when your GitOps tooling breaks? And it will break, because software always breaks. Keep some emergency procedures around for when you need to bypass the normal process.

1. ArgoCD is what we use for our Kubernetes stuff. The web UI is actually decent, and it handles complex application dependencies without losing its mind. Setup was a bit of a pain, but it’s been rock solid since.
2. Flux is simpler and lighter weight. We use it for some of our non-critical services. Less features, but also less complexity.
3. GitHub Actions can handle the CI part if you’re already living in GitHub. It’s not the most powerful option, but it integrates nicely and the YAML syntax doesn’t make me want to throw my laptop out the window.

Honestly though, don’t get too obsessed with tools. We spent way too much time evaluating options. Pick something that works with your existing infrastructure and move on.

Is GitOps perfect? Nope. Is it better than what we had before? Absolutely.

Our deployment-related incidents dropped from “multiple per week” to “maybe one per month.” We ship features faster because we’re not afraid of deployments anymore. New team members can contribute infrastructure changes on their first week instead of their first month.

The downsides? Setup takes time. You need to retrain your team. Sometimes the abstraction makes debugging weird issues harder.

But honestly, I can’t imagine going back to the old way. Manual deployments feel primitive now, like using FTP to upload files to your website.

If you’re already using containers and your team is comfortable with Git workflows, probably yes. If you’re still managing bare metal servers with shell scripts, maybe work on containerization first.

Start small. Pick your least critical application and try GitOps with that. Don’t try to migrate your entire infrastructure over a weekend – we tried that and it was a disaster.

And remember, GitOps isn’t going to fix bad application architecture or terrible monitoring. It’s just a better way to manage deployments. Your code still needs to be good, your tests still need to pass, and you still need to understand what you’re putting into production.

But if you’re tired of deployment anxiety and want something more predictable, GitOps might just save your sanity. It saved mine.