The Hidden Mechanics of Software Delivery: Beyond the "Everything in Git" Dogma

Effective engineering teams prioritize short feedback loops over the latest industry trends. While many view GitOps as a universal solution, the most durable systems rely on practical control rather than ideological purity. GitOps is a misnomer, as none of its core pillars require the use of Git. By decoupling deployment from release through feature flags and focusing on rolling forward instead of rolling back, teams gain stability without the overhead of treating every infrastructure problem as a Git repository issue. This analysis helps engineering leaders build resilient, scalable delivery systems.

The GitOps Fallacy and the Power of Pragmatism

The industry has adopted a dogmatic approach to GitOps. As Robert Erez notes, the four pillars of GitOps--declarative state, versioned or immutable configuration, pull-based reconciliation, and continuous reconciliation--do not mandate the use of Git. This naming convention leads teams to believe that all infrastructure, including sensitive secrets, must live in a repository.

"There is often a bunch of other processes you do around your actual sort of quote unquote deployment. So things like maybe you run smoke tests or maybe you want to send notification when it is complete or maybe you want to send a database update... these kind of steps do not really lend themselves very well to kind of this declarative, everything is in git kind of process."

-- Robert Erez

The "everything in Git" obsession creates friction when teams force imperative tasks into declarative containers. GitOps is a tool for reconciliation, not a totalizing philosophy. When teams accept that some processes are inherently imperative, they stop building convoluted workarounds for tasks that were never meant to be declarative.

Why Rollbacks Are a Mythical Safety Net

Conventional wisdom suggests a rollback button is the ultimate safety net for failed deployments. Erez argues this is flawed in any system involving state, such as databases. Attempting to roll back a schema change often creates more complexity and risk than simply pushing a hotfix.

"We have gotten pretty far in basically trying to advise customers that you never want to avoid ever talking about rollback. It is always roll forward. So if there is a bug, roll forward. Get it changing."

-- Robert Erez

Relying on rollbacks creates a false sense of security that ignores the downstream impact of data migrations. By shifting focus to rolling forward, teams build faster feedback loops and more robust hotfix pipelines. This provides a lasting advantage: the team becomes faster at fixing the current state rather than wasting energy attempting to revert to a past state that may no longer be compatible with the data.

Progressive Delivery as a Competitive Moat

As AI-driven code generation increases shipping volume, the traditional big bang deployment model becomes a liability. Progressive delivery, using canary releases and feature flags, is about more than safety; it is about decoupling the deployment of code from the release of features.

This separation allows teams to ship code on their own schedule while controlling the user experience independently. The hidden consequence of this approach is hygiene debt. Feature flags, if left unmanaged, turn into a technical nightmare. Successful teams treat feature flags like gardening: they implement strict expiration policies and automated notifications to ensure flags are removed once they serve their purpose. This requires discipline, which is why it serves as a competitive moat. Those who master the lifecycle of a feature flag can iterate at speeds that competitors tethered to rigid, versioned release cycles cannot match.

Key Action Items

• Audit your GitOps footprint (Immediate): Identify processes currently forced into Git that are inherently imperative, such as secret management or complex database migrations. Move these to more appropriate management tools to reduce artificial complexity.
• Shift from Rollback to Roll-Forward (Over the next quarter): Re-evaluate your incident response playbooks. Prioritize building a high-velocity hotfix pipeline that allows for rapid forward-fixes, reducing reliance on risky database-level rollbacks.
• Implement Feature Flag Hygiene (12-18 months): If you use feature flags, implement an automated expiry system. Tag flags with ownership and expiration dates to prevent the accumulation of dead code paths that complicate debugging.
• Adopt Ephemeral Environments (12-18 months): Move away from static Dev, Test, and Prod environments for feature validation. Invest in ephemeral, per-branch environments to provide developers with immediate, isolated feedback loops.
• Establish a Platform Team (12-18 months): As your organization grows, transition from a model where everyone does DevOps to one where a platform team provides self-service templates. This prevents the bifurcation of processes that occurs when every team builds their own deployment infrastructure from scratch.