The PR review cycle is not a good fit for MVP (and to internal tools, etc.) . I think, GitOps still can be used if
* You have a sandbox / test environment
* Allow the developers to push directly (no PR) to the branch used for that test environment
So for me it's not about GitOps (having the description of the deployment in git) it's a about the git workflow for these cases (PR review cycle vs pushing directly to branch).
I don’t see this article actually arguing against GitOps. It just argues that the policies in place for GitOps need to make sense for the environment you’re developing in.
Obviously, the level of auditing and reviewing for infrastructure changes in a Prod environment make no sense for a Sandbox environment, and there’s nothing in GitOps that implies these need to be the same.
Ideally at every phase of development, you have very legible infrastructure that can be shared and iterated on by a team. The CI pipelines backing this should offer rapid turnaround times, and things should be easy to test.
All things which the general GitOps concept still works in tandem with.
Usually GitOps have flow like
checkout => modify => commit => push => PR => merge => check result.
Even if we remove the merge step, still have flow
modify => commit => push => check result.
In which the commit & push still could be removed
I overall agree with the article; GitOps is great for managing long-lived, shared, stable systems you need a good audit trail for (like production), but testing isn't one of these. Test environments should ideally just be something non-shared you can just spin up and make changes to without asking for permission.
In theory, GitOps is neutral. A robot pulls from Git and makes reality match. Everyone gets to review, and every change is versioned. Feels fair. Right?
But in practice, GitOps introduces a very specific kind of power dynamic: the gatekeeper pattern.
Most of the time, it’s the infra or platform team that sets up GitOps. They define the rules—how environments are structured, how approvals work, which tools are allowed. And once that system is live, every change has to go through them.
It sounds like collaboration. In reality, it’s almost always a one-way review.
A backend developer wants to change a config file. They need a review from someone on the platform team. A frontend dev wants to bump a service version. They open a PR. They wait. A product engineer wants to expose a new route for testing. Same story. PR. Wait. Fix a nit. Wait again.
But it doesn’t go the other way. It almost never goes the other direction.
Infra changes things, merges to main, the bot deploys it. No one outside the infra team is reviewing their changes. No one’s stopping their PRs with a comment. They own the system, and everyone else is a guest.
We use it heavily in our Kubernetes environment. Everything beyond the basic install goes into a repository. As soon as someone commits a change, ArgoCD running on the cluster picks it up and rolls it out automatically.
For version 1/MVP work, you absolutely shouldn’t bother with this. It’s a complete waste of resources when you should be focusing on growth or launching the product. Compared to doing it by hand, it’s slower, clumsier, and just another layer of complexity your team has to deal with.
On the other hand, for long-running, stable systems, it’s awesome! We know exactly who rolled out a change and when. From the commit messages, we know why the change happened—even years later. We also make a point of adding Jira (Hawk Tuah) ticket numbers so we can track the details more easily. And if something goes wrong, it’s simple to roll back to an older version.
This approach is perfect for large, long-term maintenance systems—but poison for a brand-new project.
> At its core, GitOps is simple. You write down how you want the system to look in code and a bot makes the world match that. Your infrastructure lives in Git. You deploy by committing. You roll back by reverting. The robots take it from there.
Readit News
The PR review cycle is not a good fit for MVP (and to internal tools, etc.) . I think, GitOps still can be used if
* You have a sandbox / test environment * Allow the developers to push directly (no PR) to the branch used for that test environment
So for me it's not about GitOps (having the description of the deployment in git) it's a about the git workflow for these cases (PR review cycle vs pushing directly to branch).
Obviously, the level of auditing and reviewing for infrastructure changes in a Prod environment make no sense for a Sandbox environment, and there’s nothing in GitOps that implies these need to be the same.
Ideally at every phase of development, you have very legible infrastructure that can be shared and iterated on by a team. The CI pipelines backing this should offer rapid turnaround times, and things should be easy to test.
All things which the general GitOps concept still works in tandem with.
Dead Comment
In theory, GitOps is neutral. A robot pulls from Git and makes reality match. Everyone gets to review, and every change is versioned. Feels fair. Right?
But in practice, GitOps introduces a very specific kind of power dynamic: the gatekeeper pattern.
Most of the time, it’s the infra or platform team that sets up GitOps. They define the rules—how environments are structured, how approvals work, which tools are allowed. And once that system is live, every change has to go through them.
It sounds like collaboration. In reality, it’s almost always a one-way review.
A backend developer wants to change a config file. They need a review from someone on the platform team. A frontend dev wants to bump a service version. They open a PR. They wait. A product engineer wants to expose a new route for testing. Same story. PR. Wait. Fix a nit. Wait again.
But it doesn’t go the other way. It almost never goes the other direction.
Infra changes things, merges to main, the bot deploys it. No one outside the infra team is reviewing their changes. No one’s stopping their PRs with a comment. They own the system, and everyone else is a guest.
That’s not collaboration. That’s control. """
For version 1/MVP work, you absolutely shouldn’t bother with this. It’s a complete waste of resources when you should be focusing on growth or launching the product. Compared to doing it by hand, it’s slower, clumsier, and just another layer of complexity your team has to deal with.
On the other hand, for long-running, stable systems, it’s awesome! We know exactly who rolled out a change and when. From the commit messages, we know why the change happened—even years later. We also make a point of adding Jira (Hawk Tuah) ticket numbers so we can track the details more easily. And if something goes wrong, it’s simple to roll back to an older version.
This approach is perfect for large, long-term maintenance systems—but poison for a brand-new project.
> At its core, GitOps is simple. You write down how you want the system to look in code and a bot makes the world match that. Your infrastructure lives in Git. You deploy by committing. You roll back by reverting. The robots take it from there.