Lesquels des contrôles pré-déploiement ont réellement empêché une mauvaise publication l'année dernière, et lesquels ne se sont jamais déclenchés ?

Question ouverte

Un pipeline de publication accumule des portes de contrôle au fil du temps : tests unitaires et d'intégration, vérification de la reproductibilité du build, scan de conteneur, test de fumée après déploiement, comparaison canary, validation manuelle, et délai de déploiement. La documentation Kubernetes sur les Deployments, par exemple, décrit progressDeadlineSeconds et indique que Kubernetes n'entreprend aucune action sur un Deployment bloqué, hormis signaler une condition ProgressDeadlineExceeded ; c'est à autre chose d'agir. Chaque porte de contrôle coûte du temps à chaque publication et bloque parfois une bonne publication. Ce que le wiki ne dit pas, ce sont des preuves sur les portes qui ont mérité leur place : sur une année de publications, lesquelles ont stoppé une publication qui aurait causé un incident, lesquelles ne se sont jamais déclenchées du tout, et lesquelles ne se sont déclenchées que sur de faux positifs qui ont été outrepassés ? Les équipes conservent-elles un historique qui permettrait d'y répondre, ou le souvenir que « ce contrôle nous a sauvés une fois » constitue-t-il la seule preuve ? Et la réponse diffère-t-elle entre les portes qui s'exécutent avant la construction de l'artefact, celles qui s'exécutent dans un environnement de préproduction, et celles qui observent le déploiement en production ?

La question n'est pas de savoir si les portes de contrôle sont bonnes en principe, mais lesquelles, pour un type de service donné, ont fait leurs preuves, de sorte qu'une équipe puisse consacrer le temps de son pipeline là où cela a effectivement stoppé quelque chose.

Ce qu'une réponse utile contient

Le type de service, la fréquence de publication et le mécanisme de déploiement. La liste des portes de contrôle avec, pour chacune, le nombre de publications sur la période, le nombre de blocages, combien de blocages ont ensuite été jugés vrais positifs, et combien ont été outrepassés. Pour chaque vrai positif, ce qui aurait atteint les utilisateurs et la manière dont la porte l'a détecté. Pour les portes qui ne se sont jamais déclenchées, si l'équipe les a supprimées, les a conservées par précaution, ou a découvert qu'elles étaient mal configurées (un contrôle qui ne pouvait pas échouer). La manière dont l'historique a été tenu : journaux de pipeline, un champ de revue d'incident, ou reconstitution de mémoire, car cela détermine la confiance à accorder aux chiffres. Si le seuil d'une porte a été ajusté pendant la période, et si une porte qui s'est déclenchée à raison était bien une porte ajoutée à la suite d'un incident. Les retours sur des portes restées silencieusement défaillantes pendant des mois sont tout aussi précieux que les retours sur des portes qui ont fonctionné.