ArgoCD vs CI fazendo deploy: qual modelo escolher

Se sua esteira de CI (GitHub Actions, GitLab CI, Jenkins) já builda a imagem, roda os testes e termina com um kubectl apply ou helm upgrade, você já está entregando continuamente. A pergunta não é "isso funciona?" — funciona, e muita empresa opera assim em produção há anos. A pergunta é: em que ponto esse modelo começa a custar mais caro do que um controlador GitOps como o Argo CD, e quando vale trocar.

Premissas deste post

Antes de entrar no comparativo, duas observações importantes sobre as fontes:

• A base factual sobre o Argo CD usada aqui vem da documentação oficial de Core Concepts, que é puramente conceitual — define termos como Application, sync, target state e live state, sem cobrir instalação, versões ou comandos de CLI.
• Não há, nas fontes disponíveis para este post, nenhum material específico sobre como pipelines de CI tradicionais executam deploy (push-based). A seção sobre esse modelo descreve um padrão de mercado amplamente documentado e observável em ferramentas como GitHub Actions, GitLab CI e Jenkins, mas não cita fonte única porque não há uma "especificação oficial" do padrão — é uma prática, não um produto. Trate essa parte como descrição conceitual, não como citação de documentação.

Nenhum comando deste post foi executado neste ambiente; são exemplos ilustrativos para orientar a decisão.

Cenário: por que essa escolha aparece

Times que já têm CI funcionando normalmente chegam a essa decisão de duas formas: alguém levanta um incidente de segurança (credenciais de cluster vivendo no runner de CI) ou alguém nota "drift" — o cluster tem algo que não existe mais no Git, e ninguém sabe quando ou como aquilo foi aplicado.

Os dois cenários apontam para o mesmo ponto: o modelo de entrega push, onde a pipeline de CI tem credenciais para falar diretamente com o cluster, concentra responsabilidade e risco num único lugar. O Argo CD propõe inverter essa relação.

Os dois modelos, em termos concretos

CI fazendo o deploy (push-based). A pipeline builda, testa e, na última etapa, autentica no cluster e aplica o manifesto. O cluster é passivo: ele só recebe o que o runner de CI enviar. Isso exige que o runner tenha, em algum momento, credenciais com permissão de escrita no cluster (kubeconfig, service account token, chave de cloud).

Argo CD (pull-based / GitOps). Segundo a documentação oficial, uma Application no Argo CD é um conjunto de recursos Kubernetes definidos por um manifesto, implementado como um Custom Resource Definition (CRD). O Argo CD roda dentro do cluster, observa um repositório Git (o target state) e compara continuamente com o que está de fato rodando (o live state). Quando os dois estados divergem, o Argo CD calcula o sync status e pode executar um sync — o processo que move o cluster para o estado desejado. A CI, nesse modelo, para no build e no push da imagem/manifesto para o Git; ela nunca fala diretamente com o cluster.

A diferença de direção é o ponto central: no push, a pipeline de CI entra no cluster. No pull, o controlador dentro do cluster é quem busca a mudança no Git.

Critérios práticos para decidir

Onde moram as credenciais do cluster

No modelo push, toda pipeline de CI que faz deploy precisa de credenciais de escrita no cluster — e isso normalmente significa secrets replicados em múltiplos repositórios ou runners. No modelo pull, só o Argo CD (rodando dentro do cluster) precisa dessas credenciais; a CI não toca nelas. Se seu critério principal é reduzir superfície de exposição de credenciais, isso pesa fortemente para o pull-based.

Detecção de drift

Mudanças manuais (kubectl edit, hotfix de emergência) não deixam rastro automático num pipeline CI tradicional — o cluster simplesmente passa a divergir do que está versionado, e ninguém é avisado. O Argo CD, pelo conceito de refresh (comparação entre o código mais recente no Git e o live state) e health (se a aplicação está de fato saudável), sinaliza esse desvio continuamente. Isso não impede alguém de rodar kubectl edit, mas torna a divergência visível no painel do Argo CD, em vez de descoberta só no próximo deploy.

Auditoria e rastreabilidade do "quem aplicou o quê"

No push, a trilha de auditoria está espalhada entre logs do runner de CI e, se houver, logs de admissão do cluster. No pull, a sync operation status do Argo CD registra se cada operação de sincronização foi bem-sucedida, e o histórico de sync fica centralizado na própria ferramenta GitOps — mais fácil de consultar quando algo quebra.

Rollback

No push, reverter normalmente significa rodar de novo a pipeline apontando para uma revisão anterior — depende da pipeline estar disponível e configurada para isso. No pull, como o Argo CD trabalha comparando contra o Git, reverter costuma ser um git revert (ou apontar a Application para outra revisão); o controlador detecta a divergência e sincroniza de volta.

Complexidade operacional e curva de adoção

Esse é o ponto onde o pêndulo volta para o CI puro. Rodar Argo CD é operar mais um componente dentro do cluster: CRDs, RBAC próprio, um controlador que precisa de atenção em upgrades. Para um time pequeno, com poucos ambientes e deploys pouco frequentes, esse custo operacional pode não se justificar frente ao ganho de segurança e auditabilidade.

Velocidade de feedback no pipeline

No push, o resultado do deploy aparece no próprio log da pipeline, em sequência com build e testes — é direto para quem só quer ver "passou ou falhou" num único lugar. No pull, o deploy acontece de forma assíncrona em relação à pipeline: a CI termina quando empurra a mudança pro Git, e o resultado do sync aparece em outro lugar (painel ou CLI do Argo CD). Isso exige acostumar o time a olhar dois lugares, ou integrar notificações.

Diferenças práticas resumidas

Quando cada modelo faz mais sentido

Mantenha CI fazendo o deploy se: o time é pequeno, o número de ambientes é baixo, a frequência de deploy não justifica operar um controlador adicional, ou a pipeline já tem controles compensatórios sólidos (secrets de curta duração, aprovação manual, auditoria de admissão no cluster).

Migre para Argo CD (ou outro controlador GitOps) se: você opera múltiplos clusters ou ambientes, precisa demonstrar auditoria de mudanças (compliance, segurança), já sofreu com drift não detectado, ou quer parar de distribuir credenciais de cluster entre vários pipelines de CI.

Um modelo híbrido é comum na prática: a CI continua responsável por build, testes e push da imagem/manifesto para o Git; o Argo CD assume exclusivamente a parte de aplicar no cluster. Isso resolve o problema de credenciais sem abandonar a pipeline que o time já conhece.

Limitação a registrar

Este comparativo descreve o padrão geral de cada modelo com base em conceitos documentados do Argo CD e em práticas de mercado amplamente conhecidas, mas não existe, nas fontes usadas, dado quantitativo (tempo de deploy, taxa de incidente, custo de operação) comparando os dois modelos. Se sua decisão depender de números, trate os pontos acima como critérios de investigação, não como resultado pronto — meça drift, tempo médio de rollback e exposição de credenciais no seu próprio ambiente antes de migrar.

Próximo passo

Se você já tem CI fazendo deploy e está em dúvida, não troque tudo de uma vez: escolha uma aplicação de baixo risco, coloque o Argo CD gerenciando só ela em modo sync manual, e compare por duas semanas o tempo de rollback e a visibilidade de drift contra o que você tem hoje na pipeline de CI.