Deploy não deveria ser um evento tenso. Se toda entrega envolve alguém rodando comandos na mão, torcendo para não esquecer um passo, você não tem um processo — tem um ritual de fé. GitOps resolve isso transformando o deploy em algo declarativo, versionado e reversível. Veja como.

A ideia central do GitOps

GitOps parte de um princípio simples e poderoso: o Git é a fonte da verdade. O estado desejado do seu ambiente — quais aplicações, quais versões, qual configuração — vive em um repositório Git. Uma ferramenta observa esse repositório e faz o cluster convergir para o que está declarado.

O efeito é profundo:

• Tudo é auditável. Cada mudança de ambiente é um commit, com autor, data e revisão.
• Rollback é trivial. Voltar ao estado anterior é reverter um commit.
• Sem drift. Se alguém muda algo direto no cluster, a ferramenta detecta a divergência e corrige.
• Deploy sem acesso manual ao cluster. Você altera o Git; a ferramenta aplica. Menos mãos no ambiente, menos erro.

Há um ganho de segurança que passa despercebido: no modelo em que o agente dentro do cluster busca o estado desejado, o pipeline de CI não precisa de credencial de administrador do cluster. Ninguém, e nenhum robô externo, precisa de acesso de escrita ao ambiente de produção — o que remove um dos alvos mais valiosos de qualquer ataque a cadeia de entrega.

CI e CD: papéis diferentes

Vale separar os dois:

• CI (Integração Contínua): a cada mudança de código, roda testes e constrói a imagem do container. Garante que o que chega ao repositório funciona.
• CD (Entrega/Deploy Contínuo): pega o artefato pronto e o coloca no ambiente. No GitOps, o CD é dirigido pelo Git.

O CI valida e empacota; o GitOps entrega. Juntos, formam o pipeline completo.

Dois repositórios, não um

A organização que mais evita confusão separa:

• Repositório de aplicação: código-fonte, testes e o Dockerfile. O CI vive aqui e produz uma imagem versionada.
• Repositório de configuração: os manifestos declarativos de cada ambiente. É o que a ferramenta de GitOps observa.

Separar dá independência entre "mudar o código" e "mudar o que está em produção" — e permite que a revisão de uma promoção de versão seja um pull request curto, revisável em segundos, sem misturar com discussão de implementação.

O elo entre os dois é a única parte que exige decisão: como a versão nova chega ao repositório de configuração? Duas opções funcionam bem. O próprio CI abre um commit ou pull request atualizando a tag da imagem — explícito, auditável, integrável com aprovação. Ou um componente observa o registry e atualiza automaticamente conforme uma política de versões — mais rápido, menos cerimônia. Ambientes de produção regulados tendem à primeira; ambientes de desenvolvimento se beneficiam da segunda.

ArgoCD: o motor do GitOps no Kubernetes

O ArgoCD é a ferramenta que faz o Kubernetes seguir o Git. Ele monitora o repositório, compara o estado declarado com o estado real do cluster e sincroniza. Na interface, você vê exatamente o que está em sincronia, o que divergiu e o histórico de cada aplicação. Se algo saiu do lugar, o ArgoCD mostra — e corrige.

Quatro recursos valem conhecer desde o começo, porque definem o comportamento do dia a dia:

• Sincronização automática, para que um merge chegue a produção sem intervenção.
• Remoção de recursos órfãos, apagando do cluster o que saiu do Git. Poderoso e afiado: ative com consciência.
• Autocorreção, revertendo mudanças feitas manualmente no cluster. É o que garante que o Git continue sendo a verdade.
• Ordem de aplicação em ondas, para que banco, migração e aplicação subam na sequência correta em vez de tudo ao mesmo tempo.

Para muitos serviços, vale o padrão em que uma aplicação raiz declara todas as outras. Assim, adicionar um serviço novo ao cluster é um commit, e a lista completa do que roda em produção fica em um único lugar legível.

Helm: empacotando aplicações

Escrever manifests Kubernetes crus para cada ambiente vira repetição e erro. O Helm empacota a aplicação em charts parametrizáveis: o mesmo chart serve dev, staging e produção, mudando apenas os valores (réplicas, recursos, domínios). Combinado com o ArgoCD, você tem aplicações versionadas e configuráveis, com uma única definição para vários ambientes.

Existe uma alternativa que convive bem com ele, e a escolha depende do que você está resolvendo:

Na prática, muitos times usam charts para o que vem de fora e sobreposições para as próprias aplicações. Misturar os dois modelos de forma consciente é normal; o que gera dor é ter três formas diferentes de fazer a mesma coisa no mesmo repositório.

Ambientes: pastas, não branches

A tentação de ter uma branch por ambiente é grande e cobra caro: as branches divergem, o cherry-pick vira rotina e ninguém sabe mais o que está onde. O padrão que se sustenta é uma pasta por ambiente na mesma branch, com a base comum e as diferenças explícitas em arquivos de valores.

Promover uma versão passa a ser o que deveria ser: alterar uma linha na pasta do ambiente de destino, com revisão de quem precisa aprovar. E a diferença entre homologação e produção fica visível em um diff, em vez de escondida no histórico.

Segredos: o problema que o GitOps expõe

Se tudo está no Git, onde ficam senhas e tokens? Nunca em texto claro no repositório — e a resposta não é abrir exceção manual, que quebraria a premissa toda. Três caminhos consolidados:

• Segredos cifrados no próprio repositório, que só o cluster consegue decifrar com a chave privada que vive nele.
• Referências a um gerenciador externo, com um operador no cluster buscando o valor real em tempo de aplicação. É o caminho mais escalável quando já existe um cofre corporativo.
• Arquivos cifrados com ferramenta de criptografia de arquivos, decifrados no momento da sincronização.

Qualquer um dos três preserva a auditoria sem colocar segredo no repositório. O que não funciona é a quarta opção informal: aplicar segredos na mão e esquecer de documentar. Seis meses depois, ninguém sabe reconstruir o ambiente.

Estratégias de entrega além do rolling update

Com a base declarativa pronta, dá para escolher como a versão nova entra:

• Atualização gradual: substituição progressiva das réplicas. Simples e suficiente para a maioria.
• Azul-verde: duas versões completas de pé, com a troca de tráfego em um passo. Rollback instantâneo, ao custo do dobro de recurso durante a transição.
• Canário: uma fração do tráfego vai para a versão nova, com avanço automático conforme as métricas se comportam. É o modelo que mais reduz o impacto de um problema, e o que mais exige observabilidade confiável.

Canário sem métrica boa é teatro. Se você não tem taxa de erro e latência por versão, comece pela observabilidade.

Rollback é trivial — com uma exceção importante

Reverter um commit devolve a configuração anterior em minutos. Mas há um limite que precisa ser dito com clareza: migração de banco de dados não volta com git revert. Se a versão nova alterou o schema de forma destrutiva, reverter a aplicação a coloca conversando com um banco incompatível.

A prática que resolve é escrever migrações compatíveis com as duas versões: primeiro adiciona-se a estrutura nova sem remover a antiga, depois a aplicação passa a usá-la, e só em uma terceira etapa — dias depois, com confiança — remove-se o que sobrou. Dá mais trabalho e é o que torna o rollback realmente seguro.

O ganho real para o negócio

Não é sobre a ferramenta bonita. É sobre entregar mais rápido com menos risco: deploys frequentes e pequenos, rollback imediato quando necessário, e um histórico que responde "quem mudou o quê, quando e por quê" sem investigação. Isso reduz o custo de cada entrega e o estresse de cada release.

Para auditoria e conformidade, o efeito colateral é valioso: cada mudança em produção tem autor, revisor, data e justificativa, sem que ninguém precise manter uma planilha paralela.

O pré-requisito honesto

GitOps brilha em cima de uma base sã. Se você ainda não tem containers bem feitos e um CI mínimo rodando testes, comece por aí. GitOps sobre um alicerce instável só automatiza o caos mais rápido.

Erros comuns

• Alterar o cluster na mão e brigar com a autocorreção, em vez de mudar o Git.
• Uma branch por ambiente, com divergência crescente.
• Remoção automática de órfãos ativada sem entender o alcance.
• Segredos aplicados manualmente e não documentados.
• Ferramenta de GitOps instalada sem alta disponibilidade nem backup da própria configuração.
• Nenhuma ordem de aplicação, com migração de banco competindo com a subida da aplicação.
• Canário decidido por sensação, sem métrica por versão.

Onde a Solvefy/Cloud entra

Nossa consultoria DevOps implanta pipelines de CI/CD e GitOps com ArgoCD e Helm — do CI que testa e empacota ao CD declarativo que entrega — com observabilidade junto e transferência de conhecimento. Cobrada por hora, com escopo definido.

Quer entregas previsíveis? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.