CI/CD Moderno: Pipelines Automatizados com GitHub Actions e ArgoCD

Pipelines de CI/CD sao a espinha dorsal da entrega de software moderna. Em 2026, GitHub Actions domina o CI e ArgoCD lidera o CD para Kubernetes com a abordagem GitOps. Este guia mostra como construir pipelines de producao que automatizam desde o commit ate a entrega em producao.

CI vs CD: entendendo a diferenca

Continuous Integration (CI) e a pratica de integrar codigo frequentemente com verificacoes automatizadas: testes unitarios, testes de integracao, analise estatica, verificacao de seguranca e build da aplicacao. Cada push ou pull request dispara o pipeline.

Continuous Delivery (CD) automatiza o processo de deploy ate producao. Continuous Delivery requer aprovacao manual antes do deploy em producao. Continuous Deployment faz deploy automatico apos todas as verificacoes passarem.

GitHub Actions: CI completo

GitHub Actions usa workflows definidos em arquivos YAML no diretorio .github/workflows do repositorio. Conceitos: Workflow e o pipeline completo disparado por eventos. Job e um conjunto de steps que rodam no mesmo runner. Step e uma acao individual como checkout, install ou test. Action e uma acao reutilizavel do marketplace ou customizada.

Workflow de CI para uma aplicacao Node.js tipica inclui: trigger em push e pull request, matrix strategy para testar em multiplas versoes do Node, checkout do codigo, instalacao de dependencias, lint, testes unitarios, build, upload de artefatos.

Otimizacoes importantes: cache de dependencias com actions/cache para npm pip ou gems reduzindo tempo de install de minutos para segundos. Matrix strategy para testar em multiplas versoes simultaneamente. Concurrency para cancelar workflows obsoletos quando novos commits sao feitos. Paths filter para rodar workflows apenas quando arquivos relevantes mudam.

ArgoCD: GitOps para Kubernetes

GitOps e o principio de usar Git como unica fonte de verdade para infraestrutura e deploy. ArgoCD implementa GitOps monitorando repositorios Git e sincronizando automaticamente o estado desejado com o cluster Kubernetes.

Como funciona: voce define manifests Kubernetes ou Helm charts em um repositorio Git. ArgoCD monitora esse repositorio continuamente. Quando detecta diferenças entre o Git e o cluster, sincroniza automaticamente ou notifica para aprovacao manual. Todo deploy e um commit no Git e todo rollback e um git revert.

Beneficios do GitOps com ArgoCD: auditoria completa pois todo deploy esta registrado no historico do Git. Rollback instantaneo revertendo ao commit anterior. Disaster recovery pois o estado desejado esta sempre no Git bastando apontar ArgoCD para um novo cluster. Multi-cluster gerenciando deploys em multiplos clusters Kubernetes a partir de um unico ArgoCD.

Pipeline completo: CI com GitHub Actions e CD com ArgoCD

Fluxo de producao: desenvolvedor cria pull request. GitHub Actions executa CI com testes, lint e security scan. Pull request e aprovado e merged na main. GitHub Actions faz build da imagem Docker e push para registry. GitHub Actions atualiza o manifesto Kubernetes no repositorio de deploy com a nova tag da imagem. ArgoCD detecta a mudanca no repositorio de deploy e sincroniza com o cluster. ArgoCD valida saude do deploy e notifica resultado.

A separacao de repositorios de codigo e deploy e uma boa pratica do GitOps. O repositorio de aplicacao contem codigo fonte e pipeline de CI. O repositorio de deploy contem manifests Kubernetes e configuracoes de ambiente. Essa separacao limita permissoes e permite que diferentes equipes gerenciem codigo e infraestrutura independentemente.

Estrategias de deploy

Rolling Update atualiza pods gradualmente mantendo o servico disponivel. E o padrao do Kubernetes. Configuravel por maxUnavailable e maxSurge.

Blue-Green Deploy mantém dois ambientes identicos. O trafego e direcionado ao ambiente verde enquanto o azul e atualizado. Apos verificacao o trafego e redirecionado. Rollback instantaneo se necessario.

Canary Deploy direciona uma porcentagem pequena do trafego para a nova versao enquanto o restante usa a versao anterior. Se nao houver problemas a porcentagem aumenta gradualmente ate 100%. Istio ou Flagger automatizam canary com analise automatica de metricas.

Monitoramento do pipeline

Metricas importantes de CI/CD: Lead Time for Changes mede o tempo do commit ate producao. Deployment Frequency mede quantos deploys por dia ou semana. Mean Time to Recovery (MTTR) mede quanto tempo leva para se recuperar de uma falha. Change Failure Rate mede a porcentagem de deploys que causam problemas.

Equipes de elite (DORA metrics) fazem deploy multiplas vezes por dia com lead time menor que 1 hora, MTTR menor que 1 hora e change failure rate menor que 15%.