GitOps: como o Git virou a fonte de verdade para ambientes de produção

O problema que GitOps resolve

Em ambientes sem GitOps, o estado real do cluster de produção frequentemente diverge do que está no repositório: alguém fez um "kubectl apply" manual para resolver um incidente e nunca voltou para atualizar o código, ou alguém ajustou um recurso direto via console cloud. Com o tempo, ninguém sabe mais o que está realmente rodando em produção.

Como GitOps funciona

No modelo GitOps, o repositório Git é a fonte de verdade do estado desejado do ambiente. Um operador (ArgoCD, Flux) monitora o repositório e reconcilia continuamente o estado real do cluster com o estado declarado no código. Se alguém modifica algo manualmente, o operador reverte.

ArgoCD: o padrão de mercado

• Application definitions — cada aplicação é um recurso Kubernetes que aponta para um repositório Git.
• Sync policies — define se a sincronização é automática (auto-sync) ou manual (precisa de aprovação).
• Health status — ArgoCD mostra o status de saúde de cada recurso, tornando incidentes visíveis imediatamente.
• Rollback — voltar para uma versão anterior é um git revert seguido de sincronização automática.

O impacto de negócio

Times com GitOps maduro têm auditabilidade completa de todas as mudanças em produção, capacidade de rollback em segundos e ambientes que se auto-curam quando alguém faz mudanças manuais acidentais. Para ambientes regulados (financeiro, saúde), essa auditabilidade é frequentemente um requisito de compliance.