Blue-green e canary deploy: escolhendo uma estratégia gradual

Estratégias graduais reduzem exposição, mas só funcionam quando versões coexistem, métricas detectam regressões e o tráfego pode ser controlado.

Memorando de decisão: como publicar a versão 4.0? A aplicação recebe tráfego contínuo. A nova versão altera: frontend; API; mecanismo de cache; consulta de pedidos; um campo aditivo no banco. A equipe avalia quatro opções: 1. rolling update; 2. blue green; 3. canary; 4. feature flag. A pergunta não é qual nome representa maior maturidade. É: Qual estratégia limita o impacto desta mudança sem exigir uma plataforma que a equipe não consegue operar? Resumo executivo Estratégia Exposição inicial Retorno Custo de infraestrutura Exigência de telemetria Rolling update Parte das instâncias Reverter rollout Baixo a médio Média Blue green Troca de grande parcela ou total Reapontar tráfego Alto durante coexistência Média Canary Pequena parcela de tráfego Interromper canário Médio Alta Feature flag Público ou segmento definido Desligar comportamento Baixo a médio Alta All at once Todos imediatamente Novo deploy ou rollback Baixo Média Nenhuma estratégia protege contra: banco incompatível; dado corrompido; mensagem irreversível; observabilidade insuficiente; erro no próprio roteador; falha compartilhada entre versões. Caso avaliado Requisitos hipotéticos: Essas condições tornam blue green e canary possíveis. Sem elas, o debate seria prematuro. Rolling update: substituir aos poucos Fluxo: O Kubernetes Deployment usa parâmetros como: maxSurge ; maxUnavailable ; readiness; progresso; histórico de revisão. Exemplo: Vantagens: usa recursos gradualmente; mecanismo comum; simples para aplicações stateless; evita troca total. Limitações: versões coexistem; distribuição de tráfego acompanha quantidade de réplicas; pode não permitir análise sofisticada; a versão nova continua avançando se o healthcheck for insuficiente; rollback não corrige banco. Rolling update é adequado quando: mudanças são frequentes; versões são compatíveis; healthchecks são confiáveis; risco por instância é aceitável; não é necessário segmentar usuários. Ele já é uma estratégia gradual. Nem toda aplicação precisa de canary. Blue green: preparar tudo antes da troca A equipe valida o ambiente green. Depois: Em caso de falha, o tráfego pode retornar ao blue enquanto ele ainda estiver disponível. A documentação BlueGreen do Argo Rollouts descreve: activeService ; previewService ; análise antes da promoção; análise depois da promoção; atraso antes de reduzir a versão antiga. O preview permite testar a versão nova sem tráfego normal. Vantagens ambiente completo antes da promoção; troca rápida; versão anterior permanece pronta; testes de preview; rollback de tráfego rápido. Custos capacidade duplicada; aquecimento de cache; sincronização; propagação de rede; sessões; banco compartilhado; validação da troca. Blue green não significa ausência garantida de downtime. A própria documentação do Argo Rollouts alerta sobre atrasos de propagação e limitações específicas de alguns roteadores e load balancers. O banco continua único Se green executa: blue pode deixar de funcionar antes da troca de tráfego. Para blue green, o schema precisa tolerar as duas versões. Sequência: O plano de rollback precisa tratar aplicação e banco separadamente. Sessões também precisam sobreviver à troca Se a sessão fica na memória da instância blue, a troca pode desconectar usuários. Opções: armazenamento compartilhado; token verificável; sticky session temporária; migração; tolerância à reautenticação. Sticky session pode dificultar a transferência completa e esconder instâncias antigas. Teste: sessão criada em blue e usada em green; upload iniciado antes da troca; WebSocket; requisição longa; job em execução; conexão persistente. Canary: aprender com pequena exposição Canary envia uma parcela do tráfego para a nova versão. A documentação de Canary do Argo Rollouts permite definir pesos e pausas: Sem integração de roteamento, o peso pode ser aproximado pela proporção de réplicas. Com poucas réplicas, a granularidade é limitada. Canary não é apenas “esperar dez minutos” Cada etapa precisa responder: há volume suficiente; quais métricas comparar; qual baseline; quais segmentos; qual limite; qual duração; qual ação automática; quem acompanha. O Google SRE Workbook discute canários como comparação entre população de controle e versão candidata, usando sinais capazes de revelar regressão. O problema da amostra pequena Considere: Esse canário não produz evidência rápida. Em baixo volume, pode ser melhor: direcionar tráfego sintético; usar usuários internos; aumentar percentagem; ampliar a janela; usar blue green; executar validação manual; usar feature flag. Canary funciona melhor quando existe tráfego suficiente para distinguir sinal de variação normal. Métricas para promoção Não use apenas CPU e memória. Experiência taxa de sucesso; latência; abandono; conversão; erro funcional. Aplicação 5xx; exceções; timeouts; saturação; fila. Dependências banco; cache; serviço externo; quota. Negócio pedido; login; envio; pagamento; processamento. Compare A e B: Não apenas B contra um limite fixo. A observabilidade precisa incluir versão e ambiente nos sinais. Canary por usuário é diferente de canary por requisição Distribuição aleatória por requisição pode fazer a mesma pessoa alternar versões. Isso quebra: sessão; fluxo em múltiplas etapas; cache; comportamento de UI; estado. Segmentação possível: cookie; conta; organização; região; header; cohort; hash estável. Exemplo: direciona aproximadamente 5% das identidades de forma estável. Cuidados: privacidade; representatividade; concentração de clientes; usuários internos; bots; diferenças regionais. Canary não é teste A/B Canary Objetivo: detectar regressão e verificar segurança da release. Pergunta: A versão nova é pelo menos tão saudável quanto a atual? A/B test Objetivo: comparar resultados de produto ou comportamento. Pergunta: Qual variante produz melhor resultado? Os dois podem usar divisão de tráfego, mas possuem: hipóteses; métricas; duração; análise; consentimento; governança; diferentes. Não promova código instável porque converteu melhor. Feature flag: deploy sem ativação total Vantagens: ativação sem novo deploy; segmentação; retorno rápido; separação entre entrega e lançamento. Custos: dois caminhos de código; combinações de flags; dívida; estado no serviço de flags; testes; auditoria; segurança. Feature flag não substitui blue green quando a mudança afeta: runtime; biblioteca; memória; inicialização; schema; infraestrutura; dependência. O código defeituoso ainda está carregado. Comparação por decisão Escolha rolling update quando aplicação é stateless; risco é moderado; healthchecks são bons; coexistência é compatível; simplicidade importa. Escolha blue green quando capacidade duplicada cabe; preview completo é valioso; troca total é aceitável; rollback de tráfego precisa ser rápido; banco permite coexistência. Escolha canary quando existe tráfego suficiente; métricas por versão são confiáveis; divisão de tráfego é controlável; impacto precisa ser limitado; a equipe consegue analisar e interromper. Escolha feature flag quando comportamento pode ser isolado; segmentação por usuário importa; lançamento e deploy devem ser separados; há governança de flags. Combine estratégias quando necessário Exemplo: Combinar também multiplica complexidade. Custos esquecidos do blue green dobro de instâncias; warming; endereços; certificados; registros; preview; capacidade do banco; filas; jobs duplicados. Se blue e green executam schedulers, ambos podem disparar a mesma tarefa. Defina: qual stack processa cron; qual consome fila; qual envia e mail; qual executa migração. A stack de preview não deve produzir efeitos reais sem controle. Custos esquecidos do canary roteamento ponderado; labels por versão; queries comparativas; amostragem; duração; análise; abort automático; representação dos usuários; suporte a versões simultâneas. Um canário mal instrumentado apenas expõe menos pessoas durante mais tempo. A estratégia precisa de estado explícito Máquina de estados: Registre: versão; peso; horário; métricas; decisão; aprovador; motivo; resultado. Não dependa de saber “qual Deployment parece ser o atual”. Gates automáticos e humanos Automático: readiness; erro; latência; saturação; smoke test; segurança; integridade. Humano: feedback visual; comportamento raro; validação de produto; risco contextual; comunicação. A promoção automática precisa de: métrica confiável; janela; baseline; tratamento de ausência de dados; rollback; limite. Se a plataforma de métricas estiver indisponível, o comportamento seguro normalmente é pausar ou abortar, não promover sem evidência. Exemplo de política Valores hipotéticos. A política precisa ser testada com falhas simuladas. Plano de prova de conceito Antes de usar em produção: 1. publique uma versão sem alteração funcional; 2. distribua tráfego; 3. confirme labels por versão; 4. injete erro controlado; 5. verifique detecção; 6. aborte; 7. confirme retorno; 8. repita com latência; 9. teste telemetria indisponível; 10. teste banco compatível; 11. teste sessão; 12. registre esforço. A prova não termina quando o dashboard mostra dois conjuntos de Pods. Ela termina quando a equipe consegue: promover; pausar; abortar; recuperar; explicar o que aconteceu. Decisão para o caso hipotético A aplicação possui: tráfego suficiente; métricas por versão; roteamento ponderado; banco aditivo; capacidade de coexistência. Decisão: Blue green também seria viável, mas exigiria troca ampla de tráfego e capacidade duplicada. O canário produz evidência gradual sob carga real. Para uma aplicação menor, com baixo tráfego e operação simples, blue green ou rolling update poderiam ser melhores. Critério final Não escolha uma estratégia pelo nome. Escolha quando conseguir responder: como duas versões coexistem; como o tráfego é controlado; quais usuários entram; como regressão é medida; quando a promoção para; como aplicação e banco voltam; quanto custa manter versões simultâneas; quem responde pelo processo. Progressive delivery não é distribuir o risco em percentuais. É criar uma sequência em que cada aumento de exposição depende de evidência suficiente para justificar o próximo.