Décider d’une mise en production à partir de preuves

Formuler la décision précisément

Un pipeline vert fournit des preuves issues d’un ensemble de contrôles. Ce n’est pas une description complète de la décision de mise en production. Le responsable doit savoir ce qui va changer, où et quelles conséquences restent à traiter.

Pour un export client fictif, identifiez le commit accepté et l’artefact produit à partir de celui-ci. Nommez l’environnement cible. Reliez les tests pertinents, la revue et toute exception approuvée. Incluez les modifications de données ou d’infrastructure qui accompagnent l’application.

Le SSDF du NIST fournit des pratiques de développement sécurisé, tandis que la provenance SLSA aide à décrire la production d’un artefact. Aucun des deux ne supprime la nécessité de décider si cette version convient à ce service. NIST SSDF, provenance SLSA.

Séparer trois événements

Le merge intègre une modification du code source dans une branche. Le déploiement place un artefact dans un environnement. L’exposition d’une fonctionnalité rend un comportement accessible aux utilisateurs. Ces événements peuvent coïncider, mais ils ne sont pas nécessairement identiques.

Un service peut déployer une fonctionnalité inactive et l’exposer plus tard. Une migration de base de données peut toucher la production avant l’apparition d’une fonctionnalité visible. Définissez la séquence réelle au lieu de supposer que le merge d’une PR décrit toutes les conséquences.

Pour l’export, un feature flag peut limiter l’exposition initiale. Il ne protège pas automatiquement un nouvel endpoint et n’annule pas une migration de schéma. Vérifiez le contrôle à l’endroit où la conséquence se produit.

Examiner un dossier de preuves compact

Utilisez un dossier qu’un autre responsable peut examiner :

• Objectif et utilisateurs touchés.
• Identité du commit et de l’artefact.
• Contrôles pertinents du comportement, de la sécurité et de la compatibilité.
• Environnement cible et identité d’exécution.
• Exceptions restantes, avec responsables et conditions d’expiration.
• Supervision, méthode de reprise et responsable de la réponse.

Gardez des affirmations précises. « Les tests passent » est moins solide qu’un lien vers les résultats du commit livré avec une description claire de la couverture. « Retour arrière disponible » est moins solide qu’une procédure testée avec des limites explicites.

Décider comment arrêter

Définissez les conditions de mise en production avant l’exécution. Pour l’export fictif, arrêtez si l’accès entre organisations réussit, si l’artefact diffère de l’empreinte acceptée ou si la reprise est indisponible. Ce sont des exemples de conditions, pas une liste universelle.

Après le déploiement, examinez les signaux importants pour les utilisateurs. Comparez les erreurs et les temps de réponse aux cibles acceptées du service. Un processus sain ne prouve pas que le parcours utilisateur fonctionne.

Si une condition échoue, utilisez la réponse convenue. Il peut s’agir de désactiver l’exposition, de revenir à un code compatible ou de récupérer des données. Choisissez l’action qui traite la défaillance sans en créer une plus grande.

Conserver la décision après la mise en production

Consignez l’artefact réellement déployé et le résultat. Si l’exécution diffère du plan, rendez cette différence visible. Utilisez les incidents et le travail imprévu pour améliorer la conception de la livraison suivante.

Un système automatisé de livraison doit rendre ce dossier plus facile à examiner. Il ne doit pas obliger une personne à reconstituer la livraison à partir de conversations, journaux et captures d’écran déconnectés. Des preuves claires permettent d’automatiser le travail courant tout en conservant des décisions attribuées à des responsables.