Validations incluses dans la demande de changement DevOps

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 7 minutes de lecture

    • Le package d'artefacts DevOps et ses versions d'artefacts associées permettent de déterminer les validations à inclure dans un changement DevOps.

    Les validations sont incluses dans un changement en fonction du type de changement.
    Type de changement Validations incluses
    Manuel Validations à partir des versions d'artefacts du package dans le changement. 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 Exécution de pipeline sont également incluses.
    Automatisé
    • Sans package : toutes les validations des versions d'artefacts sont incluses. Les versions d'artefacts sont celles qui sont liées à l'exécution de pipeline et aux exécutions de tâches associées.
    • Avec package : si l'une des exécutions de tâches en amont du changement comporte l'étape 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 Déploiement de 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.
    • Validations d'exécution : si aucune validation n'est produite à partir des flux avec ou sans package spécifiés 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 spécifiée, la version sémantique est utilisée pour déterminer les validations d'un changement. Le format est (MAJEURE.MINEURE.CORRECTIF). Par exemple, la version sémantique 2.0.1 se lit comme suit :
    • Version majeure 2
    • Version mineure 0
    • Version 1 du correctif/correctif logiciel

    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 de rétablissement : validations dont la valeur du champ Rétablir est définie sur true. Une validation de rétablissement entraîne une validation rétablie 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 Fusionner est définie sur true.
      • 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.
      • Écraser et fusionner : l'écrasement pendant une fusion génère l'arborescence de travail et l'état d'index pour mettre en correspondance une fusion sans créer de validation de fusion. Écraser et fusionner conserve les modifications, mais supprime les validations individuelles de l'historique. Ce type de validation dispose d'une seule validation dont la valeur de fusion est définie sur 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 des changements, avec quatre packages :
      1. Pipeline de version A (version majeure 1)
      2. Pipelines de version A et B (version majeure 1)
      3. Pipelines de version 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 package
    1 A 1.0.0 X
    2 A 1.0.1 ::
    3 A 1.1.0 X
    Remarque :
    La validation 2 (version 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 logiciel.
    Tableau 2. Package 2 (A 1.2.0, B 1.1.0)
    Valider Pipeline de version Version sémantique Inclus dans le package
    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 (version 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 logiciel.
    Tableau 3. Package 3 (B 1.2.0, C 1.0.0)
    Valider Pipeline de version Version sémantique Inclus dans le package
    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. Package 4 (A 1.4.0, B 1.3.0, C 1.2.0)
    Valider Pipeline de version Version sémantique Inclus dans le package
    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 :
    La validation 11 est également incluse dans ce package, car elle fait partie des changements de la version majeure 1 de la version A, car le dernier package (y compris la version majeure 1 de la version A), package 2, a été déployé en production.

    Exemple : logique de calcul des validations

    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.

    Prenez par exemple deux pipelines, l'un sur la branche principale, l'autre sur la branche de test. Scénario d'exécution :

    • Créez une validation C0 sur la branche principale, exécutez une version de CI, mais ne créez pas de version d'artefact.
    • Créez une validation C1 sur la branche de test, exécutez une version de CI, mais ne créez pas de version d'artefact.
    • Créez une validation C2 sur la branche principale, exécutez une version de CI et la version échoue.
    • Créez 2 validations C3, C4 sur la branche principale, exécutez une version de CI et créez une version d'artefact (v1.0).
    Résultat attendu : la version d'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 même cas d'utilisation :
    • Créez une validation C5 sur la branche principale, exécutez une version de CI, mais ne créez pas de version d'artefact.
    • Créez une validation C6 sur la branche principale, exécutez une version de CI et créez une version d'artefact (v2.0).
    Résultat attendu : la nouvelle version d'artefact (v2.0) créée est associée à C5, C6.
    Résumé :
    • Toutes les validations des exécutions de pipelines (ayant réussi et ayant échoué) dans la même branche, entre la dernière version d'artefact d'un artefact donné et la version d'artefact actuelle, 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 pipelines dans la même branche sont associées.

    Poursuivons avec le même cas d'utilisation :

    Créez une mise en production avec la version d'artefact de l'étape précédente, et définissez un pipeline CD avec le type d'étape = Déploiement produit.

    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 d'artefact (v2.0) et valide C0, C2, C3, C4, C5, C6.
    Résumé :
    • Les validations des deux versions d'artefacts (v1.0, v2.0) créées sur la branche principale (aucun package précédent n'a été déployé en production) s'affichent dans la demande de changement, mais pas la validation issue 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.
    Poursuivons avec le même cas d'utilisation :
    • Créez deux validations C7, C8 sur la branche de test, exécutez la version de CI et créez une version d'artefact.

      Résultat attendu : la version d'artefact (v3.0) est associée à C1, C7, C8.

    • Créez deux validations C9, C10 sur la branche principale, exécutez la version de CI et créez une version d'artefact.

      Résultat attendu : la version d'artefact (v4.0) est associée à C9, C10.

    • Créez une mise en production avec la version d'artefact de l'étape précédente (v4.0), créez un pipeline de CD avec le type d'étape = Déploiement produit.
      Résultat attendu :
      • La mise en production est associée à la version d'artefact (v4.0).
      • La demande de changement créée affiche la version d'artefact (v4.0) et valide C9, C10.
    Résumé :
    • La demande de changement affiche les validations uniquement à partir de la dernière version d'artefact créée sur la branche principale, car les validations des versions d'artefact précédentes créées sur la branche principale avaient été déployées en production sur le package précédent.
    • Le nombre de validations indiqué dans la demande de changement sera le même que celui de l'outil.
    • Pour que d’autres types d’étape, tels que Test ou Deploy, utilisent la même logique de validation que Prod Deploy, mettez à jour le champ Contrôle si les autres types d’étapes doivent suivre la même logique que Prod Deploy pour déterminer les validations d’une propriété Change [sn_devops.commit_rel_change_step_type]. Spécifiez quels types d’étape (tels que Déployer et Tester) doivent utiliser la même logique de validation que Déploiement produit comme valeur de propriété. Si ceux-ci sont configurés, le processus de validation de déploiement de produit s’appliquera également à leurs scripts de relation.