Gestion de la vérification par les pairs dans les chaînes d'outils CI/CD

Cette documentation fournit des instructions pour l'activation et la désactivation de la vérification de la révision homologue dans l'intégration continue (CI) et facultative dans les chaînes d'outils Continuous Delivery (CD).

Points importants

Vous devez effectuer des examens par les pairs uniquement sur la branche protégée (de base), où le stock est mis à jour. Si vous exécutez un pipeline d'EC sur une branche de fonction, définissez la variable d'environnement peer-review-compliance sur 0 pour ce déclencheur spécifique afin d'empêcher la vérification par les pairs sur la branche de fonction.

Le respect de la conformité à l'examen par les pairs dépend de la réussite de l'exécution d'un pipeline d'intégration continue (EC) et de l'entrée ultérieure dans l'inventaire. Par conséquent, l'exécution initiale du pipeline d'EC ignorera la vérification de conformité de l'examen par les pairs.

Pour garantir la conformité aux normes d'examen par les pairs, il est supposé que les mises à jour de l'inventaire dans l'étape ci-finish ont lieu dans la branche master. Toutefois, si vos mises à jour de stock sont effectuées sur une branche autre que la branche principale, vous pouvez définir la variable d'environnement inventory-repo-branch pour indiquer la branche dans laquelle les mises à jour de stock sont effectuées.

Dans le cadre d'un déploiement continu (CD), toutes les mises à jour de l'inventaire effectuées dans le référentiel d'inventaire seront promues dans la branche cible en cours de déploiement, ce qui permet de s'assurer qu'aucun commit n'est oublié. Par défaut, lors du déploiement, le référentiel d'inventaire sera extrait vers la branche cible. Cependant, si votre branche cible de promotion de l'inventaire manque de commits entre la branche de base et la branche cible, vous pouvez définir la variable d'environnement inventory-repo-branch pour spécifier la branche de base où se trouvent tous les commits de l'inventaire.

Par défaut, le pipeline Intégration continue (CI) effectue automatiquement une validation dans le référentiel d'inventaire à la fin de l'exécution, en utilisant le nom de l'application comme entrée d'inventaire. Toutefois, si vous avez l'intention de modifier l'entrée d'inventaire lors de la phase d'édition, il est recommandé d'incorporer une propriété d'environnement nommée inventory-entry-name dans votre chaîne d'outils. Cette propriété doit contenir le nom d'inventaire modifié pour le processus de révision par les pairs.

Si vous avez une automatisation qui pousse les commits directement vers votre branche protégée et que vous voulez éviter les problèmes avec les contrôles de conformité de la révision par les pairs, assurez-vous que votre message de commit inclut ##AUTOMATED_COMMIT##.

L'implémentation de référence découvre des exemples de code qui ne sont pas examinés par des pairs, recueille des preuves et crée des questions d'incident pour suivre ces éléments.

Avant de pouvoir fusionner du code dans la branche master (protégée), le code doit être revu par une personne qui n'a pas téléchargé le code modifié.

Le dépôt de code (repo) doit avoir au moins deux membres : un membre qui a des privilèges d'administrateur et un autre membre qui a des privilèges d'écriture. Si le code est fusionné dans un référentiel sans révision, l'action doit être visible dans la trace d'audit du référentiel de code. Analysez périodiquement la trace d'audit pour identifier et analyser ces situations exceptionnelles.

Le pipeline recueille les données de conformité à l'examen par les pairs au cours des constructions et des déploiements afin de créer une piste d'audit à partir des demandes de fusion et d'extraction de code jusqu'aux demandes de modification.

Dans ce diagramme, PR1, PR2 sont les demandes d'extrusion/fusion qui sont approuvées avant la fusion. De même, pour PR4, PR5et PR7. Toutefois, PR3 et PR6, mis en évidence en rouge, sont fusionnés sans approbation, ce qui constitue une violation de conformité à la révision par les pairs. Cet élément est capturé en tant que preuve.

Par défaut, l'exemple d'application de la chaîne d'outils EC tente de définir le nombre minimal de réviseurs sur 1. Si vous souhaitez modifier le nombre de réviseurs, définissez la propriété d'environnement peer_review_approvers selon les besoins. Pour plus d'informations sur la définition du nombre minimal de réviseurs requis pour une demande d'extraction ou de fusion, voir les ressources GitHub et GitLab suivantes:

• GitHub: Exiger plusieurs réviseurs pour les pull requests
• GitLab: Règles d'approbation des demandes de fusion

Données collectées dans le cadre de l'intégration continue

Cette collection de données contient une liste de tous les commits pour les requêtes pull/merge qui ont été fusionnés dans les dépôts de l'application depuis le dernier build.

Les données de demande d'extraction sont collectées directement depuis les référentiels d'applications. Les données relatives à chaque demande de fusion/extraction liée à des livraisons entre la livraison du repo qui a déclenché la construction précédente et la livraison actuellement disponible sont collectées.

Les commits qui ne contiennent pas de demande de pull/merge créent un problème d'incident de conformité dans les versions suivantes du pipeline. Vous ne pouvez pas effectuer de commit directement sur la branche master.

Un incident de conformité contient généralement les informations suivantes:

• Liste des URL de demande d'extraction ou de fusion pour l'ID de validation associé.
• Référentiel d'application.
• ID de validation.
• Nombre requis d'approbations.

Les données collectées sont sauvegardées en tant qu'artefact de preuve, qui est téléchargé dans le casier des preuves et auquel il est fait référence dans les preuves elles-mêmes. Le résultat final de la preuve est déterminé par les demandes d'extraction/fusion approuvées. Les demandes d'extraction/fusion non approuvées mais fusionnées échouent à ce type de preuve.

Données collectées dans le cadre d'un déploiement continu

Cette collection de données contient une liste de toutes les demandes de pull/merge qui ont été fusionnées dans les dépôts d'applications depuis le dernier déploiement.

Les données relatives aux demandes d'extraction sont collectées à partir du casier de preuves et du repo de l'incident.

• L'inventaire regroupe les données de toutes les générations sur les artefacts associés depuis le dernier déploiement.
• Le casier de preuves collecte les données d'évaluation par les pairs stockées à partir des générations.
• Le repo d'incidents recueille des informations sur les incidents ouverts de type pull/merge request.

Les référentiels d'applications ne sont pas accessibles durant cette collecte de données. Les pipelines de déploiement continu étant censés se trouver dans des environnements isolés, il n'est pas possible de franchir ces limites.

Contenu des demandes de changement

Les données suivantes sont incluses dans la demande de changement générée automatiquement :

• Liste des incidents liés à des demandes d'extraction ou de fusion qui n'ont pas fait l'objet de mesures correctives. Ces données comprennent les détails de l'actif et l' URL s sur l'incident.

Les incidents liés aux demandes d'extraction/fusion non résolus ont une incidence sur l'état de préparation au déploiement de la demande de changement. Si des incidents de demande d'extraction ou de fusion sont détectés, ils sont considérés comme des vulnérabilités et la demande de changement doit être examinée et approuvée manuellement.

Résolution des incidents de demande d'extraction

Les incidents de demande d'extraction sont considérés comme des vulnérabilités car ils indiquent que du code non vérifié est contenu dans les artefacts publiés. Pour remédier à ces incidents, procédez comme suit :

1. Révisez rétroactivement le changement fusionné.
2. Créez un incident expliquant comment résoudre les éventuels problèmes liés au code.
3. Ajoutez le libellé exempt ou fermez le problème d'incident lié à la demande d'extraction ou de fusion.

L'auteur de la demande d'extraction/fusion et la personne qui clôt la demande d'extraction/fusion ne peuvent pas être la même personne.

Traitement des incidents

Cas n° 1 :

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').

Problèmes connus

• La conformité à l'examen par les pairs dépend de l'inclusion d'une entrée de stock dans l'étape d'édition suivant chaque itération du pipeline d'intégration continue (CI). Si vous ignorez l'inclusion de l'entrée d'inventaire pour toute exécution de pipeline d'EC ayant échoué, les informations collectées d'examen par les pairs pour cette exécution de pipeline d'EC spécifique risquent d'être ignorées dans votre pipeline Continuous Delivery (CD).