"Quem mudou isso em produção?" é uma das perguntas mais caras de uma operação. Quando o deploy é um kubectl apply rodado da máquina de alguém, a resposta é um mistério: o cluster vira a fonte da verdade, e ninguém sabe ao certo o que está rodando nem por quê. GitOps inverte isso, e o ArgoCD é uma das formas mais sólidas de fazer.
O que é GitOps de verdade
A ideia é simples e tem três partes: o estado desejado da infraestrutura vive versionado no Git; toda mudança entra por pull request; e um controlador reconcilia o cluster continuamente para que a realidade bata com o repositório. O Git deixa de ser só onde mora o código e passa a ser o painel de controle do ambiente.
O ArgoCD é esse controlador. Ele roda dentro do cluster, observa o repositório e, sempre que o estado real diverge do desejado, mostra a diferença e sincroniza, automaticamente ou sob aprovação.
Por que "pull" importa (e é mais seguro)
No modelo antigo (push), a esteira de CI tem credenciais do cluster e empurra mudanças de fora. No GitOps com ArgoCD, é o contrário: o agente dentro do cluster puxa o estado do Git. A CI nunca precisa de acesso de produção, a superfície de ataque encolhe e o segredo crítico para de circular por pipelines. Segurança por arquitetura, não por boa vontade.
Rollback vira git revert
Como o Git é a fonte da verdade, voltar atrás é reverter um commit. O ArgoCD percebe a divergência e sincroniza o cluster de volta ao estado anterior, sem ninguém digitar comando em produção sob pressão. E a auditoria vem de graça: o histórico do Git responde "o que mudou, quando e por quem" para qualquer ponto no tempo.
Drift deixa de ser invisível
Se alguém alterar algo direto no cluster, o ArgoCD marca o app como OutOfSync na hora, mostrando exatamente o que difere do repositório. Você pode só ser avisado ou ligar o self-heal, em que o controlador reverte sozinho a mudança manual para o estado declarado. O resultado é o que GitOps promete: o que está no Git é o que está rodando, sempre.
Com GitOps, o cluster para de ter segredos: tudo que roda está declarado, versionado e auditável.
Montamos esse fluxo nos projetos de DevOps e Plataforma, deixando o time entregando por pull request, com rollback de um clique e sem kubectl manual em produção, e capaz de manter tudo sozinho depois. Se o seu deploy ainda mora na máquina de alguém, vamos conversar.