Tome uma decisão de release com evidências

Defina a decisão com precisão

Um pipeline verde é evidência de um conjunto de verificações. Não é uma descrição completa da decisão de release. O responsável precisa saber o que mudará, onde mudará e quais consequências permanecem.

Para uma exportação fictícia de clientes, identifique o commit aceito e o artefato produzido a partir dele. Nomeie o ambiente de destino. Inclua links para testes relevantes, revisão e qualquer exceção aprovada. Inclua as alterações de dados ou infraestrutura que acompanham a aplicação.

O SSDF do NIST fornece práticas de desenvolvimento seguro, enquanto a proveniência SLSA ajuda a descrever como um artefato foi produzido. Nenhum dos dois elimina a necessidade de decidir se esse release é adequado para esse serviço. NIST SSDF, proveniência SLSA.

Separe três eventos

O merge incorpora uma alteração de código-fonte em uma branch. O deployment coloca um artefato em um ambiente. A disponibilização de uma funcionalidade torna o comportamento acessível aos usuários. Esses eventos podem coincidir, mas não são necessariamente o mesmo evento.

Um serviço pode implantar uma funcionalidade inativa e disponibilizá-la depois. Uma migração de banco de dados pode afetar a produção antes de aparecer uma funcionalidade visível. Defina a sequência real em vez de presumir que o merge de um PR descreve todas as consequências.

Para a exportação, uma feature flag pode limitar a disponibilização inicial. Ela não protege automaticamente um novo endpoint nem reverte uma migração de schema. Verifique o controle no ponto em que a consequência ocorre.

Revise um registro compacto de evidências

Use um registro que outra pessoa responsável possa inspecionar:

• Objetivo e usuários afetados.
• Identidade do commit e do artefato.
• Verificações relevantes de comportamento, segurança e compatibilidade.
• Ambiente de destino e identidade de execução.
• Exceções restantes com responsáveis e condições de validade.
• Monitoramento, método de recuperação e responsável pela resposta.

Mantenha as afirmações específicas. “Os testes passaram” é mais fraco que um link para os resultados do commit de release com uma descrição clara da cobertura. “Rollback disponível” é mais fraco que um procedimento testado com limites declarados.

Decida como interromper

Defina as condições de release antes da execução. Para a exportação fictícia, interrompa se o acesso entre organizações for permitido, se o artefato diferir do digest aceito ou se a recuperação estiver indisponível. Essas condições são ilustrativas, não uma checklist universal.

Após o deployment, inspecione os sinais importantes para os usuários. Compare o comportamento de erro e os tempos de resposta com as metas aceitas do serviço. Um processo saudável não prova que o fluxo do usuário funciona.

Se uma condição falhar, use a resposta acordada. Isso pode significar desativar a funcionalidade, fazer rollback de código compatível ou recuperar dados. Escolha a ação que resolve a falha sem criar outra maior.

Preserve a decisão após o release

Registre o artefato efetivamente implantado e o resultado. Se a execução diferir do plano, deixe a diferença visível. Use incidentes e trabalho inesperado para melhorar o projeto do próximo release.

Um sistema automatizado de entrega deve facilitar a inspeção desse registro. Não deve exigir que um revisor reconstrua o release a partir de chats, logs e capturas de tela desconectados. Evidências claras permitem automatizar trabalho rotineiro com responsabilidade pelas decisões.