Liberar software costumava significar uma janela de manutenção e dedos cruzados. As equipes modernas usam estratégias que tornam os lançamentos rotineiros, e a escolha implantação azul-verde versus implantação canário é uma das primeiras que você enfrentará. Ambos reduzem o risco, mas o fazem de maneiras opostas: um prepara uma substituição completa, enquanto o outro testa com usuários reais, um pouco de cada vez.

Este guia explica como cada um funciona e quanto custa na prática. Executamos pequenos exemplos de roteamento de usuário e reversão no Python 3.13, e a saída vem dessa execução. Os exemplos do Kubernetes são ilustrativos e não os executamos. Trate as porcentagens e os limites como exemplos iniciais de adaptação.

A resposta curta

Com a implantação azul-verde, você executa dois ambientes de produção idênticos. Um atende os usuários enquanto você implanta e testa a nova versão no outro, e então você alterna todo o tráfego de uma só vez.

Com a implantação canary, a nova versão é executada ao lado da antiga. Você envia uma pequena porcentagem do tráfego real, compara os resultados e aumenta a participação passo a passo até atender a todos. O nome vem dos canários que os mineiros costumavam usar como alerta precoce de perigo.

Azul esverdeado vs canário lado a lado

Como funciona a implantação azul-verde

1. Blue está ativo e atende todo o tráfego.
2. Implante a nova versão em verde, que não recebe tráfego de usuários.
3. Teste o verde exaustivamente, no ambiente de produção real, utilizando testes de fumaça e usuários internos.
4. Mude o roteador, balanceador de carga ou DNS para enviar o tráfego para verde.
5. Observe atentamente, com o azul ainda funcionando e pronto.
6. Se algo estiver errado, volte. Se tudo estiver bem, o azul se tornará o próximo ambiente ocioso.

No Kubernetes, você pode fazer a troca alterando o seletor de um serviço, para que o tráfego seja movido para pods rotulados de forma diferente:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Pontos fortes: É conceitualmente simples, você pode testar a configuração exata de produção antes que os usuários a vejam e a reversão é quase instantânea. Fraquezas: Infraestrutura duplicada pode ser cara, um bug que passa despercebido nos testes atinge todos ao mesmo tempo, e sessões abertas e trabalho em andamento precisam de cuidados durante a mudança. Se você usar DNS para o switch, os registros em cache poderão atrasá-lo. Novo nos conceitos? Veja nosso tutorial do Kubernetes para iniciantes.

Como funciona a implantação canário

1. Implante a nova versão junto com a estável.
2. Direcione uma pequena parcela do tráfego, por exemplo 5%, para o canário.
3. Compare taxas de erro, latência e métricas de negócios com a versão estável.
4. Se estiver saudável, aumente para 25%, depois 50% e depois 100%.
5. Se alguma coisa degradar, envie todo o tráfego de volta para a versão estável.

Muitas equipes iniciam um canário com funcionários internos, depois com uma região de baixo risco e só então com o público em geral.

Pontos fortes: Um lançamento incorreto afeta apenas um pequeno grupo, e você aprende com o tráfego real que nenhum ambiente de teste pode ser totalmente reproduzido. Pontos fracos: você precisa de roteamento baseado em porcentagem e métricas por versão, as implementações demoram mais e duas versões são executadas juntas por um tempo. Um canário pequeno também pode ser silencioso demais para emitir um sinal significativo, principalmente em horários de baixo tráfego.

Roteamento de usuário estável

Escolher uma versão aleatoriamente em cada solicitação proporciona aos usuários uma experiência confusa, pois eles podem alternar entre o antigo e o novo. Uma solução comum é fazer o hash de um ID de usuário estável em um bucket, para que cada usuário sempre obtenha a mesma resposta:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

A participação real seguiu de perto a meta. Este método tem mais duas propriedades úteis e nossa execução confirmou ambas. O mesmo usuário sempre recebeu a mesma versão. E todos no grupo de 5% ainda estavam incluídos em 25%, então ninguém que já tinha a nova versão retrocedeu à medida que o lançamento crescia.

Em sistemas reais, uma malha de serviço, balanceador de carga ou uma ferramenta como Argo Rollouts ou Flagger geralmente cuida desse roteamento, portanto você não precisa escrevê-lo sozinho. Ainda é útil entender o que eles estão fazendo.

Automatizando a decisão

Um canário só funciona se alguém estiver realmente comparando as versões. As verificações automatizadas são mais confiáveis ​​do que uma pessoa observando os gráficos. Aqui está a ideia central, comparando a taxa de erro do canário com a da versão estável:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Observe o primeiro caso. Sua taxa de erro parece alta, mas com apenas 100 solicitações, ainda não há evidências suficientes. Ferramentas reais aplicam estatísticas mais cuidadosas e analisam vários sinais em conjunto:

O problema do banco de dados

O código do aplicativo pode ser trocado em segundos, mas os dados não. Ambas as estratégias geralmente compartilham um banco de dados, portanto, durante uma implementação e após uma reversão, as versões antiga e nova devem funcionar com o mesmo esquema.

A resposta padrão é o padrão expandir e contrair. Suponha que você queira renomear name para full_name:

1. Expandir: adicione a nova coluna. O código antigo não é afetado.
2. Migrar: libera código que grava em ambas as colunas e preenche linhas antigas.
3. Switch: libera o código que lê a nova coluna.
4. Contrato: quando nada usar a coluna antiga, remova-a em uma versão posterior.

Isso requer vários lançamentos, mas cada etapa pode ser revertida com segurança. Executar RENAME COLUMN de uma só vez quebraria qualquer versão que esperasse o outro nome. Tenha cuidado também com alterações de esquema de longa duração, pois elas podem conter bloqueios. Para saber mais sobre isso, leia sobre transações SQL.

Rolamento e outras estratégias

Uma implantação do Kubernetes faz uma atualização contínua por padrão, o que é adequado para muitos serviços. Uma atualização contínua também muda gradualmente, mas sua parcela está vinculada ao número de instâncias e não analisa resultados por si só ou faz uma pausa em métricas ruins.

E quanto aos sinalizadores de recursos?

A implantação coloca o código nos servidores e o lançamento disponibiliza um recurso para os usuários. Os sinalizadores de recursos os mantêm separados, permitindo que você ative um recurso para usuários escolhidos sem implantar nada. Eles funcionam muito bem com ambas as estratégias: implantar com o sinalizador desativado e ativá-lo gradualmente. Eles não substituem essas estratégias, pois um sinalizador não pode protegê-lo de uma versão que trava na inicialização. Lembre-se de remover sinalizadores antigos, pois eles se acumulam como dívida técnica.

Como escolher

Eles também podem ser combinados. Algumas equipes implantam um ambiente verde e depois transferem o tráfego para ele gradualmente, obtendo um ambiente limpo e um raio de explosão limitado. Seja qual for sua escolha, automatize-o por meio de seu pipeline de CI/CD, conforme explica nosso guia de ações do GitHub.

Erros comuns

• Fazer alterações significativas no esquema. A reversão não ajuda se o código antigo não conseguir ler os dados.
• Não ter critérios de reversão. Decida o que “ruim” significa antes do início do lançamento, não durante um incidente.
• Deixando os ambientes flutuarem. Se o verde for diferente do azul, seus testes provarão menos. Defina ambos com infraestrutura como código.
• Medindo apenas métricas técnicas. Uma versão pode estar livre de erros e ainda assim interromper a finalização da compra.
• Nunca pratique rollback. Ensaie para que funcione quando você estiver sob pressão.
• Esquecer trabalhos em segundo plano. Trabalhadores e tarefas agendadas também precisam de um plano durante uma mudança.

Considerações finais

Azul esverdeado oferece uma troca limpa e rápida. Canary oferece uma exposição pequena e medida. Se o seu monitoramento ainda for básico, comece com atualizações contínuas ou azul esverdeado e invista em métricas por versão antes de tentar canários. Em seguida, ensaie uma reversão em sua próxima versão, incluindo o banco de dados. Esse único exercício tende a revelar o que realmente precisa ser consertado.

Perguntas frequentes

Continue aprendendo