Erstellung von Change-Anforderungen mit DevOps-Datenabruffehlern

Erstellen Sie Change-Anforderungen auch mit Fehlern beim DevOps-Datenabruf.

Übersicht über die Erstellung von Change-Anforderungen

Hinweis:

Die Erstellung von Change-Anforderungen mit DevOps-Datenabruffehlern wird nur für unterstützt Azure DevOps, GitHub Actions, GitLab, Jenkins, Und Kabelbaum-Pipelines.

Sie können eine Change-Anforderung mit oder ohne Fehler beim DevOps-Datenabruf erstellen. Diese Funktionalität kann von gesteuert werden Aktivieren Sie die Erstellung von Change-Anforderungen auch bei Fehlern beim DevOps-Datenabruf Eigenschaft. Wenn Aktivieren Sie die Erstellung von Change-Anforderungen auch bei Fehlern beim DevOps-Datenabruf Eigenschaft ist aktiviert, und beim Abrufen von DevOps-Daten wie Arbeitselementen, Commits, Testzusammenfassungen oder Sicherheitszusammenfassungen tritt ein Fehler auf. Die entsprechende Change-Anforderung wird weiterhin erstellt. Die Daten, die abgerufen werden können, werden weiterhin der Change-Anforderung zugeordnet. Für die Daten, die nicht abgerufen werden können, wird der Grund für den Fehler in der Drittparteikonsole benachrichtigt, und dieselben Informationen werden auch in hinzugefügt Change-Kommentare Feld im Schrittausführungsdatensatz und im Change Arbeitsnotizen .

Wenn Aktivieren Sie die Erstellung von Change-Anforderungen auch bei Fehlern beim DevOps-Datenabruf Eigenschaft ist nicht aktiviert. Eine Change-Anforderung wird nur erstellt, wenn in einem Schritt einer Pipeline-Ausführung kein Fehler auftritt. Wenn ein Fehler auftritt, wird die Pipeline abgebrochen, und der Grund für den Fehler wird dem eingehenden Ereignis hinzugefügt Verarbeitungsdetails Und wird dem Anwender in der Drittparteikonsole benachrichtigt.

Weitere Informationen finden Sie unter DevOps Change-Geschwindigkeit -Eigenschaften.

Genehmigung für Change-Anforderungen mit DevOps-Datenabruffehlern

Für Change-Anforderungen, die mit DevOps-Datenabruffehlern erstellt wurden, die is_change_with_partial_dataRichtlinieneingabe ist auf festgelegt Wahr Für alle Change-Genehmigungsrichtlinien. Auf solche Changes wird nur eine manuelle Change-Genehmigungsentscheidung angewendet, sodass Sie den Change genehmigen oder ablehnen können, nachdem Sie die darin enthaltenen DevOps-Daten manuell überprüft haben. Im Subflow DevOps – Change-Richtliniendaten erfassen – die Is change with partial dataDie Aktion bestimmt, ob ein Change mit DevOps-Datenabruffehlern erstellt wird oder nicht.

Pipeline-UI für Change-Anforderungen mit DevOps-Datenabruffehlern

Wenn eine Change-Anforderung mit DevOps-Datenabruffehlern erstellt wird, wird die Karte, die die Phase angibt, in der der Fehler aufgetreten ist, in der Farbe Gelb angezeigt.

Hinweis:

Wenn Ihre Build-Pipeline (CI) so eingerichtet ist, dass sie eine Release-Pipeline (CD) auslöst, und ein Change in der Release-Pipeline erstellt wird, werden die Daten aus der Build-Pipeline erfasst und der Change-Anforderung zugeordnet. Es kann eine Situation geben, in der ServiceNow DevOps Change-Geschwindigkeit die Release-Pipeline-Ereignisse empfängt und verarbeitet, bevor Pipeline-Ereignisse erstellt werden. In diesem Fall wird der Change mit DevOps-Daten aus der Build-Pipeline erstellt, auch wenn beim Abrufen einiger der Daten ein Fehler auftritt. Sie können dieses Verhalten auch über beobachten Aktivieren Sie die Erstellung von Change-Anforderungen auch bei Fehlern beim DevOps-Datenabruf Eigenschaft ist aktiviert. Auch die is_change_with_partial_dataDie Richtlinieneingabe ist in diesem Fall falsch, und der Genehmigungsprozess wird so angewendet, wie er in den Genehmigungs-Flows definiert ist, im Gegensatz zu immer manuell, wenn Change-Anforderungen mit DevOps-Datenabruffehlern auftreten.

Rückruf-Zeitüberschreitung

Wenn ein eingehendes Ereignis während einer Pipeline in den Status „Warten“ versetzt wird, versucht das System, den Change bis zum Zeitüberschreitungswert in zu verarbeiten sn_devops.change _request_callback_timeoutEigenschaft wird überschritten, danach wird die Pipeline abgebrochen. Der Grund für den Fehler wird in den Konsolenprotokollen Ihres Drittanbietertools angezeigt. Wenn eine Pipeline aufgrund einer Rückruf-Zeitüberschreitung abgebrochen wird, werden dieselben Informationen im Rückruf-Datensatz der entsprechenden Schrittausführung hinzugefügt. Sie können sich an Ihren DevOps-Administrator wenden, um den Zeitüberschreitungswert in zu erhöhen sn_devops.change_request_callback_timeoutEigenschaft. Der Standardwert dieser Eigenschaft beträgt 120 Minuten, der Mindestwert 60 Minuten. Weitere Informationen finden Sie unter DevOps Change-Geschwindigkeit -Eigenschaften.

Hinweis:

Wenn Sie die anwenderdefinierte Aktion „GitHub-Change-Automatisierung“, die anwenderdefinierte Aktion „GitLab Docker-Change-Automatisierung“ verwenden oder die anwenderdefinierte Aktion „Docker-Change-Automatisierung“ in Ihrer entsprechenden Pipeline nutzen, um Change-Anforderungen zu erstellen, müssen Sie angeben Intervall In der anwenderdefinierten Aktion, mit der GitHub, GitLab oder Harness ServiceNow DevOps nach dem Change-Status abfragen können. Wenn der Change innerhalb des angegebenen Intervalls einen entsprechenden Status in ServiceNow erreicht, wird der entsprechende Status abhängig vom Ergebnis des Change an GitHub, GitLab oder Harness-Pipeline gesendet, wodurch die Pipeline fortgesetzt oder abgebrochen wird. Siehe Anwenderdefinierte ServiceNow DevOps-Aktionen aus GitHub Marketplace Und Implementieren Sie anwenderdefinierte Aktionen für Pipelines mit einem generischen Docker-Container-Image Für weitere Details. Wenn also Ihre Pipeline mit der anwenderdefinierten Change-Aktion ausgeführt wird und eine der Schrittnachrichten von GitHub, GitLab oder Harness ServiceNow DevOps nicht erreicht hat, erfolgt die Zuordnung von Rückruf, Schrittausführung und Aufgabenausführung in ServiceNow DevOps nicht. Da die Zuordnung nicht verfügbar ist, wird der Change nicht erstellt, und ServiceNow DevOps wartet, bis die Zuordnung vorhanden ist. Gleichzeitig fragt GitHub, GitLab oder Harness ServiceNow nach dem Change-Status ab, bis die im Intervall angegebene Zeit erreicht ist. Wenn das Intervall überschritten wird, und auch die in angegebene Zeitüberschreitung sn_devops.change_request_callback_timeoutEigenschaft ist erreicht. ServiceNow DevOps beendet Ihre Pipeline nicht wie vorgesehen, behält sie jedoch für die im GitHub-, GitLab- oder Harness-Schritt festgelegte Standardzeitüberschreitung bei, wodurch die Pipeline schließlich beendet wird. Die wichtigen Informationen in diesem Szenario sind, dass ServiceNow DevOps den Anwender nicht benachrichtigen kann, dass die Schrittereignisse ServiceNow DevOps in den GitHub-, GitLab- oder Harness-Konsolenprotokollen nicht erreicht haben.

Upgrade

Nach dem Upgrade wird die Eigenschaft standardmäßig auf „falsch“ festgelegt. Ihr aktueller Change-Prozess funktioniert unverändert, aber der einzige Unterschied, den Sie sehen, besteht darin, dass bei einem Fehler beim Abrufen von DevOps-Daten die Pipeline abgebrochen wird (anstatt unbegrenzt zu warten) und der Grund für den Fehler im eingehenden Ereignis hinzugefügt wird Verarbeitungsdetails Und wird dem Anwender in der Drittparteikonsole benachrichtigt. Wenn Sie Change-Anforderungen mit Fehlern beim Abrufen von DevOps-Daten erstellen und auch Ihre Pipeline nicht fehlschlagen möchten, können Sie aktivieren Aktivieren Sie die Erstellung von Change-Anforderungen auch bei Fehlern beim DevOps-Datenabruf Eigenschaft. Dies bietet Ihren Change-Genehmigern und AppDev-Teams einen Mehrwert, indem die Changes automatisch mit DevOps-Nachweisen erstellt werden, die in den Arbeitsnotizen der Change-Anforderung und in den Protokollen der Drittpartei-Konsole mit Fehlern oder Daten, die möglicherweise fehlen, gesammelt und entsprechend benachrichtigt werden.

Einschränkung

Wenn Aktivieren Sie die Erstellung von Change-Anforderungen auch bei Fehlern beim DevOps-Datenabruf Die Eigenschaft ist aktiviert, und der ADO-Artefaktpaketschritt in Ihrer Pipeline führt zu einem Fehler. Der Change wird ohne zugeordnete ADO-Artefakte erstellt, der entsprechende Fehler wird jedoch nicht in Arbeitsnotizen, in Kommentaren zur Schrittausführung oder im ADO-Konsolenprotokoll benachrichtigt.