Évaluation de l'état de préparation au déploiement

Avant la création d'une demande de modification, le pipeline calcule l'état de préparation au déploiement et attribue à l'indicateur DEPLOYMENT_READY la valeur true ou false. Cet indicateur est dérivé des preuves collectées au cours des étapes de l'IC et de la CD. Si un contrôle des éléments de preuve indique un écart, une absence ou un échec de contrôle, d'analyse ou de test concernant l'ensemble d'artefacts déployé, DEPLOYMENT_READY devient false.

La demande de changement est préparée avec les champs suivants provenant du dernier PR de promotion fusionné dans la branche cible :

• risk
• impact
• priority
• assignee
• description
• purpose
• customer impact
• deployment impact
• backout plan

Création d'une demande de modification

La demande de changement préparée est soumise dans l'un des deux états initiaux en fonction de DEPLOYMENT_READY:

Le système de gestion des changements approuve également automatiquement les demandes de changement lorsque la mise en œuvre n'entraîne pas de temps d'arrêt (durée d'arrêt nulle), que DEPLOYMENT_READY est true et que le risque de déploiement se situe dans des limites acceptables.

Si vos changements nécessitent un temps d'indisponibilité planifié, vous devez créer la demande de changement manuellement et l'envoyer pour approbation. Une fois la demande de changement approuvée, vous pouvez démarrer le déploiement en fournissant l'ID de demande de changement. Le pipeline vérifie son état d'approbation et exécute ensuite le déploiement. Pour plus d'informations, voir Approbation manuelle des demandes de changement.

Pièces jointes avant déploiement

Immédiatement après la création de la demande de modification, le pipeline attache les artefacts suivants à l'enregistrement de la demande de modification :

• Nomenclature de déploiement- liste de tous les composants inclus dans le déploiement
• Résumé du delta- position des éléments de preuve de tous les composants participant au déploiement
• Fichier de configuration des contrôles des preuves- joint uniquement si le contrôle des preuves est configuré dans le pipeline
• Profil SCC- joint uniquement si une configuration de sécurité et de conformité est configurée

Porte d'approbation

Si la demande de modification a été créée comme non approuvée, elle est placée dans un état non approuvé et envoyée pour examen humain. Aucun déploiement n'a lieu tant que l'approbation n'a pas été accordée.

Vous pouvez consulter l'identifiant de la demande de modification créée dans les journaux du pipeline, attendre qu'elle soit approuvée, puis relancer le déploiement en utilisant ce même identifiant. Le pipeline vérifie l'état d'approbation et poursuit le déploiement.

Tests de déploiement et d'acceptation

Lorsque le CR est en état de mise en œuvre, le pipeline s'exécute :

• Déploiement sur CD- promotion du code dans l'environnement cible
• Tests d'acceptation- validation du résultat du déploiement

Ces deux étapes sont pilotées par l'utilisateur.

Fermeture de la CR après le déploiement

Lorsque les tests de déploiement et d'acceptation sont réussis, le pipeline attache les artefacts de clôture et ferme la demande de changement :

• Résumé de clôture- un résumé des preuves pour toutes les écritures d'inventaire au niveau de l'engagement cible.
• Nomenclature fusionnée- la nomenclature logicielle post-déploiement pour tous les composants de l'inventaire.

Le CR est ensuite clôturé par un close_category basé sur le DEPLOYMENT_READY au moment de la clôture :

Types de changement

La gestion des demandes de modification prend en charge deux types de modifications : les modifications d'urgence et les modifications courantes.

Si la modification en cours est une modification d'urgence, ajoutez le label « emergency » à la pull request de promotion.

Il n'y a pas de débit d'urgence du côté de l'oléoduc CI. Toutefois, le fait de donner à la propriété skip-inventory-update-on-failure du pipeline CI/déclencheur une valeur vide ou 0 permet de mettre à jour le référentiel d'inventaire même si des problèmes sont détectés lors de l'exécution du pipeline CI. Grâce à cet inventaire actualisé, un changement d'urgence peut être activé.

Choisir une voie de rétablissement

Voie 1 : retour en arrière complet à l'aide de l'auditeur de retour en arrière dédié

S'il existe une dernière configuration connue, c'est-à-dire un état précédemment déployé qui est confirmé stable, le chemin le plus rapide pour restaurer le service est un retour en arrière complet. Cette opération utilise un auditeur de retour en arrière spécialement conçu pour ce scénario et qui ne nécessite pas de nouvelle construction ou de promotion.

Pour des instructions étape par étape et les paramètres à configurer, voir Retour en arrière complet à l'aide de l'auditeur de retour en arrière dédié.

Voie 2 : Fixer pour avancer en tant que changement d'urgence

S'il n'existe pas de cible de retour en arrière viable, ou si l'enquête a déjà produit un correctif, le correctif peut être déployé en tant que changement d'urgence. Cette voie court-circuite la logique standard de blocage des preuves : le pipeline permet la mise en œuvre immédiate du changement, et la demande de changement fait l'objet d'un examen et d'une approbation rétroactifs après la résolution de l'incident.

Choisir cette voie, c'est accepter que le code déployé en production puisse encore contenir des vulnérabilités non résolues ou des lacunes dans les éléments de preuve. Le rétablissement du service est considéré comme une priorité absolue et les questions de conformité en suspens doivent être traitées après la clôture de l'incident.

Ces deux voies ne s'excluent pas mutuellement. Dans la pratique, les équipes peuvent d'abord procéder à un retour en arrière complet pour rétablir le service immédiatement, puis faire suivre d'un correctif une fois que le correctif est prêt et validé. Le séquençage est laissé à l'appréciation de l'opérateur en fonction de la situation.

Procédure de rattrapage

Pour déployer un correctif en tant que changement d'urgence au cours d'une CIE, procédez comme suit :

1. Reconstruire le composant concerné. Exécuter le pipeline CI pour construire une nouvelle version de l'artefact contenant la correction. Si les vérifications de preuves de CI échouent en raison de conditions d'incident, définissez la propriété de pipeline ou de déclenchement skip-inventory-update-on-failure sur une valeur vide ou 0 pour permettre la mise à jour de l'inventaire malgré les échecs, afin que le changement d'urgence puisse avoir lieu.

2. Promouvoir la solution par le biais d'environnements. Créer des demandes de promotion en commençant par l'environnement le plus bas et en remontant vers la production. Si le temps le permet, vérifiez la correction à chaque étape avant de poursuivre la promotion. Si la situation est critique, passez directement à la production et réconciliez les environnements inférieurs une fois le service rétabli.

3. Appliquez l'étiquette d'urgence. Sur la demande de promotion ciblant la production, ajoutez l'étiquette emergency. Cela signale au pipeline que le contrôle des preuves standard doit être contourné et que la modification doit être traitée comme un déploiement d'urgence.

4. Déployer en production. Exécutez le pipeline CD. Le pipeline détecte l'étiquette d'urgence, évite l'attente de l'approbation et passe immédiatement aux tests de déploiement et d'acceptation. La demande de modification est créée et clôturée à l'adresse close_category = successful with issues, ce qui indique que la modification a été déployée dans des conditions d'urgence.

5. Rapprocher les environnements inférieurs. Une fois l'incident de production résolu, déployez le même artefact de correction d'urgence dans les environnements inférieurs (staging, pré-production, etc.) afin que tous les environnements soient dans un état cohérent avec la production. Si les environnements inférieurs ont été vérifiés avant de passer à la production, confirmez que la même version de l'artefact est en place dans tous les niveaux.

Obligations post-CIE

Un déploiement d'urgence entraîne des obligations de conformité qui doivent être respectées après la clôture de l'incident :

• La demande de modification doit être examinée rétroactivement et approuvée par les approbateurs appropriés.
• Toute lacune acceptée pendant l'urgence - vulnérabilités non résolues, analyses incomplètes ou vérifications échouées - doit être corrigée et le pipeline doit être réexécuté dans des conditions normales.
• Une analyse des causes profondes (RCA) doit être effectuée et documentée.

L'enregistrement de la demande de changement, y compris le Delta Summary, le Closing Summary et le Merged SBOM joint par le pipeline, sert de piste d'audit principale pour la révision post-CIE.

Invoquer le flux d'urgence

Le flux d'urgence est déclenché par l'utilisateur :

1. L'utilisateur exécute le pipeline avec l'étiquette emergency appliquée à la demande de promotion.
2. Le pipeline détecte la désignation d'urgence et les tests de déploiement et d'acceptation se déroulent immédiatement, sans attendre l'approbation de la norme.
3. Le CR est clôturé avec les notes de clôture comme successful with issues.

Si la modification en cours est une modification d'urgence, ajoutez le label « emergency » à la pull request de promotion avant de lancer le pipeline.

Déploiement post-urgence

Une fois que le flux d'urgence a terminé le déploiement et les tests, il rejoint le flux standard au stade du post-déploiement :

• Le résumé de clôture et le SBOM fusionné sont joints au CR.
• close_category Le CR est fermé en suivant la même logique DEPLOYMENT_READY que le flux standard.

Si le type de CR est emergency, la demande de modification doit être examinée et approuvée rétroactivement après le déploiement.

Condition de déclenchement

Le flux de retour en ligne est mis en place lorsque les tests de déploiement ou d'acceptation ne sont pas concluants. Le pipeline évalue ensuite si le retour à la ligne est activé :

• La fonction Inline-Rollback n'est pas activée: Le CR reste ouvert avec close_category = unsuccessful et le pipeline se termine. Aucune récupération automatique n'est tentée.
• Rollback activé: Le script de retour en arrière est exécuté pour rétablir l'environnement cible, et les artefacts de retour en arrière sont rassemblés et joints au CR.

Exécution du rollback en ligne

Lorsque le retour en ligne est activé, le pipeline :

1. Exécute le script de retour en ligne si le déploiement ou le test d'acceptation a échoué dans le pipeline CD.
2. Collecte les artefacts suivants :
   • Journaux de rollback- résultats de l'exécution du script de rollback
   • Résumé de clôture- reflète le résultat du rollback
   • Nomenclature fusionnée- nomenclature logicielle post-rollback
3. Attache les trois artefacts à l'enregistrement CR ouvert.

Fermeture du CR après le rollback

Après le retour en ligne et l'attachement de l'artefact, le CR reste ouvert avec close_category = unsuccessful. Cela indique à la gestion des changements que le déploiement a été tenté, qu'il a échoué et qu'il a été automatiquement annulé.

Un CR avec close_category = unsuccessful est le résultat attendu et correct lorsqu'un déploiement est inversé - ce n'est pas une indication d'une défaillance du processus. Les équipes opérationnelles doivent utiliser les journaux de retour en arrière ci-joints pour rechercher la cause première.

Exécution d'un pipeline avec une demande de changement pré-approuvée

Vous pouvez utiliser une demande de modification (CR) pré-approuvée pour le déploiement. Deux scénarios sont possibles :

Lorsque le pipeline CD reconnaît que le CR a été créé par une exécution antérieure du pipeline CD, il accélère le déploiement :

• Réutilisation du delta précalculé et du résumé des preuves provenant des preuves CR.
• Omission des étapes de révision par les pairs et de vérification des signatures.
• Déploiement du delta précalculé.

Lorsque le pipeline de CD ne peut pas déterminer si le CR a été créé par une exécution antérieure du pipeline de CD, ou si le CR fourni ne correspond pas à la cible de déploiement de l'exécution en cours :

• Il ne réutilise aucun delta précalculé ni aucun résumé de preuves.
• Il ne fait pas l'impasse sur l'examen par les pairs ou la vérification de la signature de l'artefact.
• Il recalcule le delta et le résumé à partir de zéro.
• Il ne crée pas de nouveau CR, puisqu'un CR a déjà été fourni.

Réexécution du pipeline en cas d'échec du déploiement

Si vous ne souhaitez pas utiliser la gestion automatisée des modifications, vous pouvez fournir à la place une demande de modification préalablement créée et approuvée. Réexécutez les déploiements ayant échoué dans les scénarios suivants:

• La dernière demande de modification générée automatiquement n'est pas prête à être déployée et n'a pas été approuvée automatiquement. Vous avez reçu l'approbation et devez relancer le déploiement en utilisant la même demande de modification.
• Le déploiement nécessite un temps d'indisponibilité. Vous avez créé la demande de modification, celle-ci a été approuvée et vous avez respecté la politique de gestion des changements de votre organisation.
• Il n'y a eu aucun changement de code ou de configuration. Vous avez créé la demande de modification, expliqué ce qui a changé, reçu l'approbation et commencé un déploiement en utilisant la demande de modification approuvée.

La demande de changement (CR) reste ouverte après la fin de la chaîne de traitement des demandes de changement (CD).

Vous pouvez lancer le pipeline de déploiement continu de référence d' DevSecOps en utilisant une demande de modification pré-approuvée et en saisissant l'identifiant de cette demande dans la propriété **change-request-id**.

demande de modification préapprouvée

Si la propriété « change-request-id » est définie, le pipeline ignore la collecte des données relatives à la demande de modification et passe directement à la vérification de l'état d'approbation. Si le paramètre « ID de la demande de modification » est défini par défaut sur « notAvailable », une demande de modification est automatiquement créée par le pipeline.