Fehlgeschlagene Build- oder Release-Pipeline-Aufträge und -Phasen werden neu gestartet

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 3 Minuten Lesedauer
  • Erneut ausführen oder erneut bereitstellen Azure DevOps Build-, Release-Changes oder Pipelines, die in dieser Phase oder Pipeline fehlgeschlagen oder abgebrochen wurden. Die Wiederholungsversuche werden im angezeigt DevOps Pipeline-UI als kontinuierliche Ausführung anstatt neue Ausführungen zu erstellen.

    Erneut Ausführen Azure DevOps Pipelines oder Phasen

    Sie können eine fehlgeschlagene oder abgebrochene Build- oder Release-Pipelines oder Change-Aufträge in erneut ausführen Azure DevOps. Die Wiederholungen werden als Teil derselben Pipeline-Ausführung wie die erste Ausführung in verarbeitet ServiceNow DevOps. Sie können ganze Pipelines oder bestimmte fehlgeschlagene oder abgebrochene Aufträge und Phasen erneut ausführen. Sie können jetzt eine Change-Anforderung wiederverwenden, anstatt jedes Mal, wenn Sie eine Phase oder Pipeline neu starten, eine neue Change-Anforderung zu erstellen.

    Ein attemptNumberDer Parameter wird der Nutzlast hinzugefügt, der uns hilft, Wiederholungen nachzuverfolgen. Zugehörige Testzusammenfassung, Ergebnisse des Softwarequalitätsprüfens, Commits , Arbeitselemente, die jedem Wiederholungsversuch entsprechen, werden auch in aktualisiert ServiceNow DevOps.

    Wenn Sie verwenden Konfigurieren der Change-Steuerung mit der Azure-REST-API aufrufen Sie müssen Ihrem Nutzlasttext den Parameter „Versuchsnummer“ im angegebenen Syntaxformat für Build- und Release-Pipelines hinzufügen. Wenn Sie den Parameter für die Versuchsanzahl nicht angeben, wird die Standardversuchsanzahl auf 1 festgelegt.

    Beispiel für den Versuchsnummernparameter in der Pipeline-Build-Nutzlast:
    "attemptNumber": "$(system.jobAttempt)"​
    Beispiel für den Versuchsnummernparameter in der Nutzlast der Release-Pipeline:
    "attemptNumber": "$(Release.AttemptNumber)"
    Hinweis:
    Verwenden Sie nicht die vorhandenen Benachrichtigungen „gestartet“ und „Abgeschlossen“ für die Phasenaufträge. Wenn Ihre Aufgaben die Benachrichtigungen „gestartet“ und „Abgeschlossen“ berücksichtigen, funktioniert die Funktion „erneute Ausführung“ nicht.

    Change-Anforderungen Werden Wiederverwendet

    Wenn ein Change-fähiger Auftrag erneut ausgeführt wird und für die vorherige Ausführung/den vorherigen Versuch eine Change-Anforderung vorhanden ist, können Sie die vorherige Change-Anforderung wiederverwenden oder eine neue Change-Anforderung erstellen. Verwenden Sie dazu den Basissystem „DevOps Change Request – Wiederverwendbarkeitsentscheidung“. Die Standardimplementierung dieses Subflows ermöglicht es Ihnen, eine Change-Anforderung aus dem vorherigen Versuch wiederzuverwenden, wenn sich die Change-Anforderung im status „Implementieren“ oder „nach der Implementierung“ befindet. Wenn sich die Change-Anforderung in einem anderen Status befindet, Standardmäßig wird eine neue Change-Anforderung erstellt, wenn Sie den Auftrag erneut ausführen. Nach vorhandenem Verhalten werden alle zugehörigen Details wie Testzusammenfassungen und Scans neu generiert, während Commits und Arbeitselemente für neue Change-Anforderungen unverändert beibehalten werden.

    Beispiel: Wenn eine Pipeline in einer bestimmten Phase fehlschlägt, nachdem die Change-Anforderung genehmigt wurde, und Sie diese Phase erneut ausführen. Die Change-Anforderung wird wiederverwendet, die zugehörige Testzusammenfassung und Softwarequalitätsscans, und die Commits und Arbeitselemente, die dem Artefakt zugeordnet sind, sind derselben Change-Anforderung zugeordnet, die Sie genehmigt haben.

    Um eine anwenderdefinierte Logik für die Wiederverwendbarkeit anzuwenden, können Sie den vorhandenen Subflow kopieren, die Änderungen vornehmen, veröffentlichen und den neuen Subflow-Namen unter aktualisieren DevOps-Eigenschaften > DevOps-Change-Anforderung – Subflow für Wiederverwendbarkeitsentscheidungan.

    Im regulären Basissystem-Flow, wenn ein Change erstellt wird, „ using-dev-ops-model-change-flow.html„ Wird zum Aktualisieren von verwendet  State Feld des Schrittausführungsdatensatzes, nachdem eine Entscheidung über die Change-Anforderung getroffen wurde. Wenn Sie jedoch einen Change wiederverwenden, ist die erste Auslöserbedingung einer Change-Anforderung, die erstellt wird, nicht erfüllt. Ein Basissystem-Subflow Stattdessen wird „Subflow für DevOps-Change-Anforderung – Wiederverwendbarkeitsmodell“ ausgelöst, wenn eine Change-Anforderung wiederverwendet wird, wenn ein Auftrag erneut ausgeführt wird. Die Standardimplementierung dieses Subflows ähnelt der DevOps Flow der Modell-Change-Anforderung. Sie können Erstellen Sie einen anwenderdefinierten Subflow, und aktualisieren Sie den Subflow-Namen unter DevOps-Eigenschaften > DevOps-Change-Anforderung – Wiederverwendbarkeitsmodell-Subflowan.

    Pipeline-UI-Changes

    ServiceNow DevOps Synchronisiert alle Änderungen, die beim Neustart oder erneuten Ausführen einer Phase oder eines Auftrags verursacht werden, und zeigt sie im an DevOps Pipeline-UI.
    • Klicken Sie auf eine Karte, um den letzten Versuch dieser Phase anzuzeigen.
    • Klicken Sie auf Zeigen Sie alle Versuche an Link zum Anzeigen aller Schrittausführungen und zugehörigen Informationen, die dem Schritt oder der Phase zugeordnet sind, der mehrmals ausgeführt wird.
    • Der Link Change anzeigen zeigt die Change-Anforderung an, die dem letzten Versuch zugeordnet ist.
    In vorherigen Releases wurden fehlgeschlagene Aufträge entweder ignoriert, oder es wurde ein neuer Pipeline-Ausführungsauftrag für Wiederholungen erstellt und entsprechend verarbeitet. Weitere Informationen finden Sie unter DevOps Pipeline-UI.