Release não é deploy

Duas palavras são usadas como se fossem a mesma coisa, e quase todo problema de deploy mora na distância entre elas.

Deploy é colocar código novo na infraestrutura. Release é deixar as pessoas usuárias chegarem nele. Toda estratégia deste curso é um jeito diferente de separar esses dois eventos, e as estratégias ficam melhores conforme a distância entre eles aumenta.

Uma atualização gradual simples mantém os dois juntos: o código chega e o tráfego vai atrás, pod a pod, e a primeira pessoa a descobrir se a release era boa ideia é uma pessoa usuária.

flowchart LR
  subgraph coupled["Acoplado — atualização gradual"]
    D1["deploy"] --> R1["release"] --> U1["as pessoas acham o bug"]
  end
  subgraph separated["Separado"]
    D2["deploy"] --> V["verificar contra a produção"] --> R2["release, nos seus termos"]
  end

As quatro estratégias

Elas respondem perguntas diferentes, então não formam uma escada para subir:

• Este build está saudável? Blue-green. Verifique o ambiente novo inteiro e mande todo mundo de uma vez.
• Esta mudança é boa para pessoas reais? Canário. Dê 5% do tráfego e leia os erros.
• Esta pessoa específica já deve ver este recurso? Flags, que não têm nada a ver com deploy.

Muitos setups maduros usam as três, porque elas operam em camadas diferentes: blue-green e canário controlam qual build serve tráfego, e as flags controlam qual comportamento um build mostra.

O que todas compartilham

Toda estratégia deste curso tem a mesma restrição dura, e ela diz respeito aos dados, não ao tráfego:

Duas versões do seu código vão rodar contra um único banco ao mesmo tempo.

No blue-green, os dois ambientes apontam para os mesmos dados. No canário, o velho e o novo dividem o banco. Até uma atualização gradual roda pods velhos e novos contra um schema. Nenhuma estratégia de deploy te dá duas versões dos seus dados, e fingir o contrário é de onde vêm os incidentes.

É por isso que a disciplina de migrações dos cursos anteriores de deploy é pré-requisito aqui: uma estratégia de release da qual você não consegue voltar é um jeito mais lento de publicar a mesma indisponibilidade. A aula 5 trata dessa restrição.

O que "zero downtime" exige

A expressão gruda em ferramentas, mas a ferramenta é a metade menor:

1. Um sinal de saúde que signifique algo. Se o /up devolve 200 enquanto o app não alcança o banco, toda estratégia aqui promove uma versão quebrada com confiança.
2. Encerramento gracioso. As instâncias velhas precisam terminar as requisições em andamento antes de parar (drain_timeout no Kamal, terminationGracePeriodSeconds no Kubernetes).
3. Mudanças retrocompatíveis: schema, formatos de cache, payloads de jobs, dados de sessão, qualquer coisa que duas versões toquem.
4. Um rollback que você já testou. Um caminho de rollback nunca exercitado é só um plano.

Três dos quatro são propriedades da sua aplicação. Só o segundo é comprado com infraestrutura.

O que este curso cobre

1. Release não é deploy (você está aqui).
2. Blue-green: dois ambientes, uma chave.
3. Canário: liberando para uma fração.
4. Feature flags: liberando para uma pessoa.
5. O banco é a parte difícil.
6. Decidindo, e voltando atrás.
7. Juntando tudo: escolhendo uma estratégia.

Pontos-chave

• Deploy põe código na infraestrutura; release deixa as pessoas chegarem nele. Toda estratégia aqui aumenta a distância entre os dois.
• Blue-green troca ambientes inteiros, canário divide tráfego e flags controlam caminhos de código por pessoa; resolvem problemas diferentes e se combinam.
• Todas rodam duas versões de código contra um único banco ao mesmo tempo.
• Zero downtime exige um health check verdadeiro, encerramento gracioso, mudanças retrocompatíveis e um rollback que você já testou.