Séquence d’exécution et logique d’attente pour les tâches de réexécution

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 2 minutes de lecture

    • La séquence de traitement et la logique d’attente pour les tâches de réexécution sont différentes lorsque vous réutilisez ou créez une demande de changement dans le cadre d’une tâche de réexécution.

    Considérations existantes

    • Une demande de changement ne doit pas exister dans une étape qui contient des tâches parallèles.
    • Si plusieurs étapes sont exécutées en parallèle, la demande de changement ne doit pas être la première tâche des deux étapes.
    Remarque :
    Les étapes parallèles dans les pipelines de mise en production sont traitées et affichées dans l’interface utilisateur du pipeline au fur et à mesure qu’elles se produisent dans le Azure DevOps pipeline. Les étapes parallèles dans les pipelines de version sont toujours traitées en parallèle, mais apparaissent dans un ordre de série dans l’interface utilisateur du pipeline.

    Considérations relatives à la mise à niveau

    Il n’y a aucun changement dans la fonctionnalité ou l’exécution lorsque vous exécutez la première tentative de pipeline. Toutes les étapes sont traitées séquentiellement et les tests, analyses de la qualité logicielle et demandes de changement associés sont exécutés et créés selon le modèle.
    Remarque :
    • Exécutez un nouveau pipeline après la mise à niveau si vous avez réexécuté des étapes et des pipelines avant la mise à niveau. Les tentatives de réexécution et les événements ayant échoué avant la mise à niveau sont ignorés par ServiceNow DevOps les nouvelles tentatives.
    • Si vous n’avez exécuté le pipeline qu’une seule fois avant la mise à niveau, vous pouvez réexécuter l’étape ou le pipeline. La fonctionnalité de réexécution s’applique telle qu’elle a été conçue et est enregistrée dans ServiceNow DevOps.

    Séquence d’exécution et logique de traitement

    • Si le même appel d’inscription de version d’artefact est reçu lors de la nouvelle tentative, l’appel d’inscription est ignoré.
    • Les appels d’enregistrement de package portant le même nom de package ne sont pas ignorés. Un nouveau package associé aux versions d’artefacts et à l’exécution du pipeline est créé lors de la nouvelle tentative. Les artefacts associés au dernier package s’afficheront dans la demande de changement.

    À partir de l’interface Azure DevOps graphique, si vous réexécutez une étape dans un pipeline de version, les réexécutions des étapes suivantes sont également déclenchées dans l’ordre spécifié. Si vous tentez à nouveau de traiter un pipeline avant que toutes les étapes de la tentative précédente ne soient pas terminées. La tentative suivante attend que tous les événements de la tentative précédente soient traités.

    Pour les pipelines de mise en production, les étapes ne sont exécutées dans l’ordre spécifié que lors de la première exécution. Pour les tentatives de réexécution suivantes, exécutez manuellement chaque étape. Dans les pipelines de mise en production, même si les étapes s’exécutent en parallèle dans , à Azure DevOpspartir de la deuxième tentative, les événements sont traités dans l’ordre spécifié.

    • Lorsqu’une nouvelle demande de changement est créée pour une tâche d’étape de nouvelle tentative et que l’étape que vous tentez à nouveau inclut un test et une analyse de la qualité logicielle, seuls les derniers résultats de la synthèse du test et de l’analyse de la qualité logicielle s’affichent dans la liste connexe Demande de changement.
    • Lorsqu’une demande de changement est réutilisée pour une tâche d’étape de réexécution, les résultats du résumé du test et de l’analyse de la qualité logicielle pour chaque tentative s’affichent dans la liste connexe demande de changement.