Rollout Progressivo e Canary Release, Explicado

Rollout progressivo é liberar uma mudança para uma fatia crescente do público (por exemplo 1%, 5%, 25%, 100%), monitorando métricas de guarda a cada etapa antes de avançar. Canary release é um caso mais específico desse mesmo princípio, aplicado à infraestrutura de deploy: uma versão nova roda em paralelo com a antiga para um subconjunto pequeno de servidores, e a decisão de expandir costuma ser automatizada por métricas de erro e latência, não por uma pessoa decidindo na régua. Os dois conceitos aparecem juntos com frequência porque resolvem o mesmo problema (reduzir o risco de uma mudança em produção) em duas camadas diferentes da stack, e ambos se apoiam na mesma infraestrutura de feature flags que já cobrimos no guia completo do cluster.

O que é rollout progressivo

Rollout progressivo (também chamado de gradual rollout ou phased rollout) é a prática de expor uma funcionalidade nova, ou uma versão nova de uma funcionalidade, a uma fração pequena do público primeiro, e ir aumentando essa fração em etapas discretas até chegar a 100%. A alternativa óbvia, virar a chave para todo mundo de uma vez, transforma qualquer problema despercebido em um incidente de escala total; o rollout progressivo transforma o mesmo problema em algo que afeta uma fatia pequena e controlada, com tempo de sobra para reagir antes que vire notícia.

A documentação da LaunchDarkly descreve dois mecanismos distintos para isso: o rollout por porcentagem, em que você define manualmente a fatia (por exemplo 5%) e aumenta essa fatia à mão conforme ganha confiança, mantendo o mesmo conjunto de usuários alocado enquanto o valor não muda; e o rollout progressivo propriamente dito, em que a plataforma aumenta a porcentagem automaticamente ao longo de um período definido (por exemplo, de 5% a 100% ao longo de 24 horas, em etapas programadas). A diferença prática mais citada pela própria LaunchDarkly é sutil, mas importa: um rollout progressivo reiniciado pode alocar um conjunto diferente de usuários à variação nova, porque a escolha de quem entra é re-sorteada a cada execução, enquanto um rollout por porcentagem simples mantém o mesmo grupo enquanto a configuração não mudar.

Na prática, a maioria dos rollouts progressivos documentados segue uma sequência parecida com esta, ajustada ao volume de tráfego e ao apetite de risco de cada time: uma etapa interna (equipe e QA, sem usuário real exposto), depois 1% de produção, depois 5 a 10%, depois 25 a 50%, e só então 100%. O guia da Flagsmith sobre estratégias de deploy descreve exatamente esse padrão com um exemplo concreto: uma flag new-payment-processor habilitada para 1% dos usuários e, se as métricas estiverem boas, aumentada para 5%, depois 20%, e assim por diante até chegar a 100%.

O que é canary release, e de onde vem o nome

Canary release é uma técnica específica para reduzir o risco de colocar uma versão nova de software em produção, liberando a mudança lentamente para um subconjunto pequeno de infraestrutura antes de expandir para o resto, segundo a definição de Martin Fowler no bliki que carrega o nome da técnica. O termo vem de uma prática histórica de mineração: canários eram levados para dentro das minas de carvão como um sistema de alerta precoce, porque o pássaro morria antes dos mineiros ao respirar gases tóxicos, dando tempo de evacuar antes que o perigo afetasse pessoas. Um canary release cumpre o mesmo papel: expõe o problema num subconjunto pequeno e controlado antes que ele afete todo o público.

Fowler descreve o canary release como parente próximo do blue-green deployment: os dois começam implantando a versão nova em infraestrutura separada, sem tráfego de usuário real ainda apontando para ela. A diferença aparece depois disso. No blue-green, a virada é completa e de uma vez só, todo o tráfego muda de uma infraestrutura para a outra no mesmo instante, depois que a validação terminou. No canary release, o tráfego de usuários reais é direcionado de forma crescente e gradual para a versão nova, começando por amostras pequenas e aleatórias, passando por funcionários internos, e só então se expandindo por critério demográfico, geográfico ou por unidade de negócio, sempre com a opção de reverter rapidamente se algo sair errado.

Documentação de provedores de nuvem reforça o mesmo desenho na prática: a AWS documenta canary deployment para funções Lambda usando um alias com duas versões e um peso de tráfego configurável, por exemplo direcionar 10% do tráfego para a versão nova, manter esse peso por uma janela de validação (minutos a poucas horas) e, se um alarme configurado disparar nesse intervalo, reverter automaticamente 100% do tráfego de volta para a versão antiga. É a mesma lógica do canário na mina: um sinal de alerta pequeno e controlado, antes do risco se espalhar.

A diferença entre os dois conceitos

Rollout progressivo e canary release compartilham o princípio (expor aos poucos, monitorar, decidir), mas focam em camadas diferentes do sistema e costumam ser operados por times diferentes.

Critério	Rollout progressivo (feature flag)	Canary release
Foco principal	Usuário e funcionalidade: quem vê o quê	Infraestrutura e deploy: qual versão do código está no ar
Quem decide o avanço	Geralmente uma pessoa (produto, engenharia), manual ou por regra de segmentação	Geralmente automatizado por métricas de erro/latência do pipeline de deploy
Unidade de segmentação	Usuário, conta, sessão (atribuição estável por ID)	Servidor, instância, pod ou fatia de infraestrutura
O que está sendo testado	Se a funcionalidade se comporta bem para o negócio e para o usuário	Se a versão nova do código é estável em produção (erro, latência, saúde do serviço)
Ferramenta típica	LaunchDarkly, Unleash, Flagsmith, PostHog, Statsig	Pipeline de deploy (AWS CodeDeploy/ECS, Kubernetes, Google Cloud Deploy)
Rollback	Desligar a flag, geralmente em segundos	Redirecionar o tráfego de volta para a versão estável

Uma forma simples de lembrar a diferença: o canary release resolve se aquela versão de código é segura para rodar em produção, enquanto o rollout progressivo por feature flag resolve se aquela funcionalidade é segura para as pessoas usarem. Na prática, as duas técnicas se combinam com frequência: você faz o deploy da versão nova via canary release (o código já está rodando, testado num subconjunto de infraestrutura), e usa uma feature flag por cima para controlar quem, dentro daquele código já implantado, de fato vê a funcionalidade nova. Canary controla onde o código roda; a feature flag controla o que aparece para quem.

Métricas de guarda e rollback automático

O elemento que transforma um rollout progressivo de “aumentar a porcentagem e torcer” em uma prática de engenharia responsável são as métricas de guarda (guardrail metrics): os indicadores que não podem piorar enquanto a exposição aumenta. As mais citadas na documentação de deploy e de feature management são a taxa de erro, a latência (em particular os percentis altos, p95 e p99, porque a média esconde os piores casos), a taxa de crash em aplicativos móveis, e indicadores de negócio como conversão ou taxa de falha de pagamento quando a mudança tem potencial de afetar receita diretamente.

A LaunchDarkly formaliza essa ideia no que chama de guarded rollout: a plataforma aumenta a exposição de uma variação progressivamente enquanto monitora métricas conectadas (por integração, API, evento de SDK ou OpenTelemetry), comparando estatisticamente o desempenho da variação nova contra a original a cada etapa. Se a comparação aponta uma regressão estatisticamente significativa, o rollout pausa e notifica o time responsável; com rollback automático habilitado, a própria plataforma reverte a mudança sem esperar uma pessoa agir.

O padrão de mercado, ilustrado por implementações como a da AWS para funções Lambda, define o limite de forma explícita antes do rollout começar (por exemplo, um alarme de taxa de erro acima de um limiar sustentado por alguns minutos) e usa uma janela de tempo curta para não confundir um pico transitório e passageiro com uma regressão real. A lição comum a toda essa documentação, da LaunchDarkly à AWS: quando uma métrica de guarda piora, a resposta certa é reduzir a exposição de volta, nunca seguir em frente na esperança de que “estabiliza sozinho”.

Como isso se conecta a feature flags, e por que não é teste A/B

Rollout progressivo depende, quase sempre, da mesma peça de infraestrutura que sustenta feature flags: uma regra que decide, por usuário ou por sessão, se aquela pessoa recebe a versão nova. É por isso que este tema aparece como uma extensão natural do que já cobrimos no guia completo de feature flags: a release flag, o tipo de flag mais comum, existe justamente para permitir esse tipo de liberação gradual e reversível.

Vale reforçar uma confusão comum: rollout progressivo não é um teste A/B, mesmo usando um mecanismo parecido por baixo. Um teste A/B aloca tráfego de forma fixa entre variações (a mesma fatia em cada braço, do início ao fim do teste) e termina com uma decisão estatística sobre qual versão converte mais, com amostra e significância calculadas antes de começar. Um rollout progressivo aumenta a fatia exposta com o tempo até chegar a 100%, e termina quando a mudança está liberada para todo mundo, sem que exista necessariamente uma pergunta de “qual variação é melhor” por trás. O objetivo de um é mitigar risco de deploy; o objetivo do outro é medir efeito. Quem quiser entender exatamente onde essa linha se cruza, e quando um rollout simples deveria virar um experimento de verdade, encontra o comparativo aprofundado em feature flags x teste A/B.

A mesma distinção vale para a camada de execução: assim como cobrimos no comparativo entre teste A/B client-side e server-side, um rollout progressivo de produto normalmente é decidido no servidor (a mesma infraestrutura de feature flag server-side), porque envolve lógica de negócio, permissão ou dado sensível que não deveria ser avaliado no navegador do usuário. Um canary release, por sua vez, é sempre uma decisão de infraestrutura: acontece na camada de deploy, antes mesmo de qualquer flag decidir o que aparece para quem.

Boas práticas: como planejar um rollout progressivo

Não existe um número mágico universal para tamanho de incremento ou tempo de observação, porque isso depende do volume de tráfego, da criticidade da mudança e de quão rápido as métricas de guarda geram sinal confiável. Mas alguns princípios aparecem de forma consistente na documentação de LaunchDarkly, AWS e Flagsmith:

Decisão	Prática recomendada	Por quê
Tamanho do primeiro incremento	Pequeno o bastante para limitar o dano (1% é o valor mais citado), nunca 10%+ na primeira etapa de uma mudança de risco desconhecido	Limita o “raio de explosão” caso algo dê errado logo na primeira etapa
Tempo de observação por etapa	Minutos a poucas horas nas etapas pequenas; um dia ou mais nas etapas grandes (25%, 50%)	Etapas pequenas têm menos tráfego, então levam mais tempo para gerar sinal estatístico confiável em métricas de negócio
Quem decide o avanço	Automatizado por métrica de guarda sempre que possível; decisão manual como plano B, nunca por “já faz um tempo que está no ar”	Decisão automatizada reage mais rápido que uma pessoa olhando um painel de vez em quando
O que monitorar	Taxa de erro, latência (p95/p99), crash rate, e pelo menos uma métrica de negócio quando a mudança afeta o funil	Métricas técnicas pegam quebra de sistema; métricas de negócio pegam problema que “funciona” mas prejudica o usuário
Quando reverter	No primeiro sinal sustentado de degradação, não na primeira flutuação isolada	Reduz falso alarme por pico transitório sem atrasar a reação a um problema real

Um erro comum de quem está começando é tratar “aumentar a porcentagem” como um evento de calendário (avançar toda sexta-feira, por exemplo), em vez de condicioná-lo à saúde da etapa atual. O rollout progressivo só entrega o valor que promete quando o avanço depende do que as métricas de guarda mostram, não de quanto tempo já passou.

Faça isso automático na Donnu

Lançar uma mudança com segurança é, no fundo, o mesmo problema que resolvemos para experimentos: decidir com dado, não no escuro, e nunca expor 100% do tráfego a um risco desconhecido de uma vez. A Donnu A/B já resolve a parte de alocação estável e sem flicker para quem quer testar variações; se o seu próximo passo é rollout de funcionalidade (não experimentação), o princípio é o mesmo que este guia descreveu: comece pequeno, meça, e só expanda quando a etapa anterior provar que está segura.

Se o que você precisa hoje é medir qual variação converte mais, com amostra calculada e leitura honesta, comece um teste grátis de 14 dias. Se o que você precisa é entender a base de feature flags antes de decidir sua stack de rollout, comece pelo guia completo de feature flags.

Referências

• Fowler, M. CanaryRelease. martinfowler.com/bliki, 2014. martinfowler.com/bliki/CanaryRelease.html.
• LaunchDarkly. Progressive rollouts e Guarded rollouts. launchdarkly.com/docs/home/releases/progressive-rollouts e launchdarkly.com/docs/home/releases/guarded-rollouts.
• AWS. Implement Lambda canary deployments using a weighted alias. docs.aws.amazon.com/lambda.
• Unleash. Canary release vs rolling deployment: Rollback speed, risk, and resources. getunleash.io/blog.
• Flagsmith. 8 Types of Deployment Strategies (And How Feature Flags Help). flagsmith.com/blog.