Le DevOps package d’artefact et ses versions d’artefacts associées sont utilisés pour déterminer quelles validations sont incluses dans un DevOps changement.

Les validations sont incluses dans un changement en fonction du type de changement.
Type de changement Validations incluses
Manuel Validations à partir des versions d’artefact du package dans le changement. En outre, les validations des exécutions de tâches de toutes les exécutions de pipeline dans l’enregistrement de référence de changement lorsque la colonne data_type est plan ou exécution de pipeline sont incluses.
Automatisé
  • Sans package : toutes les validations des versions de l’artefact sont incluses. Les versions de l’artefact sont celles qui sont liées à l’exécution du pipeline et aux exécutions des tâches pour cette exécution de pipeline.
  • Avec package : si l’une des exécutions de tâches en amont du changement comporte l’étape de déploiement produit, les validations de la dernière exécution réussie du pipeline de déploiement du produit sont incluses. Les validations qui apparaissent dans plusieurs exécutions de pipeline ne seront répertoriées qu’une seule fois. Si l’étape de déploiement du produit n’est pas présente dans les exécutions de tâches en amont, les validations de toutes les versions d’artefacts du package sont incluses.
  • Exécuter des validations : s’il n’y a aucune validation du flux de package avec ou sans comme spécifié précédemment, les validations d’exécution à partir des exécutions de tâches en amont de la demande de changement sont associées.
Toutes les validations des versions d’artefacts du package qui ont été générées après la dernière date de déploiement (jusqu’à la version en cours de déploiement) sont incluses dans la demande de changement. Les versions majeures précédentes ne sont pas incluses.
Remarque : Les versions de correctifs et de correctifs d’urgence sont exclues.
Lorsqu’elle est fournie, la version sémantique est utilisée pour déterminer les validations d’un changement. Le format est (MAJOR. MINEUR. PATCH). Par exemple, la version sémantique 2.0.1 se lit comme suit :
  • Version majeure 2
  • Version mineure 0
  • Version du correctif/correctif logiciel 1

Les échecs d’exécution des tâches entre la version d’artefact précédente et la version actuelle qui n’ont pas créé d’artefact mais qui ont des validations associées sont également associés à la version d’artefact créée.

Types de validations

  • Validations normales : les validations sur le référentiel suivi sont associées à la demande de changement.
  • Rétablir les validations : validations dont la valeur du champ Rétablir est définie sur vrai. Une validation de rétablissement entraîne une validation annulée et une validation de rétablissement dans l’arborescence source. Les deux validations ne sont pas associées à la demande de changement.
  • Validations de fusion : validations dont la valeur du champ de fusion est définie sur vrai.
    • Merge commit : L’arborescence source suit la validation d’une branche au fil du temps et permet d’effectuer une validation de fusion spéciale. Cette validation de fusion combine les validations parentes situées directement après la validation commune la plus récente sur la branche actuelle et la branche à fusionner. La validation de fusion ajoute une nouvelle validation sur la branche principale.
    • Écraser et fusionner : L’écrasement pendant une fusion génère l’arborescence de travail et l’état de l’index pour correspondre à une fusion sans créer de validation de fusion. Écraser et fusionner conserve les changements mais supprime les validations individuelles de l’historique. Il a une seule validation dont la valeur de fusion est vraie.

Exemple : validations et packages

Cet exemple comprend :
  • Trois pipelines de version (A, B et C)
  • Un pipeline de mise en production (ABC) sous contrôle des changements, avec quatre packages :
    1. Pipeline de version A (version majeure 1)
    2. Créer des pipelines A et B (version majeure 1)
    3. Créer des pipelines B et C (version majeure 1)
    4. Créer les pipelines A, B et C (version majeure 1)
Tableau 1. Trousse 1 (A 1.1.0)
Commit Pipeline de version Version sémantique Inclus dans l’emballage
1 A 1.0.0 X
2 A 1.0.1 ::
3 A 1.1.0 X
Remarque : La validation 2 (build A, version sémantique 1.0.1) n’est pas incluse dans le package, car la syntaxe de la version sémantique indique un correctif ou un correctif à chaud.
Tableau 2. Trousse 2 (A 1.2.0, B 1.1.0)
Commit Pipeline de version Version sémantique Inclus dans l’emballage
4 A 1.1.1 ::
5 A 1.2.0 X
6 A 1.2.0 X
7 B 1.0.0 X
8 B 1.0.0 X
9 B 1.1.0 X
10 B 1.1.0 X
Remarque : La validation 4 (build A, version sémantique 1.1.1) n’est pas incluse, car la syntaxe de la version sémantique indique un correctif ou un correctif à chaud.
Tableau 3. Trousse 3 (B 1.2.0, C 1.0.0)
Commit Pipeline de version Version sémantique Inclus dans l’emballage
11 A 1.3.0 ::
12 B 1.2.0 X
13 B 1.2.0 X
14 C 1.0.0 X
15 C 1.0.0 X
16 C 1.0.0 X
Remarque : La validation 11 (version A, version sémantique 1.3.0) n’est pas incluse, car le package ne spécifie pas la version A.
Tableau 4. Trousse 4 (A 1.4.0, B 1.3.0, C 1.2.0)
Commit Pipeline de version Version sémantique Inclus dans l’emballage
17 A 1.4.0 X
18 A 1.4.0 X
19 B 1.3.0 X
20 B 1.3.0 X
21 C 1.1.0 X
22 C 1.1.0 X
23 C 1.2.0 X
24 C 1.2.0 X
Remarque : Le commit 11 est également inclus dans ce package car il fait partie des changements de la version majeure 1 de la version A depuis que le dernier package (y compris la version majeure 1 de la version A), le package #2, a été déployé en production.

Exemple : Valider la logique de calcul

Cas d’utilisation avec la logique de calcul des validations associées aux versions d’artefacts. Les informations de branche sont incluses chaque fois que les validations sont définies.

Par exemple, imaginons deux pipelines, l’un sur la branche principale, l’autre sur la branche de test. Scénario d’exécution :

  • Créez un C0 de validation sur principal, exécutez la version du CI, mais ne créez pas de version de l’artefact.
  • Créez une validation C1 lors du test, exécutez la version du CI, mais ne créez pas de version de l’artefact.
  • Créez un C2 de validation sur principal, exécutez la version du CI et la version échoue.
  • Créez 2 validations C3, C4 sur principale, exécutez une version de CI et créez une version d’artefact (v1.0).
Résultat attendu : La version de l’artefact (v1.0) est associée à C0, C2, C3, C4. La validation C1 est exclue, car elle se trouve sur une branche différente.
Poursuivons avec le cas d’utilisation :
  • Créez 1 Commit C5 sur principal, exécutez la version du CI, mais ne créez pas de version de l’artefact.
  • Créez 1 commit C6 sur main, exécutez la build de CI et créez une version d’artefact (v2.0).
Résultat attendu : La nouvelle version de l’artefact (v2.0) créée est associée à C5, C6.
Résumé :
  • Toutes les validations des exécutions de pipeline (réussies et échouées) dans la même branche, entre la dernière version de l’artefact pour un artefact donné et la version actuelle de l’artefact, sont associées.
  • Si aucune version d’artefact précédente pour l’artefact donné n’est trouvée, toutes les validations des exécutions de pipeline dans la même branche sont associées.

Poursuivons avec le cas d’utilisation :

Créez une mise en production avec la version d’artefact à partir de l’étape précédente, ayez un pipeline CD avec le type d’étape = Prod Deploy.

Résultat attendu :
  • La mise en production est associée à la même version de l’artefact (v2.0).
  • La demande de changement créée affiche la version de l’artefact (v2.0) et les validations C0, C2, C3, C4, C5, C6.
Résumé :
  • Les validations des deux versions d’artefacts (v1.0, v2.0) basées sur la branche principale (aucun package précédent n’a été déployé dans Prod) sont affichées dans la demande de changement, mais pas la validation de l’exécution sur la branche de test.
  • Le nombre de validations indiqué dans la demande de changement est le même que celui de l’outil.
Poursuivons avec le cas d’utilisation :
  • Créez 2 validations C7, C8 sur la branche de test, exécutez la version du CI et créez une version de l’artefact.

    Résultat attendu : La version de l’artefact (v3.0) est associée à C1, C7, C8.

  • Créez 2 validations C9, C10 sur la branche principale, exécutez la version du CI et créez une version de l’artefact.

    Résultat attendu : La version de l’artefact (v4.0) est associée à C9, C10.

  • Créez une mise en production avec la version de l’artefact de l’étape précédente (v4.0), ayez un pipeline de CD avec le type d’étape = Prod Deploy.
    Résultat attendu :
    • La mise en production est associée à la version de l’artefact (v4.0).
    • La demande de changement créée affiche la version de l’artefact (v4.0) et valide C9, C10.
Résumé :
  • La demande de changement affiche uniquement les validations de la dernière version de l’artefact construite sur la branche principale, car les validations des versions précédentes de l’artefact construites sur la branche principale avaient été déployées vers Prod sur le package précédent.
  • Aucune validation de la version de l’artefact construite sur le test n’est affichée.
  • Le nombre de validations indiqué dans la demande de changement est le même que celui de l’outil.