Quais verificações pré-implantação realmente barraram uma versão ruim no último ano, e quais nunca dispararam?

Pergunta em aberto

Um pipeline de release vai acumulando gates ao longo do tempo: testes unitários e de integração, uma verificação de reprodutibilidade do build, uma varredura de contêineres, um smoke test após o deploy, uma comparação de canary, uma aprovação manual e um prazo de rollout. A documentação de Deployment do Kubernetes, por exemplo, descreve progressDeadlineSeconds e afirma que o Kubernetes não toma nenhuma ação sobre um Deployment travado além de reportar a condição ProgressDeadlineExceeded; é preciso que outro mecanismo aja a partir disso. Cada gate consome tempo em toda release e, de vez em quando, bloqueia uma versão boa. O que falta na wiki são evidências sobre quais gates mereceram seu lugar: ao longo de um ano de releases, quais gates barraram uma versão que teria causado um incidente, quais nunca dispararam e quais só dispararam em falsos positivos que acabaram sendo ignorados? As equipes mantêm algum registro que permita responder a isso, ou a lembrança de que "aquela verificação nos salvou uma vez" é a única evidência? E a resposta muda conforme o gate rode antes da construção do artefato, em um ambiente de staging ou durante o rollout em produção?

A questão não é se os gates são bons em princípio, mas quais deles, para um determinado tipo de serviço, têm histórico comprovado, de modo que a equipe possa investir o tempo do pipeline onde ele já impediu algum problema.

O que uma resposta útil contém

O tipo de serviço, a frequência de releases e o mecanismo de rollout. A lista de gates com, para cada um, o número de releases no período, o número de bloqueios, quantos bloqueios foram avaliados depois como verdadeiros positivos e quantos foram ignorados por override. Para cada verdadeiro positivo, o que teria chegado aos usuários e como o gate percebeu o problema. Para os gates que nunca dispararam, se a equipe os removeu, os manteve como seguro ou descobriu que estavam mal configurados (uma verificação que não tinha como falhar). Como o registro foi mantido: logs do pipeline, um campo na revisão de incidentes ou reconstrução de memória, já que isso determina quanta confiança se pode dar aos números. Se o limiar de algum gate foi ajustado durante o período e se um gate que disparou com razão era um que havia sido adicionado depois de um incidente. Relatos de gates que ficaram quebrados sem ninguém notar por meses são tão valiosos quanto relatos de gates que funcionaram.