Validations incluses dans la DevOps demande de changement

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 7 minutes de lecture

    • 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 basé sur le type de changement.
    Type de changement Validations incluses
    Manuel Validations à partir des versions d’artefacts 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 exécution de plan ou de pipeline sont incluses.
    Automatisé
    • Sans package : Tous les commits des versions de l’artefact sont inclus. Les versions de l’artefact sont celles qui sont liées à l’exécution du pipeline et aux exécutions de tâches pour cette exécution.
    • 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 produit sont incluses. Les validations qui apparaissent dans plusieurs exécutions de pipeline ne sont 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’artefact du package sont incluses.
    • Validations d’exécution : si aucune validation n’est produite à partir de l’un ou l’autre des flux de package spécifié précédemment, les validations d’exécution des exécutions de tâches en amont de la demande de changement sont associées.
    Toutes les validations des versions d’artefacts dans le 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 logiciels 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 1 du correctif/correctif

    Les exécutions de tâches ayant échoué entre la version précédente et la version actuelle de l’artefact qui n’ont pas créé d’artefact, mais qui ont des validations associées sont également associées à 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.
    • Validations d’annulation : validations dont la valeur du champ Rétablir est Vrai. Une validation d’annulation entraîne une validation annulée et une validation d’annulation 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 Vrai.
      • Validation de fusion : 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 sur la branche à fusionner. La validation de fusion ajoute une nouvelle validation sur la branche principale.
      • Squash et fusion : l’écrasement pendant une fusion génère l’arborescence de travail et l’état d’index correspondant à une fusion sans créer de validation de fusion. Squash et Merge conserve les modifications, mais supprime les validations individuelles de l’historique. Il a une seule validation dont la valeur de fusion est true.

    Exemple : validations et packages

    Cet exemple se compose des éléments suivants :
    • Trois pipelines de version (A, B et C)
    • Un pipeline de mise en production (ABC) sous contrôle de changement, avec quatre packages :
      1. Construire le pipeline A (version majeure 1)
      2. Construire les pipelines A et B (version majeure 1)
      3. Construire les pipelines B et C (version majeure 1)
      4. Pipelines de version A, B et C (version majeure 1)
    Tableau 1. Package 1 (A 1.1.0)
    Valider Pipeline de version Version sémantique Inclus dans le forfait
    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.
    Tableau 2. Package 2 (A 1.2.0, B 1.1.0)
    Valider Pipeline de version Version sémantique Inclus dans le forfait
    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 :
    Le commit 4 (build A, version sémantique 1.1.1) n’est pas inclus car la syntaxe de la version sémantique indique un correctif ou un correctif.
    Tableau 3. Package 3 (B 1.2.0, C 1.0.0)
    Valider Pipeline de version Version sémantique Inclus dans le forfait
    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 :
    Le commit 11 (build A, version sémantique 1.3.0) n’est pas inclus car le package ne spécifie pas la build A.
    Tableau 4. Package 4 (A 1.4.0, B 1.3.0, C 1.2.0)
    Valider Pipeline de version Version sémantique Inclus dans le forfait
    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 build A depuis que le dernier package (y compris la version majeure 1 de la build A), 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, considérez deux pipelines, l’un sur la branche principale, l’autre sur la branche test. Scénario d’exécution :

    • Créez un C0 de validation sur principal, exécutez une version de CI, mais ne créez pas de version d’artefact.
    • Créez un C1 de validation lors du test, exécutez la version du CI, mais ne créez pas de version d’artefact.
    • Créez un C2 de validation sur main, exécutez la version CI et la version échoue.
    • Créez 2 validations C3, C4 sur main, 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.
    En poursuivant avec le cas d’utilisation :
    • Créez 1 commit C5 sur le principal, exécutez la version de CI, mais ne créez pas de version d’artefact.
    • Créez 1 commit C6 sur le principal, exécutez la version 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.
    Sommaire :
    • Toutes les validations des exécutions de pipeline (réussites et échecs) dans la même branche, entre la dernière version d’artefact d’un artefact donné et la version actuelle de l’artefact, sont associées.
    • Si aucune version d’artefact précédente n’est trouvée pour l’artefact donné, toutes les validations des exécutions de pipeline dans la même branche sont associées.

    En poursuivant avec le cas d’utilisation :

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

    Résultat attendu :
    • La mise en production est associée à la même version d’artefact (v2.0).
    • La demande de changement créée affiche la version de l’artefact (v2.0) et valide C0, C2, C3, C4, C5, C6.
    Sommaire :
    • Les validations des deux versions d’artefact (v1.0, v2.0) construites sur la branche principale (aucun package précédent n’a été déployé sur Prod) sont affichées dans la demande de changement, mais pas la validation à partir de l’exécution sur la branche de test.
    • Le nombre de validations indiqué dans la demande de changement sera le même que celui de l’outil.
    En poursuivant avec le cas d’utilisation :
    • Créez 2 validations C7, C8 sur la branche de test, exécutez la génération de CI et créez une version d’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 génération de CI et créez une version d’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 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.
    Sommaire :
    • La demande de changement affiche les validations uniquement à partir de la dernière version d’artefact construite sur la branche main, car les validations des versions d’artefact précédentes créées sur main avaient été déployées vers Prod sur le package précédent.
    • Aucune validation de la version de l’artefact générée lors du test n’est affichée.
    • Le nombre de validations indiqué dans la demande de changement sera le même que celui de l’outil.