O que é GitOps (e por que ele mudou a forma de fazer deploy)

GitOps explicado sem buzzword: os quatro princípios, a diferença entre deploy "empurrado" e "puxado", o que ele resolve no dia a dia e quando não vale a pena.

Fala pessoal, tudo bem?

O DevOps nos ensinou a automatizar o caminho do código até a produção. Pipelines de CI/CD viraram padrão. Mas, com o Kubernetes, uma pergunta começou a incomodar: o que está rodando no cluster agora é exatamente o que está no repositório?

Na maioria dos ambientes, a resposta honesta é "não sei". Alguém fez um kubectl edit às pressas, um deploy falhou pela metade, uma variável foi trocada direto no console. O GitOps nasceu para responder essa pergunta com um "sim".

A ideia em uma frase

💡 GitOps: o repositório Git é a única fonte da verdade sobre como o ambiente deve estar, e um agente dentro do próprio ambiente garante, o tempo todo, que a realidade fique igual ao que está no Git.

Os quatro princípios

O projeto OpenGitOps, da CNCF, resume a prática em quatro princípios:

1. Declarativo: você descreve o estado desejado (quantas réplicas, qual imagem, qual configuração), e não os passos para chegar lá;
2. Versionado e imutável: esse estado fica no Git, com histórico, autor e data de cada mudança;
3. Puxado automaticamente: um agente busca as mudanças no repositório, sem ninguém precisar "empurrar" para o cluster;
4. Reconciliado continuamente: se alguém mexer direto no ambiente, o agente percebe a diferença e corrige.

Push x pull: a diferença que importa

# Modelo tradicional (push)
dev -> git push -> pipeline CI/CD -> kubectl apply -> cluster
                   (o pipeline precisa da credencial do cluster)

# Modelo GitOps (pull)
dev -> git push -> repositório Git <- agente dentro do cluster
                                      (compara e aplica sozinho)

No modelo push, o pipeline guarda as credenciais de produção, e o cluster só muda quando o pipeline roda. No modelo pull, a credencial fica dentro do cluster, e a reconciliação acontece o tempo todo, não só na hora do deploy.

O que muda na prática

• Rollback é um git revert: voltar uma versão é voltar um commit;
• Auditoria de graça: quem mudou o quê, quando e por quê está no histórico do Git e nos pull requests;
• Fim do "mexi direto no cluster": mudanças manuais são detectadas e desfeitas, ou pelo menos ficam visíveis;
• Recriar um ambiente vira apontar um cluster novo para o mesmo repositório.

As ferramentas

As duas principais são projetos graduados da CNCF: o Argo CD, com uma interface web muito boa para ver o estado de cada aplicação, e o Flux, mais enxuto e muito usado em automações.

Se você quer ver isso funcionando, montei uma série aqui no blog com um lab completo: um cluster kind, o Argo CD instalado e uma aplicação versionada por tags no GitHub. A primeira parte está em Argo CD na prática (parte 1).

Quando não vale a pena

⚠️ GitOps brilha em ambientes declarativos, principalmente Kubernetes. Para um servidor isolado, um ambiente sem nenhuma automação ou um time que ainda não versiona configuração, comece pelo básico: tudo em Git e um pipeline simples. GitOps é o passo seguinte, não o primeiro.

Outro ponto de atenção: segredos. Senha não vai para o Git em texto puro. Ferramentas como Sealed Secrets, SOPS ou o External Secrets Operator resolvem isso, e precisam entrar no desenho desde o começo.

Considerações Finais

GitOps não é uma ferramenta, é um jeito de operar: o Git descreve o ambiente, e um agente garante que ele continue assim. A grande vantagem não está no deploy em si, e sim em sempre saber o que está rodando e em conseguir voltar atrás com um commit.

Abs e até a próxima!!!

:wq!

Post publicado originalmente em setembro de 2024 e atualizado em novembro de 2026.