# Canary vs blue-green deployment: qual estratégia > Canary deployment e blue-green deployment são estratégias de liberação de software que diferem na forma de expor usuários à nova versão. Canary deployment direciona gradualmente uma pequena parcela do tráfego para a nova versão, enquanto blue-green deployment mantém dois ambientes completos e alterna todo o tráfego de uma só vez. A escolha depende do apetite a risco, orçamento de infraestrutura e maturidade de observabilidade. *Blog Sem Juízo · Especiais · 13 de setembro de 2026 · Sol Henriques* Canary deployment e blue-green deployment resolvem o mesmo problema de formas opostas: um troca o tráfego aos poucos, o outro de uma vez. A escolha depende do apetite a risco, do orçamento de infraestrutura e da maturidade de observabilidade do time. Canary deployment e blue-green deployment resolvem o mesmo problema de formas opostas: um troca o tráfego aos poucos, o outro de uma vez. A escolha depende do apetite a risco, do orçamento de infraestrutura e da maturidade de observabilidade do time. ## Como cada estratégia entrega a nova versão No blue-green, você mantém dois ambientes idênticos: o azul (versão atual) e o verde (versão nova). Quando o verde está pronto, o roteador aponta 100% do tráfego para ele. Se algo quebrar, o rollback é só voltar o ponteiro para o azul, em segundos. No canary, a nova versão entra em produção ao lado da antiga, mas recebe uma fatia pequena do tráfego, algo como 1% a 5%. Se as métricas de erro, latência ou conversão se mantiverem estáveis, essa fatia cresce gradualmente até 100%. É o modelo que o Google popularizou ao testar versões com um grupo reduzido de servidores antes do lançamento geral. A diferença prática: no blue-green, o risco é binário (ou o verde funciona, ou você volta tudo). No canary, o risco é distribuído e você aprende com dados reais antes de expor todos os usuários. ## Custo de infraestrutura e operação Blue-green exige o dobro de recursos ativos durante a janela de deploy: dois ambientes completos rodando ao mesmo tempo. Em um cluster Kubernetes, isso significa provisionar o dobro de pods e manter bancos de dados compatíveis com as duas versões. Canary também precisa de dois ambientes, mas o novo recebe só uma fração do tráfego, então o custo adicional é proporcional à fatia liberada. A contrapartida é a complexidade operacional: roteamento por peso, métricas segmentadas por versão e automação para promover o canary sem intervenção manual. | Critério | Blue-green | Canary | |---|---|---| | Troca de tráfego | 100% de uma vez | Gradual (1% → 100%) | | Rollback | Instantâneo (troca de ponteiro) | Rápido, mas depende de automação | | Custo de infraestrutura | Alto (dois ambientes completos) | Médio (fatia controlada) | | Observabilidade exigida | Média | Alta (métricas por versão) | | Complexidade de setup | Menor | Maior | ## Quando cada uma faz mais sentido Blue-green brilha em sistemas monolíticos, com poucas dependências e times que precisam de rollback imediato. É a escolha natural quando a janela de manutenção é curta e o custo de manter dois ambientes é aceitável, como em aplicações internas ou APIs com tráfego previsível. Canary se destaca em microsserviços, onde uma mudança pode afetar apenas um componente e o time quer validar hipóteses com usuários reais. Também é útil quando o produto tem métricas de negócio claras (taxa de conversão, tempo de resposta) que permitem decidir se vale promover a versão. Um contraexemplo comum: equipes pequenas que adotam canary sem observabilidade madura acabam com um deploy lento e difícil de diagnosticar. Nesses casos, blue-green entrega mais valor com menos esforço. ## Ferramentas e integração no pipeline Ambas as estratégias se apoiam em orquestradores e service meshes. Kubernetes com Istio ou Linkerd permite roteamento por peso para canary e troca de serviço para blue-green. Ferramentas como Argo Rollouts e Flagger automatizam a promoção gradual com base em métricas do Prometheus. A escolha da ferramenta importa menos que a disciplina de medir. Sem métricas confiáveis, canary vira só um deploy mais lento; sem automação de rollback, blue-green vira uma aposta. ## Veredito Para quem busca simplicidade, rollback instantâneo e tem orçamento para manter dois ambientes, blue-green é a escolha mais direta. Para quem opera microsserviços, quer validar mudanças com dados reais e já investe em observabilidade, canary oferece controle mais fino e risco menor por usuário. Não existe vencedor absoluto: existe a estratégia que combina com a maturidade do seu time e o custo que você aceita pagar. ## FAQ ### Qual estratégia tem rollback mais rápido? Blue-green, porque basta redirecionar o tráfego de volta ao ambiente antigo, que já está pronto. Canary também permite rollback rápido, mas depende de automação para reverter a distribuição de tráfego e pode deixar usuários expostos por mais tempo. ### Canary deployment precisa de mais infraestrutura que blue-green? Não necessariamente. Canary pode rodar com uma fração pequena de recursos, enquanto blue-green exige dois ambientes completos ativos durante o deploy. O custo real depende de como você provisiona e desliga os ambientes. ### É possível combinar canary e blue-green no mesmo pipeline? Sim. Alguns times usam blue-green para trocar a versão base e canary para testar funcionalidades específicas dentro do ambiente novo. A combinação aumenta a complexidade, mas oferece controle granular sobre risco e custo. ### Qual estratégia é mais indicada para microsserviços? Canary costuma se encaixar melhor, porque permite liberar a mudança em um serviço específico sem afetar todo o sistema. Blue-green em microsserviços pode exigir duplicar muitos componentes, elevando o custo operacional. ### Preciso de service mesh para implementar canary? Não é obrigatório, mas facilita muito. Service meshes como Istio e Linkerd oferecem roteamento por peso e métricas por versão sem alterar o código da aplicação. Sem elas, é preciso construir essa lógica manualmente. ### Qual estratégia reduz mais o risco de incidentes em produção? Canary tende a reduzir o impacto por usuário, já que expõe apenas uma fração do tráfego. Blue-green reduz o tempo de exposição ao erro, porque o rollback é quase instantâneo. O risco total depende da qualidade dos testes e da observabilidade. --- Fonte (canonical): https://blogsemjuizo.com.br/especiais/canary-vs-blue-green-deployment-qual-estrategia/