GitOps na prática: como desenhar um pipeline CI/CD escalável com GitLab e GKE

Um pipeline CI/CD escalável com GitLab e GKE não se constrói copiando YAMLs de tutoriais. A diferença entre funcionar em dev e operar em produção com cinco ambientes está na arquitetura: reconciliação pull, repositórios separados para código e manifestos, e promoção por merge requests. O modelo push, onde o runner do GitLab executa kubectl apply diretamente no cluster, expõe credenciais e aumenta a superfície de ataque. Já o pull, com o GitLab Agent e Flux dentro do GKE, garante que o cluster nunca precise aceitar conexões externas. Isso não é detalhe técnico, é a base de uma postura de segurança defensiva.

Separar o repositório de aplicação do de manifestos elimina drift e conflitos de merge. Quando o ambiente é um diretório, staging/, prod/, e não uma branch, promover uma versão vira um commit que atualiza apenas a tag da imagem. Cada mudança é pequena, auditável e reversível. O GitLab Duo não escreve pipelines, mas acelera a correção de erros: ao identificar logs de falha e sugerir ajustes diretos no merge request, ele faz com que o time encontre problemas antes da staging, não da produção.

Essas escolhas não são boas práticas abstratas, são o que separa times que entregam com confiança de times que vivem em firefighting. Trabalhar com Workload Identity Federation em vez de service account keys evita vazamentos de credenciais que já derrubaram centenas de clusters. Usar o External Secrets Operator para puxar segredos do Google Secret Manager mantém valores sensíveis fora do Git e dos variáveis de pipeline. Medir DORA metrics, especialmente lead time e change failure rate, transforma a pergunta "o pipeline está lento?" em uma ação concreta: talvez o gate manual de staging esteja atrasando tudo. Não é sobre usar mais ferramentas. É sobre usar as certas com propósito.