DevOps Versionshinweise zum Datenmodell

Neu:
- Unterstützung für proaktive Integritätsprüfungen
  - Erkennen Sie Anomalien und Probleme in Ihrer DevOps-Change-Geschwindigkeitsinstanz mithilfe einer Reihe proaktiver Prüfungen. Diese Prüfungen können Ihnen helfen, Probleme zu identifizieren, die in der Produktbenutzeroberfläche nicht sichtbar sind, aber durch Tabellenscans leicht erkannt werden können. Je nach Art der Prüfung sind sie entweder geplant oder bei Bedarf.
- Nutzen Sie die Tool-Integration mit ServiceNow
  - Integrieren Sie das Orchestration-Tool Kabelbaum mit DevOps Change-Geschwindigkeit. Mit dieser Integration können Sie in ServiceNow für Kabelbäume eine Verbindung herstellen, erkennen, importieren, Echtzeitereignisse verarbeiten und CI/CD mit Change integrieren.
Geändert:
- Vereinfachtes Onboarding von Orchestration-Tools, die im Basissystem nicht unterstützt werden
  - Das vereinfachte generische Framework bietet Ihnen eine einfach zu verwendende Lösung für die Integration benutzerdefinierter Orchestration-Tools mit ServiceNow DevOps Change-Geschwindigkeit, die minimale Kenntnisse der Plattform erfordert. Es reduziert die Komplexität der Integration, indem es den Umfang der erforderlichen benutzerdefinierten Codierung reduziert und den Gesamtprozess für Kunden und Partner vereinfacht. Durch die Optimierung des Onboardings neuer Orchestration-Tools ermöglicht das -Framework eine schnellere Einführung, eine reibungslosere Skalierung und ein einfacheres Onboarding zusätzlicher Teams. Dadurch entstehen bei der Integration weniger Herausforderungen, die Benutzerakzeptanz wird beschleunigt, und der Übergang wird reibungsloser ausgeführt. Dieses generische Framework unterstützt die Integration jedes Orchestration-Tools, das von ServiceNow nicht nativ unterstützt wird, im Basissystem.
- Anwenderdefinierte Felder für die Integration des Planungstools
  - Integrieren Sie zusätzliche anwenderdefinierte Felder für Arbeitselemente, und profitieren Sie dadurch von einer verbesserten Konfigurierbarkeit der im Basissystem von DevOps Change-Geschwindigkeit unterstützten Planungstools.

Neu:
- OAuth 2.0-Authentifizierung für Azure DevOps (ADO)
  - Verwenden Sie die OAuth 2.0-Authentifizierung, um Ihr Azure DevOps-Tool mit DevOps Change-Geschwindigkeit zu verbinden und so eine sichere Authentifizierungsmethode zu schaffen.
- OAuth 2.0-Authentifizierung für Jira Cloud
  - Verwenden Sie die OAuth 2.0-Authentifizierung, um Ihr Jira Cloud-Tool mit DevOps Change-Geschwindigkeit zu verbinden und so eine sicherere Authentifizierungsmethode zu gewährleisten.
Geändert:
- Generalisierte Docker-Containerlösung zur Unterstützung jedes Orchestration-Tools
  - Verwenden Sie die verallgemeinerte und erweiterbare Docker-Container-Lösung, um jedes Orchestration-Tool mit DevOps Change-Geschwindigkeit zu integrieren und Pipeline-Aktionen wie die Erstellung von Change-Anforderungen und das Sammeln relevanter DevOps-Daten aufzurufen, ohne auf Tool-spezifische Plugins oder Erweiterungen angewiesen zu sein.
- Vereinfachtes Onboarding von Planungstools, die im Basissystem nicht unterstützt werden
  - Integrieren Sie Planungstools, die im Basissystem nicht unterstützt werden, mithilfe von Transformatorregeln. GitLab-Probleme sind jetzt als eines der Planungstools verfügbar und werden mit diesem neuen Ansatz entwickelt, sodass Sie in GitLab Pläne erkennen, Arbeitselemente importieren und Webhooks für Arbeitselemente (Probleme) konfigurieren können.
- Verbesserte Experience bei der manuellen Erstellung von DevOps-Changes durch direkte Aktivierung der Zuordnung von Arbeitselementen
  - Fügen Sie in Service Operations-Arbeitsbereich für ITSM Arbeitselementdaten in einer manuell erstellten DevOps-Change-Anforderung hinzu.

Das DevOps-Datenmodell wurde verbessert, um die folgenden DevOps Change-Geschwindigkeitsfunktionen zu unterstützen:
- Geändert:
  - Verbesserter Weg zur vollständigen Change-Automatisierung mithilfe von Modellen.
  - Support-Wiederholungen mit GitHub-Aktion.
  - Unterstützen Sie API_KEY für Jira Server.
  - Behalten Sie Verzweigungsdetails in der Pipeline-Ausführung bei, um Commits aus Artefakten und Paketen zu bestimmen.
- Entfernt:
  - Change-Aufgaben werden nicht mehr automatisch erstellt, damit der Flow Change – DevOps-Implementierung des DevOps-Modells besser für DevOps-Changes geeignet ist.
  - Die Flows für die Genehmigung von DevOps-Change-Anforderungen für minimale Automatisierung und für die Genehmigung von DevOps-Change-Anforderungen für erweiterte Automatisierung werden für DevOps-Change-Anforderungen nicht ausgelöst, deren Modell ein DevOps-Change-Modell des Basissystems (DevOpsorDevOpssimplified) ist, um Konflikte und Fehler zu vermeiden.
- Hinweis: Ausführliche Informationen zu den Funktionen finden Sie in den Versionshinweisen zu DevOps Change-Geschwindigkeit.

Geändert:
- Das DevOps-Datenmodell wurde verbessert, um die folgenden DevOps Change-Geschwindigkeitsfunktionen zu unterstützen:
  - Unterstützung für die Integration eines anwenderdefinierten Orchestration-Tools
  - Verbesserte Behandlung von Onboarding-Fehlern und Schutzmaßnahmen
  - Lassen Sie die Erstellung von Change-Anforderungen auch bei Fehlern beim DevOps-Datenabruf zu
  - Support für GitLab-Merge-/Pull-Anforderung
  - JFrog Artifactory-Unterstützung für GitHub Actions, Azure DevOps und GitLab
  - Unterstützung für Jira Cloud
  - Unterstützt mehrere ServiceNow DevOps-Konfigurationen in derselben Jenkins-Instanz
  - Verbesserungen des GitLab-Docker-Containers

Neu:
- Integration mit GitHub-Problemen
  - GitHub unterstützt jetzt zusätzlich zu den Code- und Orchestration-Fähigkeiten die Fähigkeit Planen mit Integration von GitHub-Problemen. GitHub-Probleme des Repositorys können auch erkannt und mit den GitHub-Commits verknüpft und im ServiceNow DevOps CHG beibehalten werden, das für Richtlinienentscheidungen der ServiceNow DevOps CHG-Beschleunigung verwendet werden kann.
- Unterstützt verschiedene Arten von Komponententests für GitHub-Aktionen
  - Veröffentlichen Sie Testergebnisse verschiedener Komponententest-Toolberichte wie NUnit, Pytest, Jest, JUnit, XUnit automatisch ohne anwenderdefinierte API-Aufrufe, um sie im ServiceNow DevOps-CHG zu veröffentlichen.
- Experience der geführten Change-Automatisierung
  - Sie erhalten jetzt bessere produktinterne Anleitungen zu den verschiedenen Möglichkeiten zur Nutzung von DevOps-Changes und zur einfachen Übernahme von DevOps-Changes, ohne den Change-Prozess vollständig zu unterbrechen. Ein Stepper führt Sie durch die Automatisierung der Erstellung von DevOps-Changes. Sie können den Verbindungsstatus eines Tools überprüfen, während Sie eine Pipeline auf dem Stepper auswählen, und Sie werden auch benachrichtigt, bevor Sie mit dem nächsten Schritt fortfahren. Zwei neue Statusübergangs-Flows: „Change – DevOps – Neu“ und „Change – DevOps-Zeitplan“ für das DevOps-Change-Modell werden eingeführt, um Changes durch diese Status zu verschieben und zu verfolgen. Das Skript „DevOpsChangeRelationshipHelper“ wurde eingeführt, um Daten abzurufen, die einer Change-Anforderung zugeordnet sind, basierend auf dem angegebenen Beziehungstyp.
- Umgang mit Quotenbegrenzungen für Azure DevOps- und GitHub-API
  - Wenn die Azure DevOps- oder GitHub-API-Quotengrenzwerte überschritten werden, verzögert DevOps Change-Geschwindigkeit die Verarbeitung neuer Ereignisse, bis die GitHub-Drosselung nachgelassen hat, um große Datenmengen zu verarbeiten.
- Unterstützt Paginierung in Discover-Importanforderungen für Pipelines, Repositorys und Pläne für Azure DevOps und GitHub
  - Daten werden jetzt stapelweise (paginiert) von Drittanbieter-Tools abgerufen. Dies wird Ihnen bei der Skalierung helfen, indem Sie viele Teams mit großen Datenmengen einarbeiten.
- - Entfernung der Rollen „Verbindungsadministrator“ und „Flow Designer“ für DevOps-Administrator und Toolbesitzer
    - Die Sichtbarkeit und die Bearbeitungsfunktionen von DevOps-Administratoren und Toolbesitzern wurden eingeschränkt, indem die Rollen „Flow Designer“ und „Verbindungsadministrator“ für diese Anwender entfernt wurden.
- Änderungen an Artefakten und Paketen
  - Die allgemeine Experience bei der Einführung, Implementierung und Fehlerbehandlung für Artefakte und Pakete wurde verbessert. Die Artefakt- und Paketregistrierungs-API für Jenkins und ADO bietet jetzt in der Antwort eindeutige Nachrichten zum Status. Benutzer können sehen, ob die Artefaktversion bereits vorhanden, bereitgestellt oder erstellt ist, und im Falle einer Ablehnung den Grund anzeigen. In der Konsole ist eine eindeutige Meldung zusammen mit einem Link zum Navigieren zur Artefaktseite verfügbar. Die DevOpsDPRHelper-API akzeptiert jetzt Pipeline-Ausführungen als Eingabe, um Daten zu Schwachstellen, Testergebnissen und Codeabdeckung abzurufen. Die Experience bei der Problembehandlung wurde durch eine zusätzliche Beschreibungsspalte verbessert, in der erläutert wird, warum eine Artefaktversion oder ein Paket aussteht. Ein neues Listenmodul, das die Listen „Artefakt“, „Paket“ und „Ausstehende Pakete“ enthält, wurde erstellt, um den Zugriff auf diese Informationen im DevOps-Change-Arbeitsbereich zu erleichtern.
- Verbesserungen bei der Verarbeitung von GitLab-Benachrichtigungen
  - Die Skalierbarkeit wurde durch die nahtlose Verarbeitung von GitLab-Ereignissen verbessert. Die Vorfilterung für die eingehenden Ereignisse wurde eingeführt, um die Anzahl der Flow-Ereignisse und API-Aufrufe zu reduzieren. Die Unterstützung für die Drosselung der Quotenbegrenzung wurde für die Flows „Erkennen“ und „Import“ zusammen mit Webhook-Ereignissen aktiviert. GitLab-Subflows wie die GitLab-CI-Benachrichtigung wurden neu gestaltet, um Störungen bei der Nachverfolgung des Wartestatus zu reduzieren. Dadurch wurde die Anzahl der REST-Aufrufe zum Abrufen von Projektinformationen optimiert.
- Änderungen an der SonarQube-Integration
  - Der allgemeine SonarQube-Quality-Gate-Status für die Scan-Zusammenfassung wird jetzt unterstützt, und die SonarQube-Integration mit GitLab-Pipelines wird auch mit dem ServiceNow DevOps Gitlab Docker Container unterstützt.

Neu:
- Automatische Aktualisierung des Abschlusscodes basierend auf dem Gesamtstatus der Pipeline-Ausführung
  - >Der aus einer Pipeline erstellte Change wird jetzt automatisch geschlossen und mit den Abschlussnotizen sowie der tatsächlichen Start-/Endzeit basierend auf dem Gesamtabschlussstatus der Pipeline aktualisiert. Dies wird durch eine Konfigurationskennzeichnung gesteuert, die als Attribut im CHG-Erstellungsschritt oder über die Konfiguration auf Pipeline-Ebene in DevOps Change-Geschwindigkeit übergeben werden kann.
- Toolverbindung und Konfigurationsstatus
  - Für Jenkins, GitHub und Azure DevOps werden die Statusindikatoren für Verbindungen und Konfigurationen aktualisiert. Sie können auch die Toolverbindungen einfach testen. Der Gesamtstatus des Tools wird jetzt basierend auf dem Status von Verbindungsstatus, Tool-Anmeldeinformationen, Berechtigungsprüfung, Webhook-Konfigurationsstatus als „Verbunden“, „Nicht verbunden“, „Handlungsbedarf“ aktualisiert.
- Unterstützt verschiedene Arten von Komponententests für Azure DevOps (ADO)
  - Veröffentlichen Sie Testergebnisse verschiedener Testtool-Berichte wie NUnit, Pytest, Jest, JUnit, XUnit automatisch ohne anwenderdefinierte API-Aufrufe, um sie im DevOps-CHG zu veröffentlichen.
- Unterstützung für Pull Request (PR)/Merge Request für Azure DevOps (ADO)
  - Ausführungen der ADO-Abrufanforderungs-Pipeline werden jetzt in DevOps Change-Geschwindigkeit nachverfolgt, und die folgenden Metadaten werden in CHG veröffentlicht: Abrufanforderungs-ID, Commits, Ursprungsverzweigung, Zielverzweigung, Ausgelöst von, Genehmiger, Kommentare, ausgelöste PR-Zeit, PR-Genehmigungszeit, PR Zusammenführungs-/Schließungszeit.
- Umgang mit der Quotenbegrenzung der GitHub-API
  - Wenn die GitHub-API-Quotengrenzwerte überschritten werden, verzögert DevOps Change-Geschwindigkeit die Verarbeitung neuer Ereignisse, bis die GitHub-Drosselung nachgelassen hat. Dadurch wird die Gesamtleistung bei großen Datenmengen erhöht.
- Checkmarx-Support
  - >Verbinden Sie Checkmarx, das in Ihre CI/CD-Pipelines integriert ist, mit DevOps Change-Geschwindigkeit, um Ergebnisse von Sicherheitsscans abzurufen. Dies hilft Ihnen zu bestimmen, wie angreifbar Ihr Code ist. Checkmarx-Scans, die in GitHub Actions-, Jenkins- und Azure DevOps-Pipelines konfiguriert sind, werden im Basissystem unterstützt. Sie können die Ergebnisse von Sicherheitsscans entweder in der zugehörigen Liste einer Change-Anforderung oder der Aufgabenausführung der Pipeline in Ihrer ServiceNow-Instanz oder in der Pipeline-UI anzeigen. Sie können Sicherheitsergebnisse verwenden, um Change-Richtlinien und Bedingungen für die Change-Automatisierung zu definieren. Sowohl Checkmarx One als auch Checkmarx SAST werden unterstützt.
- Änderungen der Unterstützung für mehrere Modelle
  - Migrieren Sie alle Ihre vorhandenen Pipelines zu -Modellen, indem Sie den Katalog für die DevOps-Pipeline-Migration zu Change-Modellen verwenden. Darüber hinaus können Sie die Change-Modelle nach Namen aus Ihren Orchestration-Tool-Pipelines übergeben.
Behoben:
- Wenn mehr als 20 Pipelines vorhanden waren, blieb die Pipeline-UI im Status „Laden für immer“.
- Windows Server hat ein Kompatibilitätsproblem mit Jenkins.
- Eingehende Ereignisse verbleiben im Status „Warten“, wenn die URL für die Aufgabenausführung ein Komma (,) für Jenkins-Pipelines mit mehreren Verzweigungen enthält.
- Die Verbindung von Tools wurde aufgrund der Quotenbegrenzung im System selbst für Tools mit gültigen Anmeldeinformationen getrennt.
- Die codierte Abfrage zum Zurückgeben der Aufgabenausführungs-URL für Jenkins-Pipelines mit mehreren Verzweigungen funktionierte nicht.
- Die einer Pipeline zugeordnete Orchestration-Aufgabe wurde nicht umbenannt, als eine Pipeline in ADO umbenannt und in ServiceNow erneut erkannt wurde.
- Die Zuweisungsgruppe wurde in einer Change-Anforderung nicht festgelegt, wenn in einem Change-Schritt eine Vorlage hinzugefügt und die entsprechende Pipeline ausgeführt wurde.
- Eingehende Ereignisse sind beim Herstellen einer Verbindung mit einem privaten GitHub-Repository über GitHub Apps OAuth fehlgeschlagen.
- Bei Verwendung der Matrixstrategie zum Erstellen von Schrittnamen im GitHub-Workflow wurden falsche Schrittnamen generiert.
- Der Sonar-Schritt in ADO-Release-Pipelines funktionierte für Pull-Anforderungs-Pipelines nicht.
- Die Rückrufanforderung ist für anwenderdefinierte Changes in GitHub-Aktionen fehlgeschlagen.
- Sicherheitsfix für ADO-Webhooks.
- Die Unterstützung von MID-Server-Clustern für den Verbindungsalias des DevOps-Tools funktionierte nicht.

Neu:
- Sicherheits-Framework
  - Ein neues Integrations-Framework und Datenmodell wurde speziell für Anwendungssicherheitstools hinzugefügt. Es handelt sich um ein erweiterbares Framework, mit dem Sie auch anwenderdefinierte Integrationen mit beliebigen Tools für die Anwendungssicherheit erstellen können.
- Veracode-Unterstützung
  - Verbinden Sie Veracode, das in Ihre CI/CD-Pipelines integriert ist, mit DevOps Change-Geschwindigkeit, um Ergebnisse von Sicherheitsscans abzurufen. Dies hilft Ihnen zu bestimmen, wie angreifbar Ihr Code ist. Veracode-Scans, die in GitHub Actions-, Jenkins- und Azure DevOps-Pipelines konfiguriert sind, werden im Basissystem unterstützt. Sie können die Ergebnisse von Sicherheitsscans entweder in der zugehörigen Liste einer Change-Anforderung oder der Aufgabenausführung der Pipeline in Ihrer ServiceNow-Instanz oder in der Pipeline-UI anzeigen. Sie können Sicherheitsergebnisse verwenden, um Change-Richtlinien und Bedingungen für die Change-Automatisierung zu definieren.
- Multimodale Unterstützung
  - Multimodaler Change ist eine neue Change-Management-Funktion, die eine größere Flexibilität bei der Definition von Change-Modellen oder Prozessen ermöglicht, um moderne Entwicklungspraktiken widerzuspiegeln. DevOps unterstützt diese neue Funktion, mit der Sie Change-Modelle mit Status und Regeln erstellen können, die die Übergänge zwischen den Status bestimmen, um mit einer Suite von prägnanten Flows und Flow-Aktionen, die in Flow Designer erstellt wurden, zweckmäßige Change-Modelle bereitzustellen. Mit DevOps-Change-Modellen können Change-Teams jetzt selektiv zu einer Vielzahl von Modellen wechseln, die vollständig für ihre spezifischen Anwendungsfälle optimiert sind
- Sichere Token-Authentifizierung für Integrationsbenutzer
  - Azure DevOps-, Jenkins- und GitHub-Aktionen unterstützen jetzt die tokenbasierte Authentifizierung für Integrationsbenutzer. Jenkins unterstützt sowohl die Standardauthentifizierung als auch die Tokenauthentifizierung, um die Kompatibilität mit DevOps Config zu gewährleisten.
- Commits für GitHub Actions und Azure DevOps ausführen
  - Erhöhen Sie die Nachverfolgbarkeit, indem Sie die vollständige Liste der ausgeführten Commits für einen Change in GitHub Actions und Azure DevOps erfassen.
- Änderungen am Arbeitsbereich für Onboarding und Einblicke
  - Dies umfasst die Validierung der Installation der ServiceNow DevOps-Erweiterung in Azure DevOps vor der Konfiguration von Webhooks, das automatische Importieren von Pipeline-Schritten beim Durchlaufen des Setups der Change-Automatisierung, Informationssymbole für DevOps-Einblicke-Widgets und bessere Grafiken für Flow- und Beschleunigungsmetrik-Punktzahlen für DevOps-Einblicke.
- Protokollierung von CHG-Statusübergängen im Orchestration-Tool und in den Details der Richtlinienbedingung
  - Change-Informationen wie Change-Nummer, Status, Zuweisungsgruppe, Genehmiger, geplantes Start-/Enddatum werden in den Konsolenprotokollen von Azure DevOps-Pipelines und GitHub-Aktions-Workflows angezeigt, während für die Pipeline oder den Workflow die Change-Genehmigung aussteht. Die ServiceNow DevOps-Anwendung wird in regelmäßigen Abständen abgefragt. Wenn sich die Change-Informationen unterscheiden, werden sie direkt in den Konsolenprotokollen protokolliert, wodurch die Hops zur ServiceNow-Instanz minimiert werden. Die Details der Richtlinienbedingung, die fehlgeschlagen ist, werden auch in der Konsole des Orchestration-Tools protokolliert.
- Rufen Sie die Details der DevOps-Change-Anforderung ab, und aktualisieren Sie sie
  - Rufen Sie Change-Anforderungsdetails ab, die einer Azure DevOps-Pipeline und einem GitHub Action-Workflow zugeordnet sind, indem Sie die ServiceNow DevOps-Erweiterung aus dem Azure DevOps- und GitHub Action-Marketplace verwenden. Diese Erweiterungen oder anwenderdefinierten Aktionen können verwendet werden, um den Change abzurufen, zu aktualisieren und nach Bedarf zu schließen, indem die erforderlichen Attribute übergeben werden.
- Bereitstellungs-Gates für GitHub-Aktion
  - ServiceNow DevOps Change-Geschwindigkeit unterstützt jetzt GitHub Action Deployment Gates für seine Umgebungen. Durch die Integration dieser Funktion in ServiceNow DevOps können Entwickler Qualitygates für jede Bereitstellungsumgebung in GitHub Actions erzwingen und die Change-Details aus den Protokollen der GitHub Actions-Konsolenprotokolle für die Bereitstellungsschutzregel abrufen, zusammen mit dem Fortschritt der Change-Status wie genehmigt oder abgelehnt.
- Webhooks manuell konfigurieren
  - Sie können Webhooks jetzt manuell konfigurieren, anstatt sie automatisch über ServiceNow DevOps Change-Geschwindigkeit zu konfigurieren. Mit dieser Funktion können Sie auf das Token und die Sys-ID zugreifen. Mit diesen Informationen kann der -Tooladministrator in Ihrer Organisation die Webhooks manuell konfigurieren. Es ist nur für die Rollen DevOps-Administrator und Toolbesitzer zugänglich.
- ServiceNow DevOps-Verbindung und -Anmeldeinformationen
  - Die Ersteinrichtung von ServiceNow DevOps Change-Geschwindigkeit durch ServiceNow-Administratoren wurde vereinfacht. Die Aufgabe, den Integrationsbenutzer mit Anmeldeinformationen zur Standardauthentifizierung einzurichten, ist nicht mehr erforderlich. Setup des CreateDevOpsTool-Alias wurde entfernt.
- optimale Verarbeitung von ServiceNow DevOps-Ereignissen zur Verbesserung der Leistung
  - ServiceNow DevOps filtert unwichtige Ereignisse heraus, bevor sie eine Flow-Ausführung auslösen. Dadurch werden die Leistung der Ereignisverarbeitung und die Ausführungsbandbreite des Flow Designers für wichtige Ereignisse verbessert, wodurch sich die Gesamtantwortzeit verbessert. Dies ermöglicht es DevOps-Administratoren auch, Tool-Webhooks mit einem größeren Umfang hinzuzufügen, ohne die Systemleistung zu beeinträchtigen.
Wichtige Korrekturen.

Geändert:
- Verbesserte Fehlerbehandlung und bessere Schutzmaßnahmen: Verbesserte Fehlermeldungen, um die Suche nach der Ursache eines Problems beim Onboarding (Verbindung, Erkennen, Konfigurieren oder Importieren) eines Tools zu erleichtern. Fehlermeldungen identifizieren relevante aktive Probleme, heben bestimmte Probleme hervor und erläutern, wie sie entschärft werden können.
- Änderungen am DevOps-Change-Arbeitsbereich
  - Optimiertes anfängliches System-Setup für ServiceNow-Administratoren, einschließlich Setup-Status, verbesserter Identifizierung des für den Abschluss erforderlichen Umfangs, der Möglichkeit zum Festlegen neuer Passwörter für Accounts, die zur Konfiguration des Anmeldeinformationsalias verwendet werden, zusätzlicher Validierung und mehr.
  - Erweiterung der Rolle „App-Besitzer“, einschließlich der Möglichkeit, Pipelineschritte zu ändern, um Anwendungsservices zuzuweisen oder die Change-Automatisierung einzurichten. App-Besitzer können auch auf „Erkennen“ für Tools klicken, um neue Objekte zuzuordnen, die für ihre DevOps-Anwendung benötigt werden. Aktualisierte Toolverwaltung, mit der Sie die Anmeldeinformationen für jedes Tool einfach aktualisieren und die Berechtigungen für die angegebenen Anmeldeinformationen überprüfen können.
- Rally-Integration: Stellen Sie eine Verbindung zum Planungstool Broadcom Rally her, um Rally-Planungsobjekte wie Epics, Stories, Fehler und Aufgaben als Arbeitselemente in DevOps-Daten zu importieren. Die Rally-Integration unterstützt die Erkennung von Arbeitselementen, die Konfiguration von Webhooks zum Senden von Echtzeitdaten und den Import von Verlaufsdaten. Rally-Arbeitselemente können Commits zugeordnet werden, die für die Beschleunigung von Change-Anforderungen verwendet werden.
- GitHub-OAuth-JWT-Authentifizierung: Die sichere Authentifizierung der GitHub-Tool-Verbindung wird jetzt mit OAuth-JWT (Json-Web-Token) unterstützt. Die OAuth-JWT-Authentifizierung mit einem in GitHub generierten privaten Schlüssel wird jetzt unterstützt.
- DevOps-Change-Anforderungsdetails abrufen und aktualisieren: Rufen Sie Change-Anforderungsdetails ab, die einer Jenkins-Pipeline zugeordnet sind, und aktualisieren Sie sie, indem Sie die Skripts snDevOpsGetChangeNumber bzw. snDevOpsUpdateChangeInfo in der Jenkins-Pipeline ausführen.
- DevOps-Beschleunigungsmetriken: werden jetzt auch im Arbeitsbereich für Digital-Portfoliomanagement nach Geschäftsanwendung angezeigt.
Behoben:
- Die Anwendung DevOps-Einblicke 1.36 fügt ACLs hinzu, wodurch die Business-Service- und Geschäftsanwendungs-CIs in der CMDB ausgeblendet werden.
- Das DevOps-Abonnement fügt die Anwender mit zugewiesener Rolle nicht über eine Zuweisungsgruppe zur Teilnehmertabelle hinzu.
- Das Besitzerfeld wird nicht ausgefüllt, wenn die App über das App-Onboarding erstellt wird.
- Jenkins Discover schlägt bei einer großen Anzahl von Pipelines/Aufträgen fehl.
- Wenn der Pipeline-Name für alle Tools identisch ist (z. B. Gitlab, Jenkins), werden die Pipeline-Ausführungen eines Tools einem anderen Tool zugeordnet.
- Verzweigungsdetails fehlen für „Commit“ aufgrund der Konkurrenzbedingung, wenn Tag- und Verzweigungsereignisse gleichzeitig verarbeitet werden.
- Die Meldung „Möchten Sie konfigurieren?“ Kontrollkästchen fehlt im Serviceportal während des App-Onboardings.
- Bei der GitHub-Massencommit-Verarbeitung werden mehr Commits als erforderlich beibehalten.
- Für eine Azure DevOps (ADO)-Pipeline mit nur einer Phase und aktiviertem Change-Beleg wird die CR mit einem tatsächlichen Startdatum erstellt, das nach dem tatsächlichen Enddatum liegt.
- Gitlab Discover füllt nur die ersten 100 Repositorys (Wert in der Eigenschaft „import.coding_tool.repos.per_page“ definiert) und Pipelines.
- Der aus dem DevOps-Paket erstellte CI-Klassenname „Paket“ steht in Konflikt mit dem CMDB-CI-Betriebssystempaket.

Geändert:

Aktualisierte Fehlermeldungen
- Verbesserte Fehlermeldungen, um die Ursache eines Problems beim Herstellen einer Verbindung mit einem -Tool zu ermitteln. Fehlermeldungen identifizieren relevante aktive Probleme, heben bestimmte Probleme hervor und erläutern, wie sie entschärft werden können. Eine neue Berechtigungsprüfung beim Verbinden eines Tools zeigt anstelle der erforderlichen Berechtigungen Berechtigungen an, die in den Anmeldeinformationen verfügbar sind.
Sie können jetzt einen bestimmten MID-Server direkt auf der Seite des DevOps-Change-Arbeitsbereichs angeben, während Sie eine Verbindung zu einem Tool herstellen
Ausführungen der Pull Request-Pipeline (PR) unterstützen GitHub/Jenkins
- Verfolgen und unterstützen Sie die Ausführungen der Pull-Request-Pipeline für das Jenkins-Orchestration-Tool und PRs, die im GitHub-Codierungstool erstellt wurden. Integrieren Sie PR-Daten wie Abrufanforderungs-ID, Commits, Ursprungsverzweigung, Zielverzweigung, „Gestellt von“, Genehmiger, Kommentare, ausgelöste PR-Zeit, PR-Genehmigungszeit und PR-Zusammenführungs-/Schließungszeit aus dem GitHub-Codierungstool in das für den entsprechenden erstellte DevOps-CHG Pipeline-Ausführung im Jenkins-Orchestration-Tool. Fügen Sie außerdem die PR-bezogenen Daten an die DevOps-CHG an, um zu überprüfen, wer den PR-Zusammenführungsprozess autorisiert, validiert, verifiziert und genehmigt hat.
Verlaufsdaten für DevOps-Tools und CHG-Rückverfolgbarkeit importieren – Gitlab
- Importieren Sie Verlaufsdaten für Code- und Orchestration-Fähigkeiten, indem Sie Daten über den Selfservicekatalog für das App-Onboarding und regelmäßige Abfragen abrufen.
- Das Import-Framework hilft beim Onboarding von Teams, indem DevOps-Daten in die Instanz importiert werden, ohne die Pipeline bearbeiten oder Webhooks konfigurieren zu müssen. Die importierten Daten bieten Einblicke in die Ursachen für eine vollständige Change-Rückverfolgbarkeit von Commits, Verzweigungen, Tags und Pipelines (beide CI/CD) aus Gitlab.
SonarQube – Unterstützt neue Codemetriken
- Integrieren Sie die von SonarQube-Scan-Ergebnissen bereitgestellten neuen Code-Metriken neben den Gesamt-Code-Scan-Ergebnissen, basierend auf der Konfiguration für neuen Code in SonarQube. Die folgenden neuen Codemetriken sind in diesem Release integriert: Neue Schwachstellen, Neue Wartbarkeitsbewertung, Neue Zuverlässigkeitsbewertung, Neue Sicherheitsbewertung, Neue Fehler, Neue Code-Geschmacksrichtungen, Neue Technische Schulden und Neue Codezeilen. Dies wird für die Orchestration-Tools Jenkins, Azure DevOps und GitHub Actions unterstützt.
Integration des Split.io-Funktionskennzeichnungs-Tools mit ServiceNow
- Diese Integration erweitert ServiceNow um die Verwaltung des CHG-Genehmigungsprozesses für Funktionskennzeichnungen und Segmente von Split.io. ServiceNow DevOps kann jetzt Updates für Funktionskennzeichnungen verwalten.
- Die Unterstützung des Split.io-Funktionskennzeichnungstools ermöglicht die Discovery von Arbeitsbereichen, Umgebungen, Segmenten und Funktionskennzeichnungen. Sie können CHG-Anforderungsfelder festlegen, um Split.io für die CHG-Steuerung zu aktivieren. Bei der Genehmigung/Ablehnung einer CHG-Anforderung wird die Rückruf-URL in Split.io für den Split oder das Segment aufgerufen, um die Implementierung des Updates für den Split und das Segment fortzusetzen
Behoben:
- Das Dashboard für DevOps-Einblicke kann jetzt nach Geschäftsanwendung filtern.
  - Artefakte mit demselben Namen, aber unterschiedlichen Versionen werden als Duplikate betrachtet (auch wenn sie zu unterschiedlichen Repositorys gehören).
  - Für eine ADO-Release-Pipeline wurden zwei Pipelineausführungen erstellt, wenn der ADO-Projektname Leerzeichen und Sonderzeichen enthält.
  - DevOps – Change-Tickets enthalten Links zur Pipeline-Startseite anstelle einer bestimmten Ausführung.
  - Azure DevOps
    - Commits und Arbeitselemente werden nicht mit Artefakten für Pipelines verknüpft, die im ersten Schritt oder Auftrag Artefakte veröffentlichen enthalten.
    - Azure DevOps – Importierte Commit-Details zeigen die falsche Anzahl der geänderten Dateien an
    - Arbeitselemente, Testzusammenfassungen und Commits werden in ServiceNow nicht an Changes angehängt, wenn die Release-Pipeline vor der Build-Pipeline eincheckt.
    - Falsche Nachricht in den Details zur Verarbeitung eingehender Ereignisse, wenn die Testtypzuordnung fehlt.
  - Nach dem historischen Import von abgebrochenen Pipelineausführungen wird der Pipelinestatus in der Pipeline-UI als „In Bearbeitung“ angezeigt
  - Jenkins-Orchestration-Ereignisse gehen nach dem Zufallsprinzip in den Fehlerstatus über.

Neu:
- Verbesserte Fehlermeldungen, damit Sie die Ursache eines Problems beim Herstellen einer Verbindung mit einem -Tool ermitteln können. Fehlermeldungen identifizieren relevante aktive Probleme, heben bestimmte Probleme hervor und erläutern, wie sie entschärft werden können.
- Sie können jetzt einen bestimmten MID-Server direkt auf der Seite des DevOps-Change-Arbeitsbereichs angeben, während Sie eine Verbindung zu einem Tool herstellen.

Neue Funktion:

Unterstützung für Pipelines mit mehreren Verzweigungen bei der Registrierung eines Changesets oder Snapshots bei der Pipeline-Ausführung hinzugefügt (erfordert DevOps Config)
- Erfordert das Jenkins-Plug-in für ServiceNow DevOps v1.35.2

Behoben: MID-Server, der einem Verbindungsalias zugewiesen ist, der beim Erstellen des Change nicht ausgewählt wurde.

Neu
- Integration von GitHub-Aktionen:
  - GitHub ist ein Codierungstool, das jetzt aktualisiert wurde, um die Orchestration-Funktion für GitHub-Aktionen in ServiceNow DevOps zu unterstützen. Sie verwenden die anwenderdefinierten ServiceNow DevOps-Aktionen (veröffentlicht im GitHub Actions-Marketplace), um GitHub Actions-Pipelines und GitHub-Umgebungen zu integrieren.
  - Zum Aktualisieren des Datenmodells erfordert GitHub Actions Integration, dass GitHub verbunden und konfiguriert ist und Pipelines erkannt werden. GitHub Actions-Workflows werden mit anwenderdefinierten Aktionen angehalten und fortgesetzt.
  - Die folgenden anwenderdefinierten Aktionen werden im GitHub-Repository veröffentlicht:
    - ServiceNow DevOps Change
    - ServiceNow DevOps-Testbericht
    - ServiceNow DevOps-Sonar
    - ServiceNow DevOps-Registerartefakt
    - ServiceNow DevOps-Registrierungspaket
- Import und Abfrage von Verlaufsdaten für Azure DevOps-Artefakte: Sie können Verlaufsdaten für ADO-Artefakte importieren, indem Sie die Daten mithilfe des Selfservicekatalogs für App-Onboarding und durch regelmäßige Abfragen abrufen. Das Import-Framework hilft beim Onboarding von Teams, indem es DevOps-Daten in die Instanz abruft, ohne die Pipeline bearbeiten oder Webhooks konfigurieren zu müssen. Die importierten Daten bieten Einblicke in die Ursachen für eine vollständige Rückverfolgbarkeit von Changes und helfen so, die Ursachen und Bereiche mit Verbesserungspotenzial zu identifizieren.
- Sofort einsatzbereite Change-Genehmigungsrichtlinie – Risikoeingaben und Ablehnungsgründe: Die DevOps-Standard-Change-Genehmigungsrichtlinie des Basissystems verbessert die Change-Automatisierungs- und Genehmigungsrichtlinie. Richtlinienbedingungen werden für gesammelte DevOps-Daten ausgeführt, um sie automatisch abzulehnen, zu genehmigen oder die manuelle Genehmigung zurückzustellen. Die Daten können Metriken zu Commits, Codeabdeckung, Testergebnissen, Sonar-Scan-Ergebnissen, Risikoeingaben usw. sein. Die Richtlinie für Change-Genehmigungen ist konfigurierbar. Damit Anwender schnell Korrekturmaßnahmen ergreifen können, werden Ablehnungsgründe in den CHG-Arbeitsnotizen festgehalten.
- Jenkins-Fragmentgenerator: Das Jenkins-Plugin für ServiceNow DevOps kann geskriptete DevOps-Pipeline-Schritte generieren. Dies hilft Entwicklern, ServiceNow DevOps-Funktionen schnell zu übernehmen und Pipelines einfach zu ändern.

Geändert
- Standardmäßige Change-Genehmigungsrichtlinie: Die standardmäßige Change-Genehmigungsrichtlinie von DevOps (OOTB) ist implementiert, um die Change-Automatisierungs- und Genehmigungsrichtlinie zu aktualisieren. Mit denen werden die Richtlinienbedingungen auf die gesammelten DevOps-Daten angewendet, um sie entweder automatisch abzulehnen, automatisch zu genehmigen oder zur manuellen Genehmigung zurückzustellen. Die DevOps-Daten können Metriken zu Commits, Codeabdeckung, Testergebnissen, Sonar-Scan-Ergebnissen usw. sein. Die Richtlinie für Change-Genehmigungen ist konfigurierbar.
- Importieren Sie Verlaufsdaten für DevOps-Tools – Azure DevOps: Importieren Sie Verlaufsdaten für alle Fähigkeiten (Code, Planung und Orchestration), indem Sie den Selfservicekatalog für App-Onboarding verwenden und regelmäßig abfragen, um Daten abzurufen. Das Import-Framework hilft beim Onboarding von Teams, indem es DevOps-Daten in die Instanz abruft, ohne die Pipeline bearbeiten oder Webhooks konfigurieren zu müssen. Die importierten Daten bieten Einblicke in die Ursachen für eine vollständige Rückverfolgbarkeit von Changes. Ab Version 1.34 können Sie Daten importieren und einen Abfragemechanismus für Azure DevOps konfigurieren.
- jFrog – Jenkins-Artefakt-Integration: Integrieren Sie Jenkins und jFrog Artifactory in ServiceNow DevOps, und verwenden Sie diese Daten für die Rückverfolgbarkeit und die Verknüpfung von CI/CD-Pipelines in ServiceNow. Ordnen Sie die Build-Pipelines (Build Pipelines, CI) den Artefakten zu, die erstellt und in jFrog veröffentlicht wurden, und ordnen Sie die Bereitstellungs-Pipelines (CD) den Paketen zu, die aus den jFrog-Repositorys heruntergeladen wurden, um sie bereitzustellen. Durch das Verknüpfen dieser CI/CD-Pipelines mit den Artefakten und das Zuordnen dieser zum Change wird der Link vom Commit zu Artefakten erstellt, die für die Rückverfolgbarkeit von Changes erstellt und bereitgestellt werden.
Behoben
- GitLab-Integration: Sehr große GitLab-Build-Nummern werden als extrem große Nummern in der Spalte „build_number“ der Tabelle „Aufgabenausführung“ gespeichert
- Sicherheitsfehler

Geändert
- Change-Rückverfolgbarkeit
  - Die Rückverfolgbarkeit von Changes ist eine nicht-angriffige Methode, um DevOps-Daten zur Beschleunigung manueller Changes zu nutzen. Dies ermöglicht eine kürzere Amortisierungszeit auf dem Pfad zur vollständigen Change-Automatisierung. Mit diesem Release können Sie entweder Artefaktversionen, Build-Nummern oder eine Release-Version einer manuell erstellten Change-Anforderung zuordnen, die DevOps-Daten wie Arbeitselemente, Commits und Tests abruft.
  - Die Implementierung erfordert keine Pipeline-Änderungen, um ServiceNow DevOps-Change-Aufgaben einzubeziehen. Dadurch haben Sie mit den zugehörigen DevOps-Daten einen vollständigen Überblick darüber, was in der Produktion bereitgestellt wurde, um Ihre manuellen Changes zu beschleunigen.
- Unterstützt Import und Abfrage von JIRA, GitHub und Jenkins
  - Der Import über den App-Onboarding-Selfservicekatalog und regelmäßige Abfragen zum Abrufen von Daten für alle Fähigkeiten (Code, Planung und Orchestration) helfen Ihnen beim Onboarding von Teams, indem DevOps-Daten schnell in ServiceNow übernommen werden, ohne die Pipeline bearbeiten oder Webhooks konfigurieren zu müssen. Die importierten Daten bieten Ihnen Einblicke in die Ursachen für eine vollständige Rückverfolgbarkeit von Changes. Diese Version umfasst das Import-Framework für JIRA, GitHub und Jenkins sowie den konfigurierbaren Abfragemechanismus.
  - Die folgenden App-Spoke-Abhängigkeiten werden hinzugefügt, um die Funktion zu unterstützen
    - Jenkins V2-Spoke – 1.1.2
    - Jira-Spoke – 3.1.1
    - GitHub-Spoke – 2.2.2
- Dashboard und Benachrichtigungen zur Systemintegrität
  - Das Systemintegritätsdashboard bietet eine Möglichkeit, die Daten, die von Ihren verbundenen DevOps-Tools in ServiceNow DevOps eingehen, zu überwachen oder Probleme zu beheben. Auf diese Weise erhalten DevOps-Administratoren einen besseren Einblick in die eingehenden Ereignisverarbeitungsdaten, die von verschiedenen Tools empfangen werden, die in DevOps konfiguriert wurden. Es gibt auch eine einfache Möglichkeit, den aktuellen Status der Toolkonnektivität zu überprüfen.
  - E-Mail-Benachrichtigungen können an eine Gruppe gesendet werden, die wöchentlich Informationen zu wichtigen Statistiken wie Pipeline-Ausführungen, Change-Anforderungen und eingehenden Ereignisdaten bereitstellt. Auf diese Weise können DevOps-Administratoren proaktiv benachrichtigt werden, wenn sich mögliche Änderungen an der allgemeinen Hilfe ihres DevOps-Systems ergeben.
Behoben
- Azure DevOps
  - Wenn mehrere Commits gleichzeitig (Millisekunde) verarbeitet werden, werden doppelte Repositorys erstellt
  - Das erstellte ADO-Tool speichert Anmeldeinformationen in Klartext
- GitLab-Benachrichtigungen bleiben im Status „Warten“ und im Fehlerstatus hängen, wenn der MID-Server zeitweise hoch- und heruntergefahren wird
- Die Pipeline-UI wird für Pipelines mit einer großen Anzahl von Pipeline-Ausführungen nicht geladen
- DevOps-Beziehungsregeln werden für Change-Anforderungen mit Nicht-DevOps-Kategorie ausgeführt
- Die Artefaktregistrierung für den Freestyle-Auftrag schlägt nach dem Upgrade auf 1.32 fehl
- Sicherheitsfehler

Neu
- Jenkins-Support für parallele Phasen: ServiceNow DevOps verfolgt jetzt Phasen, die parallel/verschachtelt in Jenkins-Pipelines ausgeführt werden. Die parallelen Phasen werden auf der Pipeline-Benutzeroberfläche genau gerendert, und automatisierte Change-Anforderungen werden erst erstellt, wenn die parallelen Phasen vor ihnen abgeschlossen sind
- Azure DevOps: Massenverarbeitungsfunktion für Orchestration-Fähigkeit des ADO-Tools aktiviert, um die Verarbeitung von Ereignissen zu optimieren
- Tabellenarchivierungsrichtlinien: Archivregeln zur automatischen Archivierung von Daten hinzugefügt, die älter als 9 Monate sind (konfigurierbar, können für alle Archivierungsregeln mit einer Eigenschaft konfiguriert werden). Vernichtregeln werden hinzugefügt, die die archivierten Daten löschen, die älter als 3 Jahre sind. Die obigen Archivierungs- und Vernichtungsregeln werden auf Tabellen angewendet, die aus Daten bestehen – PipelineExecution, StepExecution, TaskExecution und alle zugehörigen Tabellen.
Behoben
- Agile Development 2.0: Wenn ein Benutzer mit den Rollen scrum_product_owner und scrum_story_creator eine User Story erstellt, wird das entsprechende Arbeitselement nicht in DevOps erstellt
- Jenkins: Pipelines mit mehreren Verzweigungen mit BitBucket-Konfiguration haben einen Aufgabenausführungswert, da leere Pipeline-Ausführungen erstellt werden, obwohl „Nachverfolgen“ für Pipelines mit mehreren Verzweigungen und geschachtelte Pipelines NICHT aktiviert ist. Nach dem Neuerstellen des Jenkins-Tools werden eingehende Ereignisse erstellt, obwohl Pipelines nicht erkannt oder nachverfolgt werden
- Azure DevOps: Für anwenderdefiniertes Projekt (nicht Agile-Projekt): Wenn das ADO-Arbeitselement gelöscht wird, eingehende Ereignisfehler mit Fehlercode 400, wodurch der Status des entsprechenden DevOps-Arbeitselements nicht in „Gelöscht“ aktualisiert wird
- Die Kennzeichnung „Change-Beleg“ für einen Pipeline-Schrittdatensatz wird nicht aktualisiert, wenn die Nutzlast für das App-Onboarding gebucht wird

Neu
- Unterstützung für parallele Phasen in Azure DevOps
  - ServiceNow DevOps verfolgt jetzt Phasen, die in Azure DevOps-Release-Pipelines parallel ausgeführt werden. Die parallelen Phasen werden auf der Pipeline-Benutzeroberfläche genau gerendert, und automatisierte Change-Anforderungen werden erst erstellt, wenn die parallelen Phasen vor ihnen abgeschlossen sind.
  - HINWEIS: Die Unterstützung für parallele Phasen ist auf Azure DevOps-Release-Pipelines beschränkt. Build-Pipelines werden in ServiceNow DevOps weiterhin seriell nachverfolgt und gerendert.
- Selfservice-Onboarding
  - Diese Version enthält zwei neue Servicekatalogelemente, um ein Selfservice-Modell für das Onboarding von Teams bei ServiceNow DevOps zu ermöglichen:
    - Tool-Onboarding: Ermöglicht Teams die Erstellung einer neuen ServiceNow DevOps-Toolinstanz, einschließlich Erstellung, Verbindung, Discovery und Konfiguration des Tools. Nach Abschluss ist das Tool bereit für das App-Onboarding.
    - App-Onboarding: Ermöglicht Teams das Erstellen einer neuen ServiceNow DevOps-App (oder das Konfigurieren einer vorhandenen App), einschließlich Pipelinephasen-Discovery, Steuerung der Nachverfolgung und (optional) Aktivierung der Change-Steuerung für einen Schritt.
- Mit diesen beiden Katalogelementen können Entwicklungsteams ihre Projekte für die Verwendung mit ServiceNow DevOps in wenigen Minuten von Anfang bis Ende vollständig autonom und nach ihrem eigenen Zeitplan konfigurieren.
- Neue DevOps Change-Geschwindigkeits-App
  - Eine neue App „DevOps Change-Geschwindigkeit“ wurde eingeführt, um die vorhandene DevOps-Change-Beschleunigungsfunktion zu hosten. Durch die Installation von DevOps Change Velocity werden alle Abhängigkeiten von ServiceNow DevOps-Apps automatisch installiert oder aktualisiert, sodass sie nicht mehr einzeln installiert werden müssen. In Verbindung damit wurde die vorhandene App „DevOps“ in „DevOps-Datenmodell“ umbenannt. Dies ist eine organisatorische Maßnahme zur Verbesserung der Anwendungsinstallations-Experience. die bestehende ServiceNow DevOps-Funktionalität wird in keiner Weise geändert.
- Aktivierung der automatischen Change-Steuerung für ADO und Jenkins
  - Wenn die DevOps-Change-Steuerung in einer Azure DevOps- oder Jenkins-Pipeline aktiviert wurde, ist für den entsprechenden Schritt in ServiceNow automatisch die Change-Steuerung aktiviert. Diese Verbesserung funktioniert mit der Self-Service-Onboarding-Funktion, um den Onboarding-Prozess zu vereinfachen und zu optimieren.

Neu
- Phasen für Azure DevOps neu starten: Unterstützt Neustarts von Pipelines und Phasen/Schritten, mit denen Sie die Informationen korrekt nachverfolgen können, da die Pipeline-Ausführung identisch ist.
- GitLab-OAuth: OAuth wird unterstützt, da es sicherer als Standardauthentifizierung ist, um böswillige Aktionen und ungesicherte Transparenz zu verhindern.
Behoben
- Jenkins-Plugin für ServiceNow DevOps
  - Sicherheitsschwachstellen im Zusammenhang mit Abhängigkeiten vom Jenkins-Plugin. (Hinweis: Ab DevOps 1.30 muss die Basisversion des Jenkins-Servers mindestens 2.204.6 sein, um die Schwachstellen zu beheben.)
  - Benachrichtigung, die im Wartestatus für Pipelines mit mehreren Verzweigungen steckt, die einen Verzweigungsnamen mit Sonderzeichen aufweisen (z. B. Scratch/dev!@@&mybranch).
- Azure DevOps
  - Build-Pipeline: Artefaktversionen werden in der zugehörigen Liste „Change-Anforderung“ nicht angezeigt, wenn Paket und Change in derselben Phase erstellt werden.
  - Das Feld Committet am wird geändert, wenn ein Tag für einen historischen Commit erstellt wird.
  - Release-Pipeline-Ausführungen erstellen bei jeder Ausführung ein Paket mit demselben Namen.
- Leistungsprobleme bei Tabellen für die DevOps-Pipeline-Ausführung, Testzusammenfassung und Rückruf.
- Zeitweise werden in DevOps doppelte Arbeitselemente erstellt, wenn das Arbeitselement aus dem ServiceNow-Plugin „Agile 2.0“ erstellt wird.
- Testergebnisse werden in der Bereitstellungspipeline nicht angezeigt, wenn sie aus mehreren Build-Pipelines generiert werden.
Geändert: Ab DevOps 1.30 muss die Basisversion des Jenkins-Servers mindestens 2.204.6 sein, um die Schwachstellen zu beheben.

Funktionsänderungen:
- Jenkins-Plugin für ServiceNow DevOps
  - Plugin aus dem Jenkins-Marketplace: Einfaches Onboarding durch direkte Installation aus dem Jenkins-Marketplace. Hauptsächlich, um ALLE Probleme zu beseitigen, damit Entwickler sich selbst einarbeiten und die Lösung verwenden können
  - Verbesserte Protokollierungsebenen: Die Protokollierung ist der Schlüssel zum Diagnostizieren oder Debuggen eines Problems. Wenn Sie jedoch übermäßige Protokollierung aktivieren, kann dies Ihr System schnell überlasten und die Server beenden. Entwicklerteams können jetzt die gewünschten Protokollebenen festlegen, um die genaue Ursache eines Problems zu ermitteln
  - Reduzierung übermäßiger Pipeline-Infoaufrufe: Um bei jeder Auslösung eines Jenkins-Builds die Anzahl der Aufrufe von Jenkins an ServiceNow zu reduzieren, um zu erfahren, ob eine Pipeline nachverfolgt wird, wurde in der Jenkins-Konfiguration die neue Kennzeichnung „Nachverfolgungsprüfung erzwingen“ eingeführt. Wenn diese Option deaktiviert ist, wird eine Datei mit den Pipeline-Nachverfolgungs- und Testinformationen erstellt, anhand derer ermittelt wird, welche Pipelines in ServiceNow zum Senden von Benachrichtigungen nachverfolgt werden. Immer wenn ein Anwender eine Pipeline-Nachverfolgungskennzeichnung oder Testinformationen in einer ServiceNow-Anwendung aktualisiert, sendet ServiceNow einen POST-REST-API-Aufruf an Jenkins, um die Pipeline-Nachverfolgungsdatei zu aktualisieren
- Change-Anforderung bei Kategorisierung: Wenn eine Change-Anforderung automatisch erstellt wird, hat sie die Kategorie=DevOps. Die Kategoriewerte, die Sie heute haben, bezeichnen eine Art von Change, wie Hardware, Software, Netzwerk usw., während der Wert „DevOps“ eher die Quelle der Änderung ist. Es kann Instanzen geben, in denen ein Change von DevOps stammt und vom Typ „Hardware“ oder „Software“ ist. Darüber hinaus könnte bereits die Kategorieliste für einen anderen Zweck verwendet werden und Werte wie z. B. Nicht-Produktion usw. verwenden. Das DevOps-Team hat jetzt die Möglichkeit, eindeutig zu bestimmen, dass ein Change-Datensatz ein „DevOps-Change-Datensatz“ ist.
- Verbesserte Leistung des Durchsatzes bei der Verarbeitung eingehender Ereignisse
Korrekturen:
- ADO-Pipeline- und Aufgabenausführungen werden bei der Nachverfolgung einer bestimmten Pipeline auf Toolebene angezeigt, die Nachverfolgung ist für die Pipeline jedoch nicht aktiviert
- Im Tabellendatensatz „sysapproval_approver“ sind keine Kommentare zur automatischen Genehmigung und Ablehnung von Change-Anforderungen festgelegt
Jenkins-Plugin für ServiceNow DevOps: 1.29

Neu:
- Eingehende Ereignisse, die mit bestimmten Ausnahmetypen fehlschlagen, werden automatisch von einer geplanten Aufgabe wiederholt. Die Ausnahmetypen, die Anzahl der Wiederholungen und das Alter der zu verarbeitenden fehlerhaften eingehenden Ereignisse können in den DevOps-Eigenschaften konfiguriert werden
- Jenkins-Integration
  - Verbesserte Sicherheit: Sie können jetzt API-Schlüssel zum Erstellen im Jenkins-Tool in ServiceNow DevOps verwenden. Der Grund für die Ablehnung/Abbruch der Change-Anforderung wird an die entsprechende Jenkins-Pipeline zurückgesendet, sodass Sie wissen, warum der Change abgelehnt/abgebrochen wurde.
Behoben:
- Code- und Tag-Push-Ereignisse schlagen für einen leeren Commit fehl, der keine Dateiänderungen aufweist
- GitHub: Fehler 404 – Import funktioniert auf Repository-Ebene nicht – Wenn in der Tool-URL ein „/“ nachgestellt ist, ist das Artefakt nicht mit der Aufgabenausführung verknüpft, wenn der Pipeline-Name den Verzweigungsnamen enthält
- GitHub Enterprise: Repository kann aufgrund eines falschen webHookResourcePath nicht konfiguriert werden
- Das Layout der Pipeline-UI-Seite ist in IE11 Jenkins-Multibranch-Pipeline-Ereignissen im Status „Warten“ fehlerhaft, wenn der Verzweigungsname „/“ enthält und Junit-Tests die Multibranch-Pipeline mit einem Leerzeichen nicht funktionieren
- Azure DevOps:
  - Die Importanforderung für einen DevOps-Plan für Azure DevOps schlägt mit einem großen Backlog fehl (z. B. > 2.000 Arbeitselemente).
  - Die eingehende Benachrichtigung schlägt für einen Release fehl, der ein Azure-Artefakt enthält
  - Wenn sich die Anmeldeinformationen ändern/ablaufen, nachdem das Tool erstellt wurde, ist der Status der Importanforderungen für die Erkennungsaktion „Erfolg“ anstelle von „Fehler“.
  - Bei einer Ausführung in einer einzelnen Pipeline wird der rückgängig gemachte Commit vor dem ursprünglichen Commit beibehalten, wodurch der rückgängig gemachte Commit nicht aus den Run Commits entfernt wird
  - Jenkins-Plugin für ServiceNow DevOps: 1.28

Geändert:
- Softwarequalitäts-Framework: Aktualisiertes Datenmodell speziell für Tools für Codequalität und Sicherheit. Ein erweiterbares Framework, mit dem jeder anwenderdefinierte Integrationen für beliebige Codequalitäts- und Sicherheitstools erstellen kann.
- SonarQube-Support: OOTB-Support für Azure DevOps und Jenkins. Immer wenn ein Scan von der Pipeline ausgelöst wird, werden die Scan-Ergebnisse in ServiceNow DevOps erfasst, die zur Bestimmung des Change-Risikos erforderlich sind
- Zulassen, dass Change-Felder über die API festgelegt werden. Dadurch werden alle zuvor festgelegten Schrittkonfigurationen überschrieben. Die aktuelle Funktionalität bleibt bestehen. Der einzige Unterschied besteht darin, dass Felder jetzt über die API festgelegt werden können.
- Jenkins-Plugin für ServiceNow DevOps: 1.27
Behoben:
- Betrügerische Bedingung verursacht falsches
- Wartegrund für eingehendes DevOps-Ereignis und unvollständige Pipeline-Ausführungen Die DevOps-Change-Erstellung schlägt mit dem Legacy-Plugin „Change-Management“ fehl
- Wenn die GitHub-Pusher-E-Mail-Adresse leer ist, werden „Committer“ und „Committer-E-Mail“ in DevOps nicht ausgefüllt
- Für BitBucket werden DevOps-Tag-Updates nicht verarbeitet

Geändert:
- Erstellen Sie Verbindungsaliasse (unter einem übergeordneten Alias) dynamisch, sodass ein Systemadministrator Verbindungsaliase beim Erstellen des DevOps-Tools nicht separat erstellen muss. Diese Funktion nutzt die Plattformfunktion „Untergeordnete Aliasse“ und ist ab Paris verfügbar. Die DevOps-Anwendung wird mit übergeordneten Aliassen und entsprechenden Konfigurationsvorlagen (Basisauth., API-Schlüssel und OAuth-Autorisierungscode) geliefert, die dann zum Erstellen von Verbindungen und Anmeldeinformationen unter dem erstellten untergeordneten Alias verwendet werden können.
Behoben:
- Die Pipeline-UI ist fehlerhaft, wenn alle Aufgabenausführungen übersprungen werden
- Die Test-Tool-Integration erwartet, dass die Tool-ID in den Abfrageparametern eine Orchestration-Tool-ID ist
- DevOps-Tag-Aktualisierungen werden nicht verarbeitet
- Es gibt keine Standardverarbeitung für nicht unterstützte Azure-Status wie „SucceededWithIssues“. Filtern Sie die Commit-API, um nur Commits für Jenkins abzurufen
- Verzweigungsinformationen werden für Commits beim Code-Merge nicht aktualisiert
Kompatibilität von Plugins und Erweiterungen:
- Jenkins-Plugin für ServiceNow DevOps (1.24.0) https://marketplace.visualstudio.com/items?itemName=ServiceNow.vss-services-servicenow-devops Version: 1.24.0

Geändert:
- Azure DevOps: Das Onboarding des ADO-Tools wird erleichtert, indem Kunden die Möglichkeit gegeben wird, nur bestimmte Pipelines nachzuverfolgen.
- Sie können jetzt Archivierungs-/Löschbedingungen für die Tabelle „Eingehende Ereignisse“ festlegen, um große Mengen von DevOps-Daten zu verarbeiten
Behoben:
- Azure DevOps: Wenn Auftragsnamen in verschiedenen Phasen identisch sind, ist das Artefakt/Paket nicht mit der Aufgabenausführung verknüpft
- Azure DevOps: Für ein Release-Gate mit nur manuellen Auslösern auf einer Phase erstellt die Release-Pipeline zwei Pipeline-Ausführungsdatensätze
- Die Artefaktgenerierung enthält Commits aus verschiedenen Verzweigungen für fehlgeschlagene Ausführungen in der Multibranch-Pipeline
- DevOps-Flow Designer-Skripts sollten als „Anwender, der die Sitzung initiiert“ und nicht als „Systemanwender“ ausgeführt werden.

Geändert:
- API-Changes der Pipeline für Change-Anforderungen: Legen Sie zusätzliche Change-Anforderungsattribute fest, wenn Sie die Change-Anforderung aus Jenkins- und Azure DevOps-Pipelines erstellenLegen Sie die Kennzeichnung aus der Pipeline fest, damit ServiceNow DevOps die Change-Anforderung nicht schließt
- GitLab- und Azure DevOps-Repository-Tags werden jetzt in ServiceNow DevOps unterstützt
- Kann jetzt Massen-Commits aus GitLab verarbeiten
- „Version“ ist jetzt ein optionales Feld in der Plannutzlast
Behoben:
- Die Pipeline-UI rendert eine leere Seite für die Pipeline, die eine Artefaktversion in derselben Phase wie der Change erstellt
- In einer Change-Anforderung kann ein Benutzer mit nur der Rolle „DevOps-Betrachter“ alle Commits im System anstelle der im Artefakt enthaltenen Commits anzeigen
- Change-Anforderung wird nicht erstellt, wenn Commits einen leeren Committer enthalten
- Change-Anforderung wird nicht erstellt, wenn die vorgelagerte Phase auf „Übersprungen“ gesetzt ist
- Bei Azure DevOps und GitLab werden rückgängig gemachte Commits in einem Zusammenführungs-Commit in der zugehörigen Liste „Commits“ einer Change-Anforderung angezeigt

Funktionsänderungen:
- Das automatische Importieren und Kategorisieren von GitLab JUnit-Tests während der Pipeline-Ausführung wird jetzt unterstützt.
Korrekturen:
- Große Commits werden jetzt mit Azure DevOps unterstützt.
- Die Jenkins-Pipeline unter DevOps-Change wird nach dem Neustart des Jenkins-Servers automatisch fortgesetzt.
- Zwei Pipeline-Ausführungsdatensätze werden erstellt, wenn die Change-Steuerung in der ersten Phase einer Freestyle-Pipeline aktiviert ist.
- Das eingehende Ereignis generiert einen Fehler, wenn das Arbeitselement für das ADO-Tool mit einem Projekt verarbeitet wird, dessen Name ein Leerzeichen enthält. Wenn mehrere ADO-Pipelines (alle mit Tests) parallel ausgeführt werden, bleiben eingehende Ereignisse mit Ausnahmen im Status „Warten“ hängen.
- Die Nutzlast des App-Onboardings wird nicht im verschlüsselten Feld gespeichert.
- Eingehende Benachrichtigungen zum Phasenabschluss von Azure DevOps werden nicht ordnungsgemäß verarbeitet, was zu einer Zeitüberschreitung führt.
- Anwendungsfälle für erneute Versuche in Azure-Release-Gates schlagen mit Changes für Change-Belege fehl.
- Anwendername/Passwort für die globale Toolkonfiguration von Jenkins sind in der config.xml als Nur-Text gespeichert.
- Die Jenkins-Pipeline schlägt fehl, wenn die Pipeline nicht erkannt wurde.

Neu: Mehrere Arbeitselemente für einen Commit werden jetzt unterstützt und werden mit dem Commit in ServiceNow DevOps verknüpft. Außerdem:
- Die Syntax des Arbeitselements in der Commit-Nachricht kann an die Prozesse Ihrer Organisation angepasst werden.
- Die Auswahl der Arbeitselemente über die Azure DevOps-Anwenderoberfläche beim Commit wird jetzt unterstützt.

Neu:
- Sie können jetzt viele DevOps-Objekte wie Tools, Repositorys und Pipelines löschen. Die vollständige Liste und die Einschränkungen finden Sie in der Produktdokumentation.
- Sie können jetzt die in einer Pipeline erstellte Change-Nummer für die weitere Interaktion mit der Change-Anforderung aus der Pipeline abrufen.
Entfernt:
- Das Feld „Konfigurationselement“ in einem Tool wurde entfernt.
- Unter der Auswahl „Mid-Server verwenden“ wurden die beiden Felder („Mid-Server-Anwendung“, „Mid-Server-Fähigkeit“) entfernt.

Installieren Sie für die folgenden Korrekturen das Plugin Jenkins für ServiceNow DevOps (1.20.2).

Behoben:
- Sicherheitsfix
- Wenn die Pipeline nicht erkannt wurde, kann das Verhalten des Jenkins-Plugins fehlschlagen
- Wenn Jenkins neu gestartet wird, werden die Bereitstellungen ohne Change-Genehmigung fortgesetzt

Neu:
- Change-Registrierung: Pipeline-Schritte können jetzt so konfiguriert werden, dass Change-Belege erstellt werden, die alle Pipeline-Daten enthalten, erfordern jedoch keine Genehmigung, um in der Pipeline fortzufahren.
- Verbesserungen bei Testtools: JUnit- und Selenium-Tests können jetzt automatisch kategorisiert werden, und zusätzliche Testtypen können für die automatische Kategorisierung konfiguriert werden.
- Von Jenkins übersprungene Phasen: Wenn Phasen aufgrund von Verzweigungsbedingungen übersprungen werden, werden sie von der Pipeline-UI nicht angezeigt.

Neu:
- DevOps-Pipeline-Schritte werden jetzt automatisch erstellt, wenn die Jenkins-Pipeline ausgeführt wird. Sie müssen die Pipeline-Schritte nicht mehr manuell in ServiceNow erstellen oder die Benachrichtigungen in Jenkins konfigurieren. Changes werden in Jenkins und ServiceNow DevOps weiterhin manuell in den gewünschten Schritten konfiguriert.
- DevOps hat die Datenresilienz erhöht, indem für den Großteil der Toolkommunikation aus den ServiceNow-Flows Wiederholungen hinzugefügt wurden. Sie können die Wiederholungskonfiguration an Ihre Bedürfnisse anpassen.

Behoben: Dieser Release ist ein Fix-Release. Es behebt ein Kompatibilitätsproblem mit der Change-Funktion.

Neu: DevOps-Pipeline-Schritte werden jetzt automatisch erstellt, wenn die Pipeline des Orchestration-Tools ausgeführt wird. Sie müssen die Pipeline-Schritte nicht mehr manuell erstellen und dem Orchestration-Tool zuordnen. Changes müssen in den gewünschten Schritten weiterhin manuell konfiguriert werden.

Neu: OAuth- und GitHub-Apps werden jetzt mit der GitHub-Integration unterstützt
Behoben:
- Das Problem wurde behoben, bei dem der Schrittname unter „Schrittausführung“ leer war, bis die gesamte Ausführung abgeschlossen war
- Verbesserte Leistung bei der Git-Commit-Verarbeitung
- Das Problem wurde behoben, bei dem Azure DevOps-Commit-Datensätze nicht erstellt werden, wenn das zugehörige Arbeitselement nicht gefunden wurde
- Die korrigierte Verarbeitung von Azure DevOps-Pipeline-Ausführungen mit leeren JUnit-Tests

Neu:
- DevOps-Pipeline-UI wird aktualisiert, um Artefakte einzubeziehen
  - Möglichkeit, Artefaktversionen anzuzeigen, die in der Pipeline-UI erstellt oder veröffentlicht wurden
  - Verbesserungen der Barrierefreiheit
- Demodaten verbessert, um Beispiele für Pipeline-UI, Tool und Einblick zu enthalten
- Fähigkeit, Orchestration-Tools zu erstellen, die eventbasierte Discovery und generische Change-Beschleunigungsrückrufe nutzen
- Integrationen mit GitLab Codierungs- und Orchestration-Tools über die DevOps-Integrations-App

Neu:
- Vom Kunden verwalteter Change – DevOps bietet jetzt mehr Flexibilität bei der Konfiguration von Change-Anforderungs-Flows, z. B. Unterstützung für neue Change-Typen.
- Verbesserte Verarbeitung von Azure DevOps-Pipeline-Benachrichtigungen, die außerhalb der Reihenfolge liegen.
- Der Import von Verlaufsdaten für Azure DevOps-Arbeitselemente wird jetzt unterstützt.
Behoben:
- Gelöschte Ereignisse für Arbeitselemente werden für Azure DevOps jetzt ordnungsgemäß behandelt.
- Die Verarbeitung von Commit-Benachrichtigungen wurde korrigiert.
- Die Pipeline-UI wurde aktualisiert und enthält nun neue Status (vom Anwender abgebrochen) in Schrittausführungen.
- Problem behoben, bei dem aufgrund der Obergrenzeneigenschaft nur 200 Datensätze importiert werden.
- Der Toolerstellungshinweis „Toolerstellung kann bis zu einer Minute dauern“ ist jetzt übersetzbar.
- Unterstützung für Komponenten/Steuerelemente hinzugefügt, die ohne Status und/oder Eigenschaften bereitgestellt werden (erweiterbarer/reduzierbarer Inhalt).
- Das Problem wurde behoben, bei dem sich das Layout nicht an Änderungen der Textgrößeneinstellungen bis zu 200 % anpasst.

Hinweis:

Diese Version der App kann nur auf Instanzen installiert werden, die New York oder höher ausführen.

Neu: Verbesserungen an der Pipeline-UI

Neu: Das vom Anwender erstellte Integrations-Framework unterstützt jetzt Connect- und Discovery-Aktionen.

Toolerstellung verbessert

Es gibt eine neue Schaltfläche „Erstellen“, die:
- Erstellen Sie ein DevOps-Tool, erstellen Sie Verbindungen, Alias und Anmeldeinformationen und stellt automatisch eine Verbindung zum Tool her
App-Pipeline-UI
- Für Change-Anforderungen, die von DevOps erstellt wurden, gibt es einen zugehörigen Link zum Anzeigen der Pipeline-UI für diese Ausführung.
- Von der App- oder Schrittausführung aus können Sie dem zugehörigen Link zur letzten Ausführung in der Pipeline-UI folgen.

Neu:
- Eine REST-API, mit der jeder Benutzer Code-, Planungs- und Orchestration-Tools integrieren kann
- Jenkins-Aufträge in Ordnern können jetzt erkannt werden
- Change-Beschleunigung funktioniert auf MID Server

Name von „Enterprise DevOps“ in „DevOps“ geändert.

Verbesserungen der Benutzerfreundlichkeit und Stabilität

Modellierung konfigurierbarer Pipelines

Pipelines auf hoher Ebene ermöglichen, dass mehr als eine App Teil einer Pipeline ist.
Modellieren Sie die Jenkins-Jobs in Pipelinephasen auf App-Ebene (App-Phase).
Verfolgen Sie vor- und nachgelagerte Auftragsbeziehungen nach.

Change-Beschleunigung

Erstellen Sie Change-Anforderungen für Auftragsausführungen, die der Change-Steuerung unterliegen. Verwendet Konfigurationselemente, die in der App-Phase festgelegt sind.
Das Jenkins-Plugin wartet, bis die Change-Anforderung in den Status „Implementieren“ versetzt wird, bevor der Jenkins-Auftrag ausgeführt wird. Nach Ausführung des Auftrags wird die Change-Anforderung mit Implementierungsdetails aktualisiert und geschlossen.

Einblicke

Einblicke in die Change-Beschleunigung bieten Einblick in den Change-Management-Prozess und seine Effizienz.
Einblicke in die Systemintegrität ermöglichen Administratoren einen effektiven Betrieb der Pipeline.

ITBM Agile 2.0 Integration

Synchronisieren Sie ITBM-Produkte, Epics, Stories, Fixes und Releases automatisch mit ServiceNow® DevOps.
Import von Verlaufsdaten

Jira-Integration

Synchronisieren Sie Jira-Projekte, Epics, Stories, Fehler, Aufgaben und Releases automatisch mit ServiceNow® DevOps.
Import von Verlaufsdaten

GitHub-Integration

Unterstützt GitHub.com und Enterprise GitHub.
Verarbeiten Sie Commits und Verzweigungen mithilfe von Webhooks in ausgewählten Repositorys.
Web-Hook beim Konfigurieren des Repositorys automatisch verschieben.
Verfolgen Sie optional Dateiänderungen.
Verfolgen Sie Committer- und Repository-Qualitätsmetriken.
Import von Verlaufsdaten

Jenkins-Integration

Verwenden Sie das Jenkins-Benachrichtigungs-Plugin, um Updates an ServiceNow® DevOpszu senden.
Laden Sie den herunter, und installieren Sie ihn ServiceNow® DevOps Plugin für Jenkins. Der KB-Artikel enthält Anweisungen.
Importieren Sie Jenkins-Freestyle-Pipeline-Jobs, und ordnen Sie sie den ServiceNow® DevOps -Pipelines zu.
Speichern Sie Testergebnisse aus Jenkins, einschließlich JUnit- und Selenium-Tests.
Jenkins-Plugin zur Aktivierung der Change-Beschleunigung bereitgestellt.

DevOps Versionshinweise zum Datenmodell

Store-Versionshinweise

DevOps Versionshinweise zum Datenmodell

Versionsverlauf