IA Muda CI/CD de Velocidade para Controle de Risco

Robert Erez, principal engineer na Octopus Deploy, discutiu decisões de deployment que quebram times em escala em um episódio recente de The Pragmatic Engineer com Gergely Orosz. Ele abordou Kubernetes, GitOps, feature flags e a mudança na economia de CI/CD quando agentes de IA fazem ship de código.

**IA muda o cálculo de CI/CD de velocidade para risco.** Para desenvolvedores humanos, um build de dez minutos reduz a produtividade. Para um agente de IA sem overhead de context-switching, dez minutos é irrelevante. A questão real é se o agente faz ship de um bug para produção. Erez recomenda colocar testes completos à frente—até mais lentos—em vez de otimizar para tempo de build real. Times construídos em torno de CI rápido para throughput humano precisam se recalibrar.

Em serviços com estado, Erez é inequívoco: sempre avance (roll forward), nunca retroceda. Quando um deployment muda um schema de banco de dados, reverter v2 para v1 deixa o código da aplicação desalinhado do schema. A solução é v3 com a correção—crítico para stacks de inferência de IA apoiados por vector stores, tabelas de metadata de fine-tune ou qualquer sistema de memória acoplado ao banco de dados. Rollback é inseguro uma vez que estado está envolvido.

Para resposta a incidentes, feature flags vencem rollbacks. Desativar uma feature impede danos sem fazer redeploy às 2 da manhã. O custo: flags se acumulam. Erez compara a limpeza com jardinagem—toggles desenterrados transformam o codebase em um labirinto de lógica condicional. Times executando muitos experimentos com features de IA devem tratar o ciclo de vida de flags como uma tarefa de primeira classe.

GitOps atinge um teto concreto em escala. Erez descreve organizações executando milhares de clusters Kubernetes independentes puxando estado de um único repositório Git. O repo se torna o gargalo—clusters são estrangulados e times recorrem a workarounds. Os quatro pilares de GitOps (declarativo, versionado e imutável, baseado em pull, continuamente reconciliado) não requerem Git, mas a indústria confunde o termo com "colocar tudo em um repo"—incluindo secrets que não deveriam estar lá.

Ambientes efêmeros substituíram staging estático para times executando bem. Crie um ambiente full-stack por feature branch, avalie pré-merge, destrua no merge. Para times de IA, este é o harness de avaliação natural—execute o agente contra um ambiente efêmero ativo em vez de unit tests mockados. Erez não prescreve tooling; a mudança operacional é o que importa.

Erez separa continuous deployment de continuous delivery deliberadamente. Continuous deployment envia cada commit para produção automaticamente. Continuous delivery significa que cada commit é deployável mas o push final é opcional—automatize ou clique um botão uma vez por semana. A maioria dos times não precisa de continuous deployment e obtém mais valor validando o processo de deployment através de continuous delivery.

Se seu pipeline de CI/CD foi ajustado para throughput de desenvolvedor humano, a era do agente de IA demanda um alvo diferente. Profundidade de cobertura de testes e controles de risco de deployment—feature flags, disciplina de roll-forward, ambientes efêmeros de avaliação—superam velocidade de build como os principais alavancas.