Séparation des fonctions lors des promotions

• Promotions obtenues principalement via le workflow Pull Request

  • → Créer un PR de promotion (par exemple, d'une branche de l'environnement source vers une branche de l'environnement cible)
  • → Relire/modifier les PR (y compris vérifier le statut de validation des PR)
  • → Fusionner la pull request dans la branche de l'environnement cible
  • → Exécuter le pipeline de déploiement CD (lors d'un commit, d'une déclenchement programmé ou manuel)
  • → Répétez l'opération pour la branche d'environnement suivante
  • → Peut comporter un nombre illimité de branches d'environnement

• Rôles

  • Développeur: valider le code, ce qui entraîne la mise à jour du pipeline d'intégration continue (CI) de l'inventaire principal (hors production)
  • Responsable des opérations de promotion / Responsable des mises en production: déclencher le pipeline de promotion (production → préproduction et/ou préproduction → production), créer des pull requests avec vérification du statut pour le contrôle d'accès (assuré par les listes de contrôle d'accès de la chaîne d'outils et les protections des branches d'inventaire)
  • Opérations de production / Responsable de validation: réviser et fusionner la pull request de mise en production dans la branche de production. Exécuter les pipelines de production. (assuré par la protection des branches d'inventaire)

• Utiliser des chaînes d'outils CD distinctes pour les charges de travail de préproduction et de production (opérations distinctes)

• Cela signifie qu'un développeur peut préparer une modification, mais ne peut pas la mettre en production de manière unilatérale si la protection de la branche nécessite l'intervention d'un autre validateur.

• Le communiqué de promotion fait office de compte rendu officiel de validation des modifications, et l'historique des fusions fournit des preuves vérifiables indiquant qui a approuvé la mise en production et à quel moment.

Etapes du pipeline de promotion

1. Recueillir des commentaires concernant la promotion et la demande de pull/merge associée.
2. Promouvoir les entrées d'inventaire de l'environnement source vers l'environnement cible
3. Créez la demande de promotion (pull/merge). Editez la demande d'extraction ou de fusion pour indiquer les modifications à effectuer. Surveillez les zones facultatives et obligatoires.
4. Optionnel. Définissez les statuts des informations collectées et ajoutez le récapitulatif des informations collectées agrégées à la demande d'extraction / fusion de promotion.
5. Fusionnez la demande d'extraction ou de fusion.
6. Envoyer une notification Slack si la fonctionnalité est activée.

Etapes et tâches

Le tableau suivant répertorie les tâches exécutées dans un pipeline de promotion. De plus, le tableau fournit également un aperçu de chacune de ces étapes :

• Tâche ou étape: il s'agit du nom de l'étape tel qu'il est défini dans le fichier de configuration .pipeline-config.yaml.

• Brève description: ce document fournit une explication concise des actions effectuées lors de l'exécution de l'étape.

• Personnalisation autorisée: cette mention indique si les utilisateurs ont la possibilité de modifier ou de remplacer le comportement par défaut de l'étape en insérant un script personnalisé dans le fichier .pipeline-config.yaml.

• Implémentation de référence par défaut: cette mention indique si les pipelines d' DevSecOps s intègrent une implémentation prédéfinie ou par défaut pour l'étape concernée. Il convient de noter que, pour certaines étapes telles que ou unit-tests setup, le pipeline DevSecOps ne propose aucune implémentation prête à l'emploi. Les utilisateurs doivent donc fournir des scripts ou du code personnalisés, adaptés aux exigences de leur application.

• Collecte des preuves: cette rubrique indique si l'étape prévoit la collecte des preuves standard. Lorsque le pipeline DevSecOps fournit une implémentation de référence pour une étape, la collecte des preuves s'effectue de manière prête à l'emploi. Toutefois, si l'utilisateur choisit de modifier ou de remplacer ces étapes prédéfinies, il doit s'assurer que ses implémentations personnalisées incluent une collecte de preuves appropriée. La même responsabilité incombe aux utilisateurs pour les étapes où le pipeline DevSecOps ne fournit pas de mise en œuvre prête à l'emploi, ce qui les oblige à procéder à la collecte de preuves. La colonne indique l'entité ( Utilisateur/Pipeline ) chargée de procéder à la collecte des preuves.

• Saut autorisé (applicable à la version >= v10 ): cela indique si les utilisateurs peuvent choisir de ne pas exécuter cette étape en définissant la propriété skip sur true dans le fichier .pipeline-config.yaml. Il convient toutefois de faire preuve de prudence lors de l'utilisation de cette fonctionnalité, en particulier pour les étapes destinées à recueillir des preuves. Le fait de sauter ces étapes pourrait entraîner l'absence d'éléments essentiels pour la compilation.

Pour plus d'informations sur la personnalisation des étapes à l'aide du fichier .pipeline-config.yaml, consultez les sections Scripts personnalisés et Listes de paramètres de pipeline.

Exécution du pipeline de promotion

Utilisez le déclencheur de promotion manuel pour exécuter le pipeline de promotion. Si la branche source (master) est en avance sur la branche cible (prod), le pipeline crée une demande de pull/fusion de promotion que vous pouvez examiner et modifier. Si la branche source précède la cible, le pipeline de promotion échoue avec le message All changes have already been promoted.

Pour modifier les valeurs par défaut de la demande de pull/fusion de promotion, ou pour effectuer une promotion à partir d'une source alternative vers la cible, les utilisateurs peuvent modifier les entrées depuis l'interface utilisateur des variables d'environnement du pipeline.

Avant d'exécuter le pipeline de déploiement continu, assurez-vous que la demande de pull/fusion de promotion a bien été fusionnée. Vous pouvez trouver la demande de URL pull/fusion dans les journaux du pipeline.

Pour plus d'informations sur le processus d'inventaire et de promotion, voir Promotion d'inventaire.

Promotion partielle des articles en stock

La méthode de promotion partielle permet au pipeline de promotion de promouvoir un sous-ensemble sélectionné de l'inventaire disponible.

Dans ce contexte, une entrée d'inventaire correspondrait à un fichier unique de type inventory présent dans le référentiel d'inventaire; celui-ci serait associé à un nom de fichier unique sur le système {: important}de fichiers local.

Utilisation des paramètres inventory-include et inventory-exclude active la méthode de promotion partielle.

Lors de l'utilisation inventory-include, les modèles/noms de fichiers fournis dans cette propriété d'environnement sont résolus en leurs entrées respectives et promus par le pipeline. De même, les entrées fournies dans inventory-exclude être exclu de la promotion.

Le format utilise un modèle global (prend également en charge les chemins complets), de la même manière que ce qui est suivi dans le pipeline CC. Pour plus d'informations sur les modèles globaux, consultez le globe manuel.

cd-pipeline-deps
my-application-plugin-component-config
my-application-plugin-component-diagnostic-monitor
configuration # directory entry
configuration/my-staging-region # directory entry
configuration/my-staging-region/environment-1-cluster # directory entry
configuration/my-staging-region/environment-1-cluster/serviceA-component_config
configuration/my-staging-region/environment-1-cluster/serviceB-system_config
configuration/my-staging-region/environment-1-cluster/serviceC-params_config
configuration/serviceX-dashboard-setup_helm
configuration/serviceY-releases_helm
my-application-task-runner
my-application-dashboard
my-application-dashboard_deployment
my-application-module
my-application-module_deployment
.inventoryignore
global_deployment
README.md

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor

    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

    configuration/my-staging-region/environment-1-cluster/serviceA-component_config
    configuration/my-staging-region/environment-1-cluster/serviceB-system_config
    configuration/my-staging-region/environment-1-cluster/serviceC-params_config

    my-application-dashboard
    my-application-dashboard_deployment

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

    cd-pipeline-deps
    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    my-application-task-runner
    my-application-module
    my-application-module_deployment
    .inventoryignore
    global_deployment

Demandes d'extraction / fusion de promotion

Les informations contenues dans le corps de la demande de pull/fusion de promotion sont utilisées pour créer la demande de modification. Les fichiers modifiés par la demande de pull/fusion de promotion correspondent aux éléments, tels que les images, qui sont déployés par le pipeline de déploiement continu. Si les modifications ont été apportées en raison d'une urgence, la demande de promotion (pull/merge) est marquée d'une étiquette urgence. La demande de modification créée par le pipeline de déploiement continu est également marquée comme emergency.

Les informations collectées dans le pipeline d'intégration continue sont récapitulées et jointes à la demande de changement dans le pipeline de déploiement continu.

Pipeline de validation de promotion

Une fois qu'une DA de promotion est ouverte, vous pouvez éventuellement effectuer l'agrégation des informations collectées et la génération de récapitulatif dans le pipeline de validation de la promotion, et définir les statuts des informations collectées sur la demande d'extraction / fusion de promotion (PR). La DA peut être créée par le pipeline Promotion ou manuellement dans le référentiel de stock.

Le pipeline permet la validation anticipée de la DA de promotion avant que la DA ne soit fusionnée avec la branche cible (environnement). En fonction du statut de la DA, les utilisateurs peuvent soit poursuivre la promotion (lorsque tous les statuts d'informations collectées sont verts), soit choisir de résoudre le problème dans le pipeline d'intégration continue (lorsque le statut des informations collectées est rouge).

De plus, le pipeline de validation ajoute également le résumé agrégé des preuves pour une ou plusieurs applications de l'inventaire à la demande de promotion pull/merge sous forme de commentaire, dans un format tabulaire convivial (comme illustré à la figure 3). Le tableau fournit des liens utiles, tels que des liens vers les pipelines, les référentiels d'applications et les problèmes créés pour chacune des applications.

Par défaut, chaque ligne du tableau « État détaillé des preuves » correspond à un contexte d'application fourni par un référentiel source utilisé pour créer le ou les artefacts référencés dans les entrées d'inventaire. Ce regroupement par défaut de l'application peut être personnalisé en fonction d'une valeur de regroupement obtenue en appliquant le filtre JSON (défini dans la propriété application-group-by-filter) à chaque fichier d'entrée d'inventaire.

Pendant que la validation est en cours, la fusion de la demande d'extrusion/fusion de promotion est bloquée. Une fois le pipeline de validation terminé, le statut des informations collectées est défini sur la demande d'extraction ou de fusion. En cliquant sur chaque entrée du statut, l'utilisateur accède à l'étape spécifique de l'exécution du pipeline d'EC correspondant.

Etapes et tâches

Le tableau suivant répertorie les tâches exécutées dans un pipeline de validation de promotion. De plus, le tableau fournit également un aperçu de chacune de ces étapes :

• Tâche ou étape: il s'agit du nom de l'étape tel qu'il est défini dans le fichier de configuration .pipeline-config.yaml.

• Brève description: ce document fournit une explication concise des actions effectuées lors de l'exécution de l'étape.

• Personnalisation autorisée: cette mention indique si les utilisateurs ont la possibilité de modifier ou de remplacer le comportement par défaut de l'étape en insérant un script personnalisé dans le fichier .pipeline-config.yaml.

• Implémentation de référence par défaut: cette mention indique si les pipelines d' DevSecOps s intègrent une implémentation prédéfinie ou par défaut pour l'étape concernée. Il convient de noter que, pour certaines étapes telles que ou unit-tests setup, le pipeline DevSecOps ne propose aucune implémentation prête à l'emploi. Les utilisateurs doivent donc fournir des scripts ou du code personnalisés, adaptés aux exigences de leur application.

• Collecte des preuves: cette rubrique indique si l'étape prévoit la collecte des preuves standard. Lorsque le pipeline DevSecOps fournit une implémentation de référence pour une étape, la collecte des preuves s'effectue de manière prête à l'emploi. Toutefois, si l'utilisateur choisit de modifier ou de remplacer ces étapes prédéfinies, il doit s'assurer que ses implémentations personnalisées incluent une collecte de preuves appropriée. La même responsabilité incombe aux utilisateurs pour les étapes où le pipeline DevSecOps ne fournit pas de mise en œuvre prête à l'emploi, ce qui les oblige à procéder à la collecte de preuves. La colonne indique l'entité ( Utilisateur/Pipeline ) chargée de procéder à la collecte des preuves.

• Saut autorisé (applicable à la version >= v10 ): cela indique si les utilisateurs peuvent choisir de ne pas exécuter cette étape en définissant la propriété skip sur true dans le fichier .pipeline-config.yaml. Il convient toutefois de faire preuve de prudence lors de l'utilisation de cette fonctionnalité, en particulier pour les étapes destinées à recueillir des preuves. Le fait de sauter ces étapes pourrait entraîner l'absence d'éléments essentiels pour la compilation.

Pour plus d'informations sur la personnalisation des étapes à l'aide du fichier .pipeline-config.yaml, consultez les sections Scripts personnalisés et Listes de paramètres de pipeline.

Comment participer à la validation de la promotion?

Déclassé L'option opt-in-promotion-validation qui était utilisée pour lancer automatiquement le pipeline de validation de promotion sur une demande d'extraction est deprecated en faveur de l'option Git Promotion Validation trigger. Si vous avez cette propriété dans les paramètres d'environnement, vous verrez l'avis d'obsolescence dans les journaux de pipeline et la notification Slack.

Comment activer la validation des promotions?

Pour toutes les nouvelles chaînes d'outils CD, un déclencheur Git Promotion Validation est automatiquement créé et activé.

Pour activer le déclencheur de validation de promotion Git sur un pipeline existant, procédez comme suit.

1. Accédez à la page Déclencheur du pipeline CD auquel vous souhaitez l'ajouter.
2. Sélectionnez Ajouter > Git Repository pour ajouter un nouveau déclencheur.
3. Entrez les informations suivantes requises pour le déclencheur:
   • Indiquez un nom de déclencheur. Par exemple: déclencheur de validation de promotion Git.
   • Spécifiez promotion-validation-listener or promotion-validation-listener-gitlab comme EventListener.
   • Sélectionnez le référentiel d'inventaire correspondant pour le pipeline pour la zone Référentiel.
   • Sélectionnez le nom de l'environnement cible pour la branche.
   • Cochez la case de la zone Lorsqu'une demande d'extraction est ouverte ou mise à jour.
4. Cliquez sur Ajouter.
5. Définissez le déclencheur sur On.

Entrées

Sorties et effets

• Notification Slack
• Demande d'extraction / fusion de promotion

Vous devez éditer et modifier la demande d'extraction ou de fusion si les paramètres facultatifs n'ont pas été fournis.

Lorsque la validation de la DA de la promotion (facultative) est exécutée, le statut des informations collectées est défini sur la demande d'extraction / fusion.

Le récapitulatif agrégé des informations collectées (qui peuvent provenir de plusieurs applications de l'inventaire) est affiché sous forme de tableau sous forme de commentaire dans la DA.

Étape suivante

Une fois que le pipeline de promotion a abouti, vous pouvez passer au pipeline CD.