Change-Anforderungserstellung mit DevOps-Datenabruffehlern

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

Übersicht über die Erstellung von Change-Anforderungen

Hinweis:

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

Sie können eine Change-Anforderung mit oder ohne Fehler beim DevOps-Datenabruf erstellen. Diese Funktionalität kann durch die Eigenschaft Erstellung von Change-Anforderungen auch bei Fehlern im DevOps-Datenabruf aktivieren gesteuert werden. Wenn die Eigenschaft Erstellung von Change-Anforderungen auch bei Fehlern im DevOps-Datenabruf aktivieren aktiviert ist und beim Abrufen von DevOps-Daten wie Arbeitselementen, Commits, Testzusammenfassungen oder Sicherheitszusammenfassungen ein Fehler auftritt, wird die entsprechende Change-Anforderung trotzdem erstellt. Die Daten, die abgerufen werden können, sind weiterhin mit der Change-Anforderung verknüpft. Für die Daten, die nicht abgerufen werden können, wird der Fehlergrund dem Anwender in der Drittanbieterkonsole mitgeteilt, und die gleichen Informationen werden auch im Feld Change-Kommentare im Schrittausführungsdatensatz und in den Change- Arbeitsnotizenhinzugefügt .

Wenn die Eigenschaft Erstellung von Change-Anforderungen auch bei Fehlern in DevOps-Datenabruf aktivieren nicht aktiviert ist, wird eine Change-Anforderung nur erstellt, wenn in keinem Schritt einer Pipeline-Ausführung ein Fehler auftritt. Wenn ein Fehler auftritt, wird die Pipeline abgebrochen, und der Grund für den Fehler wird im Feld Verarbeitungsdetails des eingehenden Ereignisses hinzugefügt. Dasselbe wird dem Benutzer in der Drittanbieterkonsole mitgeteilt.

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

Genehmigung für Change-Anforderungen mit DevOps-Datenabruffehlern

Bei Change-Anforderungen, die mit DevOps-Datenabruffehlern erstellt wurden, wird die Richtlinieneingabe is_change_with_partial_data für alle Change-Genehmigungsrichtlinien auf true festgelegt. 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“ bestimmt die Aktion Is change with partial data, ob ein Change mit Fehlern beim DevOps-Datenabruf 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 gelb angezeigt.

Hinweis:

Wenn Ihre Build-Pipeline (CI) so eingerichtet ist, dass sie eine Release-Pipeline (CD) auslöst, und in der Release-Pipeline ein Change erstellt wird, werden die Daten aus der Build-Pipeline gesammelt 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 Build-Pipeline-Ereignisse erstellt werden. In diesem Fall wird der Change mit DevOps-Daten aus der Build-Pipeline erstellt, auch wenn beim Abrufen einiger Daten ein Fehler auftritt. Sie können dieses Verhalten beobachten, obwohl die Option Erstellung von Change-Anforderungen auch bei Fehlern in der Eigenschaft „DevOps-Datenabruf“ aktiviert ist. Außerdem ist die Richtlinieneingabe is_change_with_partial_data in diesem Fall auf „false“ festgelegt, und der Genehmigungsprozess wird entsprechend der Definition in den Genehmigungs-Flows angewendet, anders als immer manuell bei Change-Anforderungen mit DevOps-Datenabruffehlern.

Timeout für Rückruf

Wenn ein eingehendes Ereignis während einer Pipelineausführung in den Wartestatus wechselt, versucht das System, den Change zu verarbeiten, bis der Zeitüberschreitungswert in der Eigenschaft sn_devops.change _request_callback_timeout überschritten wird. Danach wird die Pipeline abgebrochen. Die Ursache für den Fehler wird in den Konsolenprotokollen Ihres Drittanbietertools angezeigt. Wenn eine Pipeline aufgrund einer Rückruf-Zeitüberschreitung abgebrochen wird, werden die gleichen Informationen im Rückrufdatensatz der entsprechenden Schrittausführung hinzugefügt. Sie können sich an Ihren DevOps-Administrator wenden, um den Zeitüberschreitungswert in der Eigenschaft sn_devops.change_request_callback_timeout zu erhöhen. Der Standardwert dieser Eigenschaft beträgt 120 Minuten, und der Mindestwert beträgt 60 Minuten. Weitere Informationen finden Sie unter DevOps Change-Geschwindigkeit -Eigenschaften.

Hinweis:

Wenn Sie eine anwenderdefinierte Aktion für die GitHub-Change-Automatisierung oder eine anwenderdefinierte Aktion für die GitLab-Docker-Change-Automatisierung in Ihrer entsprechenden Pipeline verwenden, um Change-Anforderungen zu erstellen, müssen Sie das Intervall in der anwenderdefinierten Aktion angeben, damit GitHub oder GitLab den Change-Status von ServiceNow DevOps abfragen kann. Wenn der Change innerhalb des angegebenen Intervalls in ServiceNow einen geeigneten Status erreicht, wird der entsprechende Status abhängig vom Ergebnis des Change an die GitHub- oder GitLab-Pipeline gesendet, die die Pipeline fortsetzt oder abbricht. Weitere Informationen finden Sie unter Anwenderdefinierte ServiceNow DevOps-Aktionen aus dem GitHub-Marketplace und Implementieren Sie anwenderdefinierte Aktionen für Pipelines mit dem generischen Docker-Container-Image. Wenn also Ihre Pipeline mit der anwenderdefinierten Change-Aktion ausgeführt wird und eine der Schrittbenachrichtigungen von GitHub oder GitLab 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 besteht. Gleichzeitig fragt GitHub oder GitLab den Change-Status bei ServiceNow ab, bis die im Intervall angegebene Zeit erreicht ist. Wenn das Intervall verstrichen ist und auch die in der Eigenschaft sn_devops.change_request_callback_timeout angegebene Zeitüberschreitung erreicht ist, beendet ServiceNow DevOps Ihre Pipeline nicht wie vorgesehen, sondern belässt sie bei der im GitHub- oder GitLab-Schritt festgelegten Standard-Zeitüberschreitung, die die Pipeline schließlich beendet. Die wichtige Information in diesem Szenario lautet, dass ServiceNow DevOps den Anwender nicht darüber benachrichtigen kann, dass die Schrittereignisse ServiceNow DevOps in den Protokollen der GitHub- oder GitLab-Konsole nicht erreicht haben.

Upgrade

Nach dem Upgrade wird diese Eigenschaft standardmäßig auf „false“ festgelegt. Ihr aktueller Change-Prozess funktioniert unverändert. Der einzige Unterschied besteht jedoch darin, dass, wenn beim Abrufen von DevOps-Daten ein Fehler auftritt, die Pipeline abgebrochen wird (anstatt unbegrenzt zu warten) und der Grund für den Fehler im eingehenden Ereignis hinzugefügt wird Verarbeitungsdetails, und der Benutzer wird auch in der Drittanbieterkonsole benachrichtigt. Wenn Sie Change-Anforderungen mit Fehlern beim Abrufen von DevOps-Daten erstellen möchten, ohne dass Ihre Pipeline fehlschlägt, können Sie die Eigenschaft Erstellung von Change-Anforderungen auch bei Fehlern in DevOps-Datenabrufen aktivieren aktivieren. Dies bietet Ihren Change-Genehmigern und AppDev-Teams einen Mehrwert, indem die erstellten Changes automatisch mit DevOps-Nachweis erstellt werden, der gesammelt und in den Arbeitsnotizen zu Change-Anforderungen und Protokollen von Drittanbieterkonsolen entsprechend mit Fehlern oder Daten benachrichtigt wird, die möglicherweise fehlen.

Einschränkung

Wenn die Eigenschaft Erstellung von Change-Anforderungen auch bei Fehlern im DevOps-Datenabruf aktivieren aktiviert ist und der Schritt „ADO-Artefaktpaket“ in Ihrer Pipeline zu einem Fehler führt, wird der Change ohne zugeordnete ADO-Artefakte erstellt. Der entsprechende Fehler wird jedoch nicht angezeigt in Arbeitsnotizen oder in den Change-Kommentaren für die Schrittausführung oder im Protokoll der ADO-Konsole.