Blog/Artigos · Cloud e Plataforma
Canary, blue-green e rolling, feature flags que separam deploy de release, e o rollback automático guiado por métrica, com Argo Rollouts e Harness.
Ao prometer a terra, o texto diz que a conquista virá pouco a pouco, não de uma vez, para que a mudança não deixe a terra deserta e ingovernável antes que haja quem a ocupe. A sabedoria é a mesma da entrega de software: mudança grande demais, rápido demais, é ingovernável. O deploy que troca tudo para todos ao mesmo tempo é o big-bang, e quando ele falha, falha para todo mundo de uma vez, no escuro, sem tempo de reagir. Progressive delivery aplica o pouco a pouco: a mudança chega primeiro a uns poucos, é observada, e só avança se os números aguentam. A falha, quando vem, chega pequena e cedo, quando ainda dá para recuar sem estrago.
O deploy tradicional troca a versão para todos os usuários de uma vez. Enquanto tudo dá certo, parece eficiente; no dia em que a versão nova tem um defeito, cem por cento dos usuários o sentem ao mesmo tempo, e o time descobre o problema pelo volume de reclamação, não por um sinal controlado. É o pior momento para descobrir: tarde, no escuro e em escala máxima. O big-bang concentra todo o risco num instante, e a única defesa é o rollback correndo atrás do prejuízo já causado.
Progressive delivery parte de uma premissa humilde: toda mudança pode estar errada, então exponha-a a poucos antes de expô-la a todos. A versão nova recebe uma fatia pequena do tráfego, os números dela são comparados com os da versão estável, e o avanço só continua se ela se prova. Se falha, a fatia afetada é mínima e o recuo é imediato. O nome disso, no jargão, é reduzir o blast radius, o raio de explosão: a falha continua possível, mas o dano que ela causa fica contido, pequeno e reversível. É o pouco a pouco transformado em disciplina de engenharia.
| Aspecto | Big-bang | Progressive delivery |
|---|---|---|
| Quem sente a falha | todos, de uma vez | uma fatia pequena, primeiro |
| Quando se descobre | tarde, pelo volume de reclamação | cedo, por sinal controlado |
| Blast radius | máximo, o serviço inteiro | contido, só a fatia exposta |
| Rollback | corre atrás do estrago já feito | imediato, com dano mínimo |
| Confiança para lançar | baixa, cada deploy é aposta | alta, o número decide o avanço |
Há três estratégias clássicas, e cada uma resolve um cenário. O canary manda uma fatia pequena do tráfego para a versão nova, um por cento, depois dez, depois cinquenta, medindo a cada passo, como o canário na mina que avisa do perigo antes de ele atingir todos. O blue-green mantém duas versões inteiras no ar, azul e verde, e vira o tráfego de uma para a outra de um golpe, com rollback instantâneo por virar de volta, ao custo de rodar duas versões completas ao mesmo tempo. O rolling substitui as instâncias aos poucos, uma leva de cada vez, sem duplicar o ambiente inteiro.
A escolha depende do que se pode pagar e do que se precisa. Canary é o mais fino no controle de risco, mas exige tráfego suficiente para os números da fatia significarem algo, e uma boa camada de observabilidade para julgar. Blue-green dá o rollback mais rápido que existe, virar a chave de volta, mas dobra o custo de infraestrutura no momento da troca e complica quando há estado ou banco compartilhado. Rolling é o mais econômico e o padrão do Kubernetes, mas mistura versões durante a transição, o que exige que as duas convivam. Não há vencedor absoluto; há a estratégia certa para a carga, o tráfego e o orçamento de cada caso.
| Estratégia | Como funciona | Força | Custo ou limite |
|---|---|---|---|
| Canary | fatia crescente do tráfego para a versão nova | controle fino de risco, medido a cada passo | exige tráfego e observabilidade para julgar |
| Blue-green | duas versões inteiras, vira o tráfego de golpe | rollback instantâneo: vira a chave de volta | dobra a infra na troca, complica com estado |
| Rolling | substitui instâncias aos poucos, em levas | econômico, padrão do Kubernetes | mistura versões durante a transição |
A ideia mais libertadora de progressive delivery é separar deploy de release. Deploy é subir o código para produção; release é ligar o recurso para o usuário. Feature flags, as chaves de recurso, permitem que o código já esteja em produção, subido com calma, mas desligado, e seja ativado depois, para quem você quiser, quando você quiser. Isso é o dark launch: o recurso viaja no deploy inerte e é aceso por configuração, sem novo deploy. Ferramentas como o LaunchDarkly fizeram disso um mercado próprio.
A consequência é enorme para o risco e para o negócio. O deploy deixa de ser o evento tenso, porque não liga nada; o release vira uma decisão de produto, reversível por uma chave, sem pipeline. Dá para ligar um recurso só para a equipe interna, depois para um por cento dos clientes, depois para uma região, e desligar em segundos se algo der errado, sem redeploy nem rollback de código. A chave também sustenta teste A/B e lançamento por segmento. O preço é a dívida de flag: chave que fica ligada e esquecida vira código morto e caminho de teste que ninguém cobre, então flag tem que ter dono e data de remoção, ou o benefício de hoje vira o emaranhado de amanhã.
Recuar é apagar a chave, sem redeploy nem rollback de código. O release vira decisão de produto, reversível, e o deploy deixa de ser o evento tenso.
O canary só cumpre a promessa se o avanço for guiado por métrica, não por torcida. O padrão maduro é a análise automática: a cada passo do canary, um sistema compara as métricas da versão nova com as da estável, taxa de erro, latência, e outros sinais de saúde, e decide sozinho se promove para o próximo passo ou se reverte. Ferramentas como o Argo Rollouts, o Flagger e o Harness fazem exatamente isso, e a decisão amarra ao SLO: se o canary começa a queimar o orçamento de erro, ele volta antes de o usuário sofrer.
Isso tira do lançamento a pior parte, o julgamento humano sob pressão de madrugada. Ninguém precisa ficar olhando o gráfico decidindo se está bom o bastante para avançar; o critério foi definido antes, com calma, em número, e o sistema o aplica sem hesitar e sem viés de quem quer que o deploy dê certo. O rollback automático é o irmão do error budget do SLO: o número decide, não a opinião. E quando o número decide reverter, ele reverte em segundos, com a fatia afetada mínima. A promessa do pouco a pouco se completa aqui: falha pequena, detecção automática e recuo imediato, sem herói de plantão.
| Passo do canary (% do tráfego) | Canário saudável | Canário que degrada |
|---|---|---|
| 1 | 0,3 | 0,4 |
| 10 | 0,4 | 0,9 |
| 20 | 0,4 | 1,8 |
| 30 | 0,5 | 3,2 |
| 40 | 0,4 | 4,6 |
| 50 | 0,5 | 5 |
Progressive delivery amadurece do big-bang ao lançamento que o número governa. No começo é o deploy de tudo para todos, torcendo. No meio é o rolling ou o canary manual, com alguém olhando o gráfico. No topo é a entrega com feature flags separando deploy de release, análise automática de canary amarrada ao SLO e rollback que dispara sozinho quando o orçamento de erro começa a queimar. Cada degrau tira mais um pedaço do risco do instante do lançamento e o dilui no tempo, sob medição.
Nada disso vive isolado: progressive delivery se apoia no GitOps, que dá o mecanismo de deploy; no SLO, que dá o critério de promover ou reverter; e na observabilidade, que dá os números para julgar. É a ponta visível de uma cadeia inteira de plataforma, e é onde o usuário final colhe o benefício, porque o defeito que escaparia para ele é barrado numa fatia pequena, cedo. O pouco a pouco não é lentidão; é o que permite lançar com frequência e com calma ao mesmo tempo, porque cada lançamento carrega, por construção, o próprio limite de dano.
Progressive delivery aplica o pouco a pouco à entrega: a mudança chega a poucos antes de chegar a todos, é medida, e só avança se os números aguentam. Canary, blue-green e rolling servem a cenários diferentes; feature flags separam deploy de release e tornam o recuo uma chave; e o rollback automático amarrado ao SLO deixa o número decidir, não a torcida. A IA pega a degradação sutil e rastreia a dívida de flag. Mas definir o critério de promover ou reverter, e o apetite de risco que ele traduz, continua sendo decisão de quem responde pela confiabilidade, tomada com calma antes do lançamento.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaשׁוּב
GitOps faz do Git a única fonte de verdade do que roda, e um controlador puxa a realidade de volta ao que está escrito, sem parar. Deploy vira commit, rollback vira reverter, e o drift se corrige sozinho. O repositório declara, o laço reconcilia.
Operaçõesקָו
Buscar 100% de disponibilidade é caro e inútil. O SLO define quanto de confiabilidade basta, e o error budget transforma isso em decisão: quando inovar e quando frear.
