← Release Manager: versões, prontidão e operação
07 / 10 · 60 MIN

Compatibilidade e estado da release

Avalia os estados intermédios da mudança e liga critérios de avanço à versão, aos dados e à execução efetiva.

Descrever o estado que foi ensaiado

Começa por identificar binário, configuração, esquema, consumidores e condições de ativação. Num serviço de posições fictício, o mesmo binário funciona no ensaio, mas a configuração de destino ativa um consumidor diferente. A correspondência do hash prova identidade do ficheiro, sem demonstrar equivalência dessa combinação. Pede evidência dos caminhos afetados e regista o que ainda falta. Uma matriz pequena pode mostrar versão antiga e nova contra esquema anterior, expandido e contraído. Cada célula deve indicar a operação exercitada: ler, escrever, reprocessar ou recuperar. Uma célula verde baseada apenas numa consulta de leitura não cobre uma inserção de batch. O Release Manager usa a matriz para coordenar decisões e responsáveis, sem substituir a análise dos especialistas que conhecem os contratos de dados.

Separar expansão e contração

O laboratório cria positions com id e amount e acrescenta currency, que permite NULL. O escritor antigo especifica id e amount e continua a funcionar. Um cliente que omite a lista de colunas precisa do seu próprio teste: a forma da instrução pode depender do número de colunas. Numa segunda tabela, que representa apenas a forma do estado contraído, currency é obrigatório sem valor por omissão; a escrita antiga é rejeitada. Não se trata de uma receita de migração de produção. Antes de contrair um esquema real, confirma escritores, leitores, jobs esporádicos e dados existentes. Um backfill às 21:00 pode ficar desatualizado se um escritor antigo gerar novos NULL. Também verifica significado: manter o tipo inteiro não torna compatível passar de unidades completas para unidades menores.

Ligar intenção à execução

No exercício de geração, J1 leu sete e J2 já avançou para oito. A atualização de J1 com WHERE generation=7 altera zero linhas. Esse resultado exige reler o estado e rever a intenção. Não prova que a versão pretendida por J1 já esteja instalada. A proteção SQL também termina na transação local: um comando remoto executado depois continua a precisar de coordenação e verificação. Se o script ignora zero linhas e instala um pacote antigo, a metadata e o ambiente divergem. A revisão deve identificar essa fronteira, o tratamento da pré-condição falhada e como observar a versão efetiva. Um rollback deliberado deve ter alvo e autorização atuais; deixar um job velho concluir por acaso não é uma estratégia de recuperação.

Decidir com exposição e tempo disponíveis

O canary fictício tem seis erros em 150 pedidos: 4%. O controlo tem nove em 9850, e o total quinze em dez mil: 0,15%. Um limite de paragem de 2% aplicado ao canary foi ultrapassado, embora o agregado pareça favorável. Se ambos usam a mesma base de dados, a mudança pode degradar os dois grupos; avalia saúde absoluta e mecanismo de carga antes de atribuir causa. Liga a decisão à janela restante. Para um serviço validado às 23:00, vinte minutos de recuperação, quinze de reconciliação e dez de validação exigem começar até 22:15 no modelo sem folga. Este limite aritmético não recomenda esperar. Aos 22:25 faltam dez minutos ao caminho ensaiado; comunica a incompatibilidade e as opções sustentadas, preservando critérios de resultado.

UPDATE target
SET generation = 8, version = 'v8'
WHERE id = 'test' AND generation = 7;
-- Check changed-row count and actual state.
-- This protects only this local metadata update, not remote commands.
NA PRÁTICA

Estado expandido: a escrita antiga com colunas explícitas passa. Estado contraído: o campo obrigatório rejeita essa mesma escrita. O ensaio cobre essas operações, não todos os consumidores.

Armadilhas comuns

Forma SQL como significado; backfill como conclusão; transação de metadata como instalação atómica; erro agregado como saúde do canary.

Tópicos relacionados: Prontidão e exposição gradual · Sequência e dependências

Leva esta ideia contigo

Uma release atravessa estados intermédios; cada avanço precisa de evidência aplicável e de uma opção de recuperação ainda executável.

Criar conta

Referência: Safe deployment practices · Google SRE release and canary guidance; GitHub immutable releases and GitLab release evidence and deployment safety; DORA five-metric model; inspected 2026-10-01