Decidir um lançamento com evidências

Formule 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 lançamento. O responsável precisa de saber o que vai mudar, onde vai mudar e que consequências permanecem.

Para um export de clientes fictício, identifique o commit aceite e o artefacto produzido a partir dele. Identifique o ambiente de destino. Ligue os testes relevantes, a 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 foi produzido um artefacto. Nenhum elimina a necessidade de decidir se este lançamento é adequado para este serviço. NIST SSDF, proveniência SLSA.

Separe três eventos

O merge coloca uma alteração do código-fonte num branch. O deployment coloca um artefacto num ambiente. A disponibilização de uma funcionalidade torna o comportamento acessível aos utilizadores. Estes eventos podem coincidir, mas não são necessariamente o mesmo evento.

Um serviço pode fazer o deployment de uma funcionalidade inativa e disponibilizá-la mais tarde. Uma migração da base 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.

No export, uma feature flag pode limitar a disponibilização inicial. Não protege automaticamente um novo endpoint nem reverte uma migração de esquema. Verifique o controlo no ponto em que a consequência ocorre.

Reveja um registo compacto de evidências

Use um registo que outra pessoa responsável possa examinar:

• Finalidade e utilizadores afetados.
• Identidade do commit e do artefacto.
• 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 expiração.
• Monitorização, método de recuperação e responsável pela resposta.

Mantenha as afirmações específicas. «Os testes passaram» é menos sólido do que uma ligação aos resultados do commit de lançamento com uma descrição clara da cobertura. «Rollback disponível» é menos sólido do que um procedimento testado com limites declarados.

Decida como parar

Defina as condições de lançamento antes da execução. Para o export fictício, pare se o acesso entre organizações for bem-sucedido, se o artefacto diferir do digest aceite ou se a recuperação estiver indisponível. Estas são condições ilustrativas, não uma lista de verificação universal.

Após o deployment, examine os sinais relevantes para os utilizadores. Compare o comportamento dos erros e os tempos de resposta com os objetivos aceites do serviço. Um processo operacional não prova que o fluxo de trabalho do utilizador funciona.

Se uma condição não for cumprida, use a resposta acordada. Isto pode significar desativar a disponibilização, 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 lançamento

Registe o artefacto realmente instalado e o resultado. Se a execução diferir do plano, torne a diferença visível. Use os incidentes e o trabalho inesperado para conceber o lançamento seguinte.

Um sistema automatizado de entrega deve facilitar a inspeção deste registo. Não deve exigir que um revisor reconstrua o lançamento a partir de conversas, logs e capturas de ecrã sem ligação. Evidências claras permitem às equipas automatizar trabalho de rotina e manter decisões com responsáveis.