Esses dois conceitos se confundem porque ambos limitam o raio de explosão e ambos podem ser feitos em estágios, monitorados e revertidos automaticamente. A diferença está no que de fato varia por trás: um canary deployment roteia uma porcentagem do tráfego pra um build diferente do seu serviço; uma feature flag roteia uma porcentagem do tráfego pra um caminho de código diferente dentro de um único build que já está rodando em todo lugar.
O que um canary deployment controla
Um canary é uma decisão de camada de infraestrutura: duas versões de um serviço rodam lado a lado, e um load balancer ou service mesh desloca o peso do tráfego da versão antiga pra nova ao longo do tempo. Reverter significa deslocar o peso de volta e, eventualmente, desligar as instâncias da versão nova. A unidade de controle é "qual binário atende essa requisição", o que é uma questão de orquestração de deploy. Veja nosso texto sobre Rollout Progressivo no Kubernetes pra ver como isso fica quando a camada de orquestração é o próprio Kubernetes.
O que uma feature flag controla
Uma flag é uma decisão de camada de aplicação: um único build é implantado em todo lugar, e um if dentro dele, avaliado localmente, no processo, contra uma Configuration em cache, decide qual caminho uma dada requisição segue. Reverter significa mudar o que a flag avalia, o que é uma mudança de Configuration, não um redeploy. A unidade de controle é "qual caminho de código atende essa requisição dentro do build que já está rodando".
Onde a diferença realmente aparece na prática
- Velocidade de reversão. Reverter uma flag é uma mudança de Configuration propagada pra processos já rodando no próximo refresh de cache, tipicamente segundos. Reverter um canary envolve deslocar o peso do tráfego e, se instâncias foram escaladas pra versão nova, desligá-las, geralmente mais lento, e é uma operação de infraestrutura, não de aplicação.
- Granularidade. O raio de explosão de um canary é uma porcentagem de requisições, não importa quem as enviou. O raio de explosão de uma flag pode ser uma porcentagem de requisições, de um segmento específico (um tier de plano, uma região, um time interno), ou uma lista escolhida a dedo de subject keys, algo que um canary não consegue expressar sem dividir o tráfego na camada de infraestrutura por segmento, o que a maioria das configurações não faz.
- O que precisa ser reimplantado pra testar algo novo. Um canary exige um build novo pra testar qualquer coisa, não existe "virar uma chave pra ver o comportamento novo" sem implantar código diferente. Uma flag pode proteger código que já está implantado mas adormecido, então testar uma variante não exige deploy nenhum.
- Modo de falha sob uma mudança ruim. Uma regressão de canary fica contida a um build; reverter remove esse código do build inteiro. Uma regressão de flag fica contida a qualquer requisição que avaliou
true; reverter remove o comportamento enquanto o código continua implantado, adormecido, pronto pra tentar de novo depois de corrigido.
Eles não competem
A maioria dos times que usa os dois usa canary pra validar que um build novo é estável (sem crash loop, sem taxa de erro elevada por causa do próprio deploy) e flag pra validar que uma feature nova é segura (comportamento correto, métricas de negócio aceitáveis), muitas vezes pra a mesma mudança, em sequência: canary no build primeiro, depois flag na feature que ele contém. Veja Feature Flags vs. Guarded Rollouts pra ver como os rollouts em estágios do próprio rollfuse ficam do lado da flag nessa linha, com a mesma mecânica de guardrail automático que uma configuração de canary teria que replicar com sua própria camada de infraestrutura.