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

Build-, Release Azure DevOps - Changes oder Pipelines, die in dieser Phase oder Pipeline fehlgeschlagen oder abgebrochen wurden, erneut ausführen oder erneut bereitstellen. Die erneuten Versuche werden in der Pipeline-UI DevOps als kontinuierliche Ausführungen angezeigt, anstatt neue Ausführungen zu erstellen.

Führen Sie Pipelines oder Phasen Azure DevOps erneut aus

Sie können eine fehlgeschlagene oder abgebrochene Build- oder Release-Pipelines erneut ausführen oder Aufträge in Azure DevOpsändern. Die Wiederholungen werden als Teil derselben Pipeline-Ausführung wie die erste Ausführung in ServiceNow DevOpsverarbeitet. Sie können ganze Pipelines oder bestimmte fehlgeschlagene oder abgebrochene Aufgaben und Phasen erneut ausführen. Sie können jetzt eine Change-Anforderung wiederverwenden, anstatt bei jedem Neustart einer Phase oder Pipeline eine neue Change-Anforderung zu erstellen.

Der Nutzlast wird ein Parameter attemptNumber hinzugefügt, mit dem wir Wiederholungen nachverfolgen können. Zugehörige Testzusammenfassung, Ergebnisse von Softwarequalitätsprüfungen, Commits, Arbeitselemente, die jedem Wiederholungsversuch entsprechen, werden auch in ServiceNow DevOpsaktualisiert.

Wenn Sie Change-Steuerung mit der Azure Invoke-REST-API konfigurieren verwenden, müssen Sie Ihrem Nutzlasttext den Parameter für die Versuchsanzahl 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 Versuchsanzahlparameter in Build-Pipeline-Nutzlast:

"attemptNumber": "$(system.jobAttempt)"​

Beispiel für Versuchsanzahlparameter in der Nutzlast der Release-Pipeline:

"attemptNumber": "$(Release.AttemptNumber)"

Hinweis:

Verwenden Sie nicht die vorhandenen gestarteten und abgeschlossenen Benachrichtigungen für die Phasenaufträge. Wenn Ihre Aufträge die Benachrichtigungen „Gestartet“ und „Abgeschlossen“ berücksichtigen, funktioniert die Wiederholungsfunktion nicht.

Wiederverwendung von Change-Anforderungen

Wenn ein Auftrag mit aktivierter Change-Ausführung 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 mithilfe des Basissystems „DevOps – Subflow für Wiederverwendbarkeitsentscheidung für Change-Anforderung“ erstellen. Mit der Standardimplementierung dieses Subflows können Sie eine Change-Anforderung aus dem vorherigen Versuch wiederverwenden, wenn sich die Change-Anforderung im Status „Implementieren“ oder „Nach der Implementierung“ befindet. Wenn sich der Change Request in einem anderen Status befindet (standardmäßig ) , wird ein neuer Change Request erstellt, wenn Sie den Auftrag erneut ausführen. Gemäß dem vorhandenen 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.

Dies kann beispielsweise der Fall sein, wenn eine Pipeline in einer bestimmten Phase nach der Genehmigung der Change-Anforderung fehlschlägt und Sie diese Phase erneut ausführen. Die Change-Anforderung wird wiederverwendet, die zugehörigen Testzusammenfassungs- und Softwarequalitätsprüfungen, 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, Änderungen vornehmen, ihn veröffentlichen und den neuen Subflow-Namen unter aktualisieren DevOps-Eigenschaften > DevOps-Change-Anforderung – Subflow zur Wiederverwendbarkeitsentscheidung.

Im regulären Basissystem-Flow wird beim Erstellen eines Change „DevOps -Flows werden angepasst“ verwendet, um das Feld Statedes Schrittausführungsdatensatzes zu aktualisieren, nachdem eine Entscheidung über die Change-Anforderung getroffen wurde. Wenn Sie jedoch einen Change wiederverwenden, ist die Bedingung des ersten Auslösers, dass die Change-Anforderung erstellt wird, nicht erfüllt. Stattdessen wird der Basissystem-Subflow „DevOps Change Request Reverability Model Subflow“ ausgelöst, wenn eine Change-Anforderung wiederverwendet wird, wenn ein Auftrag erneut ausgeführt wird. Die Standardimplementierung dieses Subflows ähnelt dem Flow DevOps Modell-Change-Anforderung. Sie können einen anwenderdefinierten Subflow erstellen und den Subflow-Namen unter aktualisieren DevOps-Eigenschaften > Subflow des Wiederverwendbarkeitsmodells für DevOps-Change-Anforderungen.

Änderungen an der Pipeline-UI

ServiceNow DevOps synchronisiert alle Änderungen, die verursacht werden, wenn Sie eine Phase oder einen Auftrag neu starten oder erneut ausführen, und zeigt sie in der Pipeline-UI DevOps an.

• Klicken Sie auf eine Karte, um den letzten Versuch dieser Phase anzuzeigen.
• Klicken Sie auf den Link Alle Versuche anzeigen, um alle Schrittausführungen und zugehörigen Informationen anzuzeigen, die dem Schritt oder der Phase zugeordnet sind, der mehrmals ausgeführt wurde.
• Über den Link Change anzeigen wird die Change-Anforderung angezeigt, die dem letzten Versuch zugeordnet ist.

In früheren 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.