GitOps: como automatizar infraestrutura e deploys usando Git

O que é GitOps?

GitOps é um modelo operacional no qual o estado desejado de um sistema é descrito de forma declarativa, versionado e aplicado automaticamente por software.

O repositório registra a intenção; o ambiente em execução representa a realidade.

Um controlador observa as duas partes. Quando encontra diferença, tenta fazer o ambiente convergir para o estado aprovado no Git.

Esse ciclo, chamado de reconciliação, é o elemento que separa GitOps de um simples repositório de configurações.

O Git oferece histórico, comparação, revisão e autoria. Já o reconciliador transforma essas decisões em mudanças concretas.

Isso cria uma trilha que responde quem alterou, o que foi revisado e qual versão deveria estar ativa.

Os quatro princípios do OpenGitOps

A especificação do OpenGitOps resume a prática em quatro princípios:

1. Declarativo: o sistema é descrito pelo resultado desejado, não por uma sequência frágil de comandos.
2. Versionado e imutável: o estado é armazenado com histórico completo e versões que não são alteradas silenciosamente.
3. Obtido automaticamente: agentes autorizados buscam a declaração a partir da fonte confiável.
4. Continuamente reconciliado: controladores observam o estado real e atuam para reduzir divergências.

Esses princípios são mais úteis que uma lista de ferramentas. Eles ajudam a avaliar se o processo continua GitOps mesmo quando a equipe muda de plataforma ou de provedor.

Como o fluxo GitOps funciona na prática

Imagine que uma nova imagem da aplicação foi criada. Em vez de executar um comando de deploy no cluster, o pipeline abre ou atualiza uma solicitação de mudança com a referência imutável do artefato.

A equipe revisa a alteração e faz o merge.

• O desenvolvedor altera código ou configuração.
• A integração contínua testa e produz um artefato versionado.
• Uma revisão aprova a nova versão no repositório de estado.
• O agente detecta a mudança e a puxa para o ambiente.
• O controlador aplica, verifica a saúde e continua reconciliando.

O agente opera de dentro do limite confiável do ambiente. Assim, o sistema de CI não precisa necessariamente manter uma credencial poderosa capaz de executar comandos diretamente no cluster.

GitOps vs. CI/CD vs. infraestrutura como código

Os conceitos se complementam, mas não são sinônimos. Um bom ponto de partida é conhecer CI/CD para iniciantes e a base de infraestrutura como código.

Prática	Papel principal	Resultado
CI	Compilar, testar e validar	Artefato confiável
Infraestrutura como código	Descrever e provisionar recursos	Infraestrutura reproduzível
CD	Preparar ou executar entregas	Nova versão disponível
GitOps	Buscar e reconciliar o estado desejado	Ambiente continuamente sincronizado

Uma organização pode usar IaC sem GitOps, por exemplo, ao executar scripts manualmente. Também pode ter CI/CD que envia alterações diretamente para produção.

GitOps adiciona a fonte declarativa, o modelo pull e a reconciliação contínua.

Arquitetura básica de uma operação GitOps

Uma arquitetura enxuta contém o repositório de código, o registro de artefatos, o repositório com o estado desejado, o reconciliador e os ambientes.

Métricas e alertas fecham o circuito operacional.

• Código-fonte: concentra a lógica e os testes da aplicação.
• Registro: armazena imagens ou pacotes identificados por versão ou digest.
• Estado desejado: declara versões, políticas e configurações por ambiente.
• Controlador: busca mudanças, calcula diferenças e reconcilia recursos.
• Observabilidade: informa saúde, atraso, falhas e divergências.

Em Kubernetes, os próprios recursos representam registros declarativos de intenção.

A documentação oficial explica como gerenciar objetos por configuração declarativa, base que combina naturalmente com controladores GitOps.

Também é importante separar a origem da configuração da origem dos artefatos. O repositório declara qual imagem deve rodar, enquanto o registro guarda seus bytes.

Essa divisão permite promover exatamente o mesmo pacote entre ambientes e evita que uma compilação tardia produza algo diferente do que foi testado.

Em operações maiores, cada agente pode observar apenas um conjunto de namespaces ou clusters.

Essa divisão reduz o impacto de uma credencial comprometida e impede que uma falha de configuração atravesse todos os limites de uma vez.

Dependências entre recursos devem ser explícitas: banco, operador e aplicação nem sempre podem ser reconciliados em qualquer ordem.

Como organizar repositórios e ambientes

Não existe uma estrutura universal. Um repositório único simplifica a descoberta e mudanças coordenadas; vários repositórios aumentam a separação de acesso e autonomia.

O critério deve ser o limite de responsabilidade, não uma preferência estética.

gitops/
  apps/
    pagamentos/
      base/
      homologacao/
      producao/
  clusters/
    homologacao/
    producao/

Pastas por ambiente costumam tornar diferenças explícitas e fáceis de revisar. Branches também funcionam, mas podem esconder divergências em históricos paralelos.

Seja qual for o desenho, proteja produção com regras de aprovação e responsáveis claros.

Promoção entre homologação e produção

Promover não deveria significar reconstruir a aplicação. O mesmo artefato aprovado em homologação deve avançar para produção; muda apenas a referência declarada no ambiente seguinte.

Isso reduz a chance de testar uma coisa e publicar outra.

A promoção pode ser manual, por pull request, ou automatizada após testes e políticas.

Em ambos os casos, a alteração precisa continuar visível no Git.

Estratégias como feature flags separam deploy de liberação: o código chega ao ambiente, mas a funcionalidade pode ser ativada depois.

Drift e reconciliação contínua

Drift é a diferença entre o estado declarado e o estado real. Ele surge por alterações manuais, falhas parciais, valores padrão do provedor ou recursos criados fora do processo oficial.

O reconciliador observa periodicamente as fontes e o ambiente. Dependendo da política, ele apenas alerta ou corrige a divergência.

O Flux, por exemplo, documenta fontes versionadas, reconciliação, controle de acesso, verificação de saúde e notificações como partes do fluxo.

Uma alteração feita com kubectl edit pode desaparecer no ciclo seguinte.

Para incidentes, estabeleça um procedimento de emergência: suspender a reconciliação de modo controlado, aplicar a correção, registrar evidências e levar a mudança de volta ao Git antes de reativar o agente.

Rollback: o que o Git reverte e o que ele não resolve

Reverter um commit restaura uma declaração anterior e dá ao controlador uma nova intenção.

Isso é poderoso para versões de imagem, réplicas e configurações compatíveis. Também deixa o motivo da reversão registrado.

Mas o Git não volta o relógio do mundo real. Uma migração que apagou uma coluna, uma mensagem processada ou um dado corrompido não é restaurado por um manifesto antigo.

Rollback exige compatibilidade entre versões, backup testado e mudanças de banco no padrão expandir-migrar-contrair.

Como tratar segredos sem expor credenciais

Git é uma excelente fonte de verdade para intenção, mas não deve armazenar senhas, tokens ou chaves em texto puro.

Apagar um segredo de um commit recente também não o remove automaticamente de clones e históricos.

• Mantenha o valor em um gerenciador externo e versione apenas a referência.
• Quando necessário, armazene conteúdo criptografado e controle as chaves fora do repositório.
• Dê ao agente somente o acesso necessário para o ambiente correspondente.
• Faça rotação, registre leituras e bloqueie segredos em revisões e pipelines.

O desenho precisa considerar quem pode alterar a referência, quem pode descriptografar o valor e onde o segredo será materializado.

GitOps melhora a rastreabilidade, mas não substitui gestão de identidades.

GitOps com bancos de dados e cargas stateful

Recursos stateful pedem cautela porque configuração e dados têm ciclos diferentes.

O manifesto pode declarar uma versão do serviço, mas a transição do esquema precisa ser coordenada com aplicações antigas e novas.

Trate migrações como operações observáveis e idempotentes, com pré-condições e estratégia de recuperação. Não presuma que reduzir a versão da aplicação desfará o banco.

Para componentes críticos, ensaie restauração e defina pontos explícitos de aprovação.

Segurança da cadeia de entrega

Quando o Git passa a controlar produção, proteger o repositório vira parte da segurança operacional.

Use autenticação forte, branches protegidas, revisão obrigatória, menor privilégio e separação entre quem propõe e quem aprova mudanças sensíveis.

Prefira artefatos imutáveis identificados por digest, valide assinaturas e políticas antes da reconciliação e limite o escopo de cada controlador.

O estudo de Git e GitHub ajuda a equipe a dominar o histórico no qual esse processo se apoia.

Observabilidade e operação do reconciliador

Um painel verde não basta. Monitore a versão da fonte observada, o tempo desde a última reconciliação bem-sucedida, recursos divergentes, falhas de aplicação, saúde da carga e erros de autorização.

Dois tempos merecem atenção separada. O primeiro vai do merge até o agente perceber a revisão; o segundo vai da percepção até o ambiente ficar saudável.

O primeiro revela atrasos de fonte ou webhook. O segundo expõe problemas de aplicação, dependência ou capacidade. Misturar os dois torna o diagnóstico mais lento.

Alertas devem apontar contexto acionável: repositório, revisão, ambiente, recurso e mensagem do controlador.

Uma base de observabilidade com OpenTelemetry pode correlacionar o deploy com métricas, logs e traces da aplicação.

Embora o modelo seja pull, webhooks podem acelerar a descoberta de uma mudança.

A documentação de webhook receivers do Flux mostra como disparar uma reconciliação sem transformar o remetente no executor do deploy.

Argo CD ou Flux: como comparar

Argo CD e Flux são projetos conhecidos para Kubernetes, mas a escolha deve partir da operação desejada.

Avalie experiência da equipe, interface, modelo de multi-tenancy, extensibilidade, automação de imagens, integração com políticas e comportamento diante de dependências.

Faça uma prova de conceito com o mesmo serviço e os mesmos critérios. Meça tempo de recuperação, clareza dos erros, consumo, atualização do controlador e facilidade de restringir acessos.

A melhor ferramenta é a que a equipe consegue operar com segurança, não a que tem a lista mais longa de recursos.

Quando vale a pena usar GitOps

GitOps tende a entregar mais valor quando existem vários serviços, clusters ou equipes; quando auditoria e reprodutibilidade importam; e quando mudanças manuais já provocam divergências.

Ele também combina bem com plataformas internas e ambientes Kubernetes. Se sua base ainda está começando, vale revisar Docker descomplicado e microsserviços para iniciantes.

Para um único servidor com poucas mudanças, o custo de controladores, repositórios e políticas pode superar o benefício.

Também há limitações quando a plataforma só aceita passos imperativos difíceis de reconciliar. Comece pelo problema operacional real, não pela tendência.

Outro sinal de alerta é adotar GitOps sem responsáveis pelo controlador. O agente vira parte do caminho crítico: precisa de atualização, backup de configuração, limites de recursos e procedimentos para indisponibilidade.

Automatizar a convergência não elimina operação; transfere parte dela para um componente que também precisa ser operado.

Plano de adoção em sete passos

1. Escolha um serviço de baixo risco e defina o estado que será declarado.
2. Separe configuração, artefatos e segredos, eliminando credenciais em texto puro.
3. Proteja o repositório com revisão, responsáveis e regras para produção.
4. Instale o reconciliador com permissões mínimas e escopo bem delimitado.
5. Ative primeiro detecção de drift e alertas; depois avalie autocorreção.
6. Teste promoção, falha parcial, rollback e o procedimento de emergência.
7. Meça frequência de mudanças, tempo de recuperação e intervenções manuais antes de expandir.

A mudança cultural é tão importante quanto a instalação. A equipe precisa confiar que o caminho mais rápido para uma alteração durável passa pelo repositório e pela revisão.

Perguntas frequentes

GitOps substitui CI/CD?

Não. A integração contínua continua testando e construindo artefatos. GitOps muda principalmente a forma como o estado aprovado chega ao ambiente e permanece reconciliado.

GitOps funciona sem Kubernetes?

Sim, desde que exista uma descrição declarativa, uma fonte versionada e um mecanismo de reconciliação. Kubernetes facilita o modelo por sua API declarativa e seus controladores, mas não é uma exigência conceitual.

Um webhook deixa o modelo menos seguro?

Não necessariamente. O webhook pode apenas avisar que há uma nova revisão. O agente ainda busca a fonte, valida o conteúdo e executa a reconciliação com sua própria identidade.

O agente desfaz uma correção manual?

Pode desfazer, se a autocorreção estiver habilitada e a mudança contrariar o estado desejado.

Por isso, incidentes precisam de um processo documentado de suspensão e posterior registro da correção no Git.

Cada ambiente precisa de um repositório?

Não. Ambientes podem ser separados por pastas, branches ou repositórios. A decisão depende de permissões, autonomia, escala e necessidade de promover mudanças sem duplicar configuração.

GitOps garante rollback sem indisponibilidade?

Não. Ele facilita restaurar uma declaração anterior, mas disponibilidade depende da estratégia de deploy, da compatibilidade da aplicação, do banco de dados e da saúde da infraestrutura.

Conclusão

GitOps transforma o Git em uma interface operacional: mudanças são propostas, revisadas, versionadas e reconciliadas continuamente.

A principal vantagem não é eliminar todo trabalho manual, mas tornar o estado desejado explícito e recuperar o controle quando a realidade diverge.

Comece pequeno, proteja a fonte de verdade, trate segredos fora do texto puro e teste rollback com dados reais.

Quando princípios, pessoas e ferramentas trabalham juntos, infraestrutura e deploys deixam de depender de memória e passam a seguir um processo reproduzível.