O que é progressive delivery: canary, blue-green e flags

O que é progressive delivery? É uma forma de liberar software em que a mudança chega à produção em pequenas etapas controladas, e cada etapa é verificada com métricas reais antes de a próxima começar. Se os números piorarem, a liberação para ou volta atrás sozinha. Você deixa de apostar a base inteira de usuários em um único deploy.

Esta é a situação que você provavelmente conhece. Um pull request é aprovado, o CI fica verde, o deploy sai numa terça à tarde e, vinte minutos depois, alguém pergunta no Slack por que a latência do checkout dobrou. O progressive delivery existe para encurtar essa conversa e para fazer com que ela aconteça com 5% do tráfego, e não com 100%.

O que o progressive delivery muda de fato?

O continuous delivery responde a uma pergunta: dá para mandar esta mudança para produção com segurança? O progressive delivery acrescenta uma segunda: quem vê primeiro, e o que nos manda parar?

O movimento central é separar deploy de release. Deploy é o código novo rodando nos servidores. Release é o momento em que os usuários são expostos a ele. Quando essas duas coisas são desacopladas, você pode fazer o deploy numa quarta à tarde e liberar no seu ritmo, para um público escolhido, com um caminho de volta.

A maioria das fontes que você vai ler concorda com três blocos: a troca gradual de tráfego (canary), ambientes paralelos (blue-green) e feature flags. Eles não são rivais. Equipes maduras usam os três em camadas diferentes.

Canary releases: quanto tráfego, e quem decide?

Um canary release envia uma pequena fatia do tráfego para a versão nova, digamos 5%, enquanto o resto continua na versão antiga. Se a taxa de erro, a latência e a saturação ficarem dentro dos seus limites, a fatia cresce: 5%, 25%, 50%, 100%. Se não ficarem, o tráfego volta.

O porém é que divisões finas exigem algo capaz de dividir o tráfego. A documentação do Argo Rollouts explica que percentuais precisos de canary dependem de um gerenciador de tráfego, como um service mesh ou um ingress controller. Sem isso, você só tem um controle grosseiro, baseado em número de réplicas, e então "5%" pode significar, na prática, "um pod em vinte".

Veja como fica um canary em etapas num manifesto do Argo Rollouts. Ele é curto de propósito.

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 10m }   # acompanhe os dashboards ou rode a análise
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 100

Pule o canary se o seu serviço recebe tão pouco tráfego que 5% sejam poucas requisições por hora. Você vai esperar um sinal para sempre ou, pior, vai tomar ruído por segurança. Para serviços de baixo tráfego, feature flags direcionadas a usuários internos são uma porta de entrada melhor.

Blue-green deployments: quando vale ter um segundo ambiente completo?

Blue-green mantém dois ambientes completos de produção. O azul atende os usuários. O verde recebe a versão nova e é testado enquanto está ocioso. Quando você está satisfeito, o tráfego passa de um para o outro.

Segundo a documentação do Argo Rollouts, a troca é total: a versão antiga continua com todo o tráfego de produção até a nova ser verificada, e só então a divisão passa de 0% para 100%. Essa é a força e a fraqueza do método. O rollback é um único movimento de volta, o que é rápido. Mas o teste acontece antes de os usuários reais chegarem, e o custo é o dobro de infraestrutura enquanto os dois lados estão no ar.

Vale a pena se você opera um serviço com estado ou de alto risco, em que uma liberação parcial seria confusa. Por exemplo, um fluxo de pagamento em que duas versões nunca podem atender uma requisição ao mesmo tempo. Evite se a sua migração de banco não puder rodar nas duas versões ao mesmo tempo, porque aí o "rollback instantâneo" é uma ficção.

Onde entram as feature flags?

Canary e blue-green funcionam na camada de infraestrutura. Feature flags funcionam dentro da aplicação. Uma flag envolve um caminho de código em uma condicional que pode ser alterada em tempo de execução, sem novo deploy.

Isso torna as flags a ferramenta de controle mais fina da caixa. Você pode expor uma funcionalidade a funcionários, depois a 1% das contas, depois a um segmento de clientes, e desligá-la em segundos se ela se comportar mal. Algumas equipes tratam as flags como apenas uma técnica entre outras, outras as chamam de habilitador de toda a abordagem. Na prática, a segunda visão se sustenta: no momento em que você quer liberar por público e não por servidor, precisa de uma flag.

As flags têm custo próprio, porém. Cada flag é um desvio que os testes precisam cobrir e um ticket de limpeza que alguém precisa fechar. Se quiser a versão mais longa, explicamos a mecânica e a dívida em o que é uma feature flag. Trate cada flag como de vida curta por padrão, com um dono e uma data de remoção.

Ferramentas como LaunchDarkly e Statsig vendem a camada de gestão: regras de segmentação, logs de auditoria, liberações percentuais graduais e experimentos.

O que torna uma liberação progressiva e não apenas lenta?

A automação. Uma liberação que pausa dez minutos enquanto uma pessoa olha para um dashboard é um deploy lento. Ela se torna progressive delivery quando uma máquina verifica as métricas e toma a decisão.

O padrão é o mesmo em qualquer lugar:

1. Defina os sinais antes da liberação: taxa de erro, latência p95 e uma métrica de negócio, como a conclusão do checkout.

2. Defina os limites que significam "pare", escritos na configuração, e não na cabeça de alguém.

3. Deixe o controlador promover, segurar ou reverter com base nesses sinais.

O Argo Rollouts se integra a provedores de métricas para que uma liberação seja promovida ou abortada automaticamente, conforme as verificações passem ou falhem. Uma das fontes que revisamos resume o ponto sem rodeios: progressive delivery sem rollback automático é só um deploy lento. Concordamos.

Quais métricas devem controlar uma liberação?

Mantenha o conjunto pequeno. Três ou quatro sinais em que você já confia valem mais do que vinte que você nunca usou em alerta.

Um ponto de partida viável: taxa de respostas HTTP 5xx do canary comparada à da baseline, latência p95 do canary comparada à da baseline, saturação (CPU, memória, profundidade de fila) e uma métrica de produto. Compare o canary com a baseline no mesmo momento, e não com a "semana passada", porque os padrões de tráfego mudam.

É aqui que a sua stack de observabilidade deixa de ser algo desejável e vira requisito. Se você não consegue segmentar as métricas por versão ou por variante de flag, não consegue distinguir o canary da baseline, e a abordagem inteira desmorona. Nosso texto sobre o que é observabilidade mostra como chegar lá.

Como o progressive delivery se relaciona com o trunk-based development?

Os dois se encaixam bem. O trunk-based development mantém branches curtas e integra mudanças pequenas com frequência. O risco é que trabalho inacabado ou não testado chegue à main com mais frequência. O progressive delivery é o que torna isso seguro: o código entra no trunk, é enviado escondido atrás de uma flag e é liberado gradualmente.

Lotes pequenos somados à exposição gradual também tornam a depuração mais barata. Quando um canary falha, a lista de suspeitos é uma mudança, e não quarenta. Quem já fez bisect em uma semana de commits integrados às 23h sabe quanto isso vale.

Qual é um primeiro passo realista para uma equipe de 10 a 30 engenheiros?

Não comece instalando um service mesh. Comece com a menor coisa que lhe dê um botão de parada.

• Semana 1: coloque uma funcionalidade arriscada atrás de uma flag e libere primeiro para a sua própria equipe.

• Semana 2: adicione dashboards por versão para taxa de erro e latência. Se a sua ferramenta não consegue separar por versão, conserte isso primeiro.

• Semana 3 em diante: mova um serviço stateless para um controlador de canary, com duas ou três etapas e um aborto automático em caso de erro.

Meça em horas, e não em uma "sensação de segurança". Conte quantos incidentes ficaram restritos a uma fatia pequena de usuários e quanto tempo o rollback levou. Esses dois números vão dizer se a abordagem funciona para a sua equipe.

Onde as liberações progressivas costumam quebrar?

Em três lugares, e nenhum deles é o controlador.

Migrações de banco. Um canary significa que duas versões do seu código acessam o mesmo banco ao mesmo tempo. Se a versão N+1 remover ou renomear uma coluna que a versão N ainda lê, o canary derruba a baseline. A correção clássica é o expand and contract: adicione primeiro a coluna nova, publique um código que grave nas duas, faça o backfill, troque as leituras e só depois remova a coluna antiga.

Sessões fixas e caches. Se um usuário alterna entre a versão antiga e a nova a cada requisição, surgem bugs que ninguém consegue reproduzir. Fixe os usuários em uma variante durante a liberação, por cookie, por ID de conta ou pela avaliação da flag.

Métricas que atrasam. Uma métrica de conversão que atualiza de hora em hora não pode controlar uma etapa de canary de dez minutos. Controle com sinais rápidos (erros, latência) durante a liberação, e revise a métrica de negócio lenta antes de passar de 50% para 100%.

Como saber o que está no ar, dentro do repositório?

O progressive delivery espalha uma liberação por arquivos de configuração, definições de flags, manifestos de rollout e dashboards. Depois de alguns meses, a pergunta "qual flag protege o novo fluxo de cobrança, e quem é o dono?" vira a rotina de sempre: grep, blame e, por fim, perguntar a alguém.

Isso é um problema de leitura de código, não de ferramenta. Pesquisar o repositório pela chave da flag e seguir cada referência até o ponto de chamada é o jeito mais rápido de achar flags mortas e rollouts inacabados. Uma ferramenta que responde "onde esta flag é avaliada e o que acontece quando ela está desligada?" a partir do seu código real economiza mais tempo aqui do que mais um dashboard.

O que deixaríamos de lado

Evite blue-green para tudo se a conta de infraestrutura já é motivo de conversa. Evite canaries em serviços com quase nenhum tráfego. Evite qualquer ferramenta de rollout que ninguém da equipe consiga depurar às 3 da manhã.

O problema real não é a estratégia que você escolhe. É a distância entre enviar código e saber o que ele faz em produção. O progressive delivery reduz essa distância uma fatia de tráfego por vez, e a primeira fatia é a que importa: mantenha-a pequena, mantenha-a observável e dê a ela um botão de desligar.