DevOps Versionshinweise zur Change-Geschwindigkeit

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.
- Verbesserte Berechnung der Vorlaufzeit
  - Die Berechnung der Vorlaufzeit berücksichtigt jetzt Artefakte/Pakete, die als Teil der Pipelineausführung registriert sind, und wird basierend auf den ihr zugeordneten Commits berechnet.
- Verbesserte produktinterne Anleitung für eine effektive Einführung von Selfservices
  - Verbesserte Anwender-Experience durch Hinzufügen von Dokumentation oder Navigation zu externer Dokumentation an verschiedenen Stellen im Arbeitsbereich.

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.

Neu:
- Verbesserter Weg zur vollständigen Change-Automatisierung mithilfe von Modellen
  - Produktinterne Anleitung zur Nutzung von DevOps-Change-Modellen und zur einfachen Erstellung von DevOps-Changes ohne Unterbrechung des Change-Prozesses im DevOps-Change-Arbeitsbereich.
  - Beschleunigen Sie Ihren Change-Prozess mithilfe eines neuen vereinfachten DevOps-Change-Modells, das den Status „Bewerten“ nicht enthält. Die Change-Genehmigung für dieses Modell basiert auf der Change-Richtlinie für vereinfachtes DevOps-Modell.
  - Die Genehmigungsrichtlinie ist für die entsprechenden vereinfachten Change-Modelle von DevOps und DevOps standardmäßig manuell.
  - Der neue Ausführungsstatus-Flow „DevOps-Update ändern“ im DevOps-Modell wird jetzt verwendet, um einen Rückruf an das Orchestration-Tool des Drittanbieters zu senden.
- DevOps-Daten für Change-Nachverfolgbarkeit im Service Operations-Arbeitsbereich (SOW)
  - Fügen Sie DevOps-Daten in einer manuell erstellten Change-Anforderung im Service Operations-Arbeitsbereich hinzu, und bearbeiten Sie sie, um eine einheitliche Change-Anforderungs-Experience in DevOps Change Workspace und Service Operations-Arbeitsbereich zu erzielen.
  - Zeigen Sie die DevOps-Zusammenfassungskarte auf der Registerkarte „Übersicht“ des SOW-Arbeitsbereichs für alle Change-Status („Neu“, „Bewerten“, „Autorisieren“, „Zeitplan“, „Implementieren“, „Überprüfen“ und „Schließen“) an. Sie können auf der DevOps-Zusammenfassungskarte für manuell erstellte DevOps-Change-Anforderungen Daten hinzufügen oder bearbeiten.
- Hinweis: Diese Funktion ist nur für das Xanadu-Release verfügbar.
Bewusstsein für DevOps-Changes für Change-Manager im SOW Admin Center für die -Konfiguration
- ServiceNow-Administratoren sehen jetzt einen Navigationslink zum DevOps-Change-Arbeitsbereich (falls installiert) und den Link „App abrufen“, mit dem sie DevOps Change Velocity (DCV) installieren können, wenn sie noch nicht installiert sind (gilt nur für ITSM Pro oder wenn DCV für verfügbar ist installieren).
- Hinweis: Diese Funktion ist nur für das Xanadu-Release verfügbar.
- Bewusstsein für DevOps-Changes in Adoption Blueprints
  - Die neue Adoption Blueprint „Change-Management-Prozess modernisieren“ ist jetzt in den Adoption Blueprints des Admin Center verfügbar. Sie zeigt ServiceNow-Administratoren, wie sie die erforderlichen Funktionen übernehmen können, um ihren Change-Prozess dynamisch zu skalieren, ohne die Stabilität und Governance zu beeinträchtigen.
- Hinweis: Diese Funktion ist nur für das Xanadu-Release verfügbar.
Sensibilisierung von ServiceNow-Administratoren für DevOps-Changes im Change-Management-Setup
- Die neue Change-Management-Konfiguration im SOW Admin Center hebt Funktionen hervor, die von Change-Administratoren und -Managern verwendet werden können, um ihre Change-Management-Journey zu modernisieren, z. B. Change-Modelle, Risiko- und Erfolgspunktzahlen, Genehmigungsrichtlinien und DevOps, die somit als einzige Anlaufstelle für dienen Kunden, die Anleitungen zur Modernisierung von Changes suchen.
- Hinweis: Diese Funktion ist nur für das Xanadu-Release verfügbar.
Geändert:
- DevOps Change Request Manueller Genehmigungs-Flow löst Change aus
  - Der Flow „Manuelle Genehmigung von DevOps-Change-Anforderungen“ wird für DevOps-Change-Anforderungen, deren Modell ein Basissystem-DevOps-Change-Modell (DevOps oderDevOpsvereinfacht) ist, nicht ausgelöst, um Konflikte und Fehler zu vermeiden.
- Support-Wiederholungen mit GitHub Actions
  - Die erneute Ausführung fehlgeschlagener Aufgaben in GitHub-Aktions-Workflows wird jetzt beim Erstellen von Change-Anforderungen unterstützt.
  - Wiederholungen fehlgeschlagener Phasen vor, nach oder zum Zeitpunkt der Change-Erstellung werden unterstützt.
- Unterstützung für API_KEY für Jira Server: Die Authentifizierungsmethode API_KEY ist jetzt für Jira Server verfügbar und wird an der bereits für Jira Cloud vorhandenen Unterstützung ausgerichtet.
- Behalten Sie Verzweigungsdetails in der Pipeline-Ausführung bei, um Commits aus Artefakten und Paketen zu bestimmen
  - Der Pipeline-Ausführungstabelle wird jetzt eine neue Spalte hinzugefügt, um auf die Verzweigungstabelle zu verweisen und die Filterung nach Verzweigung zu ermöglichen, um sicherzustellen, dass die richtigen Commits einem Change zugeordnet werden, wenn Anwender gleichzeitig an mehreren Versionen eines Artefakts arbeiten.
  - Die Commit-Berechnungslogik für die Artefaktversion wurde erweitert, um nach Verzweigung zu filtern.
  - Die Commit-Zuordnungslogik für Pakete wurde geändert, um alle Commits anzuzeigen, die als Teil eines Pakets bereitgestellt werden, einschließlich der Commits aus früheren Artefaktversionen, die nicht bereitgestellt wurden, aber nur in derselben Verzweigung
- 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.

Neu:
- Unterstützung für die Integration von anwenderdefinierten Orchestration-Tools
  - Integrieren Sie DevOps Change-Geschwindigkeit mit einem beliebigen Orchestration-Tool, das nicht imBasissystem unterstützt wird.
- Verbesserte Behandlung von Onboarding-Fehlern und Schutzmaßnahmen
  - Zeigen Sie verbesserte Fehlermeldungen an, mit denen Sie die Ursache eines Problems beim Onboarding (Verbindung, Erkennen, Konfigurieren oder Importieren) eines Tools finden können.
- Change-Anforderungserstellung mit Fehlern beim DevOps-Datenabruf
  - Aktivieren Sie die Erstellung von Change-Anforderungen, auch wenn beim Abrufen der DevOps-Daten in einer Pipeline ein Fehler auftritt.
- Support für GitLab-Merge-/Pull-Anforderung
  - Verwalten Sie Abrufanforderungen für GitLab-Pipelines für die GitLab-Codierungsquelle aus ServiceNow DevOps.
- JFrog Artifactory-Unterstützung für GitHub Actions, Azure DevOps und GitLab
  - Importieren Sie die in JFrog Artifactory veröffentlichten Artefaktdaten für GitHub Actions-, Azure DevOps- und GitLab-Pipeline-Ausführungen.
- Mehrere ServiceNow DevOps-Konfigurationen in derselben Jenkins-Instanz
  - Konfigurieren Sie mehrere ServiceNow DevOps-Verbindungen in einem Jenkins-Server.
Geändert:
- Unterstützung für Jira Cloud
  - Onboarding von Jira Cloud in DevOps Change-Geschwindigkeit zusätzlich zu Jira On-Premises.
- Verbesserungen des GitLab-Docker-Containers
  - Rufen Sie Details einer Change-Anforderung ab, die einer GitLab-Pipeline zugeordnet sind, und veröffentlichen Sie Komponententestergebnisse. Die automatische Aktualisierung des Abschlusscodes basierend auf dem Gesamtstatus der Pipelineausführung für einfache GitLab-Pipelines wird ebenfalls unterstützt.
- Verbesserungen des DevOps-Arbeitsbereichs
  - Das Modul „Tools“ verfügt jetzt über drei Listengruppen: „Alle“, „Status“ und „Fähigkeit“.
  - Die Funktionen „Testergebnisse“ und „Softwarequalität“ sind jetzt im Listenmodul verfügbar, um die Navigation zu erleichtern.
  - Im Abschnitt „My Lists“ (Meine Listen) können Sie eigene Listen erstellen.
  - Systemintegrität, Integrationen und Erweitert (früher als Problembehandlung bezeichnet) sind jetzt im Administratormodul verfügbar.
- Verbesserungen von DevOps-Einblicken
  - Verwenden Sie das Dashboard „Einblicke“ im DevOps-Arbeitsbereich als Teil von Next Experience mit neueren und relevanteren Indikatoren/Widgets wie der Erfolgsquote von Bereitstellungen und fehlgeschlagenen Bereitstellungen sowie Schutzmaßnahmen und besserer Filterung.
  - DevOps Standard Insights auf der Plattform ist für alle neuen DevOps-Anwender veraltet.
  - Plattformbenutzer (Datensatzersteller) werden jetzt zum Arbeitsbereich weitergeleitet, um Tools oder Apps zu erstellen. Release-/Legacy-Anwender können weiterhin direkt zur Plattform-URL wechseln, um über die Optionen „Neu erstellen (Legacy)“ und „App erstellen (Legacy)“ Tools oder Apps in der Plattform zu erstellen.

Neu:
- Integration von GitLab mit Docker-Container
  - Die Integration von GitLab in ServiceNow DevOps wurde durch den Docker-Container vereinfacht, der in DockerHub veröffentlicht wird. Dies unterstützt die Erstellung von ServiceNow DevOps-CHGs, die SonarQube-Integration in GitLab-Pipelines und die Registrierung von Artefakten und die Paketerstellung mit ServiceNow DevOps.
- 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.
- Verbesserte Protokollierung und Behandlung von Fehlern mit ServiceNow DevOps-Erweiterungen
  - ServiceNow DevOps-Erweiterungen, die für anwenderdefinierte GitHub-Aktionen, Jenkins-Plugins und ADO-Erweiterungen veröffentlicht wurden, verfügen jetzt über eine verbesserte Fehlerprotokollierung und -behandlung, um die Fehlerbehebung zu erleichtern.
- 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.
- Fehlerbehandlung für DevOps-Change-Anforderungs-Flows geändert
  - Sie können Fehler, die einer Change-Anforderung entsprechen, in den Arbeitsnotizen der Change-Anforderung und in den Konsolenprotokollen des Pipeline-Tools anzeigen, wenn eine Geschäftsregel oder Datenrichtlinie beim Aktualisieren eines Change in Manuelle Genehmigung für DevOps-Change-Anforderung, DevOps-Change-Anforderung ein Problem verursacht Flows für minimale Automatisierungsgenehmigung oder „DevOps-Change-Anforderung für erweiterte Automatisierungsgenehmigung“.
- 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.
- Verbesserungen bei der Verarbeitung von GitLab-Benachrichtigungen
  - Die Skalierbarkeit wurde durch die nahtlose Verarbeitung von GitLab-Ereignissen verbessert.
- Ä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:
- Minimale automatisierte DevOps-Change-Genehmigung.
- Studio-Unterstützung für DevOps Change-Geschwindigkeit.
Geändert:
- Bestehende DevOps-Change-Flows wurden entsprechend umbenannt.

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.

Änderungen:
- Support für Azure DevOps-Organisationen
  - Verbinden Sie ein Tool direkt auf Organisationsebene mit Azure DevOps. Projekte innerhalb der Organisation werden automatisch erkannt. Sie können Webhooks für mehrere Projekte gleichzeitig konfigurieren und die Anmeldeinformationen einfach auf Organisationsebene aktualisieren. Dadurch entfällt die Notwendigkeit, ein Tool pro ADO-Projekt zu verbinden.
- Gruppenzugriff für Tools und Anwendungen
  - Steuern Sie den Zugriff auf Tools und Anwendungen, indem Sie dem Feld Verwaltet von Benutzergruppen hinzufügen. Anwender, die zu den hinzugefügten Gruppen gehören, können nur auf dieses Tool oder diese App zugreifen und sie nur bearbeiten, wenn ihre Rollen dies zulassen. Eine neue Rolle, DevOps-Tool-Besitzer, wurde eingeführt. Anwender mit dieser Rolle können nur Tools verbinden und haben keinen Zugriff auf zusätzliche DevOps-Administratorfunktionen wie Systemeigenschaften.
- Ruft Pipelineschritte beim Zuordnen zu einer App automatisch ab
  - Beim Zuordnen einer Pipeline zu einer App werden die Pipelineschritte auch während des Imports abgerufen. Es ist nicht mehr erforderlich, eine Pipeline einmal auszuführen, damit die Schritte in ServiceNow DevOps zugeordnet werden.
- Fehlermeldungen geändert
  - Unter Eingehende Ereignisse und Importanforderungen werden Fehlermeldungen angezeigt, um die Ursache eines Problems für Echtzeitbenachrichtigungen zu ermitteln. Fehlermeldungen identifizieren relevante aktive Probleme, heben bestimmte Probleme hervor und erläutern, wie sie entschärft werden können.
- Benachrichtigung über Ablauf der Anmeldeinformationen
  - Administratoren und Toolbesitzer werden benachrichtigt, wenn Tool-Anmeldeinformationen ablaufen oder bald ablaufen. Sie werden per E-Mail, UR-Aufgabe, Benachrichtigungssymbol und durch eine Nachricht im Tooldatensatz benachrichtigt. Dies verhindert Datenverlust.
- Letztes empfangenes Ereignis
  - Benachrichtigen Sie DevOps-Administratoren beim letzten Empfang von Ereignissen, um sie vor möglichen Problemen zu warnen, die bei ihrer Toolverbindung auftreten könnten. Das Feld „Letztes empfangenes Ereignis“ im Tooldatensatz hilft bei der einfachen Behebung von Verbindungsproblemen. Sie können die Anzahl der Tage festlegen, für die warnende oder kritische Warnungen im Feld Letztes Ereignis empfangen im Tooldatensatz angezeigt, wenn keine Ereignisse empfangen wurden.
- Change-Status wird protokolliert, während in der Pipeline die Entscheidung zur Fortsetzung der Ausführung aussteht:
  - Change-Informationen wie Change-Nummer, Status, Zuweisungsgruppe, Genehmiger, geplantes Start-/Enddatum werden in den Konsolenprotokollen von Jenkins- und GitHub-Aktionen angezeigt, während die Pipeline/der Workflow zur Genehmigung des Change 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.

Behoben:

GitHub: Die Aktion „Erkennen“ schlägt fehl, wenn ein bereits erkanntes Repository in GitHub gelöscht wird.
Anwender mit der Rolle „sn_devops.viewer“ aus DevOps Change können den Link zum DevOps Config-Arbeitsbereich sehen.
SonarQube/SonarCloud: In einer Change-Anforderung wird der Zusammenfassungsdatensatz zur Nicht-Admin-Softwarequalität vom nächsten Datensatz überschrieben, anstatt einen neuen Zusammenfassungsdatensatz zu erstellen.
Die Change-Erstellung schlägt fehl, wenn Datenrichtlinien für Change-Attribute vorhanden sind.
Die Standardansicht der zugehörigen Liste „Change-Anforderung“ kann nicht bearbeitet werden, wenn DevOps Change-Geschwindigkeit installiert ist.
Azure DevOps: Wenn der Schritttyp nicht „Prod-Bereitstellung“ ist, zeigen die zugehörigen Listen „Arbeitselement“ und „Commits“ für den Change falsche Einträge an.
Jira: Doppelte Arbeitselemente werden erstellt, wenn ein Problem unmittelbar nach der Erstellung aktualisiert wird.
Anwender mit der Rolle „DevOps-Betrachter“ können nicht auf KPI-Analysen für alle Einblicke-Widgets im Arbeitsbereich zugreifen.
Wenn ein Commit in DevOps verarbeitet, in DevOps gelöscht und dann erneut aus GitHub committet wird, werden die Committer-Details für den Commit nicht beibehalten.
Falsche Anzahl von Tests, die im Widget „Anwendungsaktivität der letzten 30 Tage“ angezeigt werden.

Geändert:
- Verbesserte Fehlerbehandlung und Schutzmaßnahmen
- Verbesserte Fehlermeldungen, um die Ursache eines Problems beim Onboarding (Verbindung, Erkennen, Konfigurieren oder Importieren) eines Tools zu ermitteln. 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. Toolverwaltung geändert, mit der Sie auf einfache Weise Anmeldeinformationen für jedes Tool aktualisieren und 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.

Änderungen:

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-Nachverfolgbarkeit von Commits, Verzweigungen, Tags und Pipelines (CI und 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
Das Dashboard für DevOps-Einblicke kann jetzt nach Geschäftsanwendung filtern
Für die Jenkins-Integration wird mindestens Version 2.289.1 unterstützt

Behoben:

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 zufällig in einen 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.

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. Die Workflow-Ausführung von GitHub-Aktionen wird 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 historischen ADO-Artefakten:

Importieren Sie Verlaufsdaten für ADO-Artefakte, indem Sie den Selfservicekatalog für App-Onboarding verwenden und regelmäßig abfragen, um die 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 und helfen so, die Ursachen und Bereiche mit Verbesserungspotenzial zu identifizieren

Risikoeingaben und Ablehnungsgründe für die Richtlinie für die sofort einsatzbereite Change-Genehmigung:

Die standardmäßige DevOps-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.

Arbeitsbereich für DevOps-Onboarding:

Das Onboarden eines Tools (das Herstellen einer Verbindung mit einem Tool) ist eine Herausforderung, da es mehrere getrennte Schritte umfasst und mehrere Personas umfassen kann. Der Arbeitsbereich führt Sie durch den Onboarding-Prozess, um Ergebnisse der Change-Automatisierung zu ermöglichen. Der Arbeitsbereich für Selfservice. Mit diesem Release können Sie das Onboarding der Tools Azure DevOps, Jira, GitHub und Jenkins problemlos durchführen.

DevOps-Einblicke-Modul im -Arbeitsbereich:

Flow-Metriken, die den Wert der geleisteten Arbeit zeigen.

Zykluszeiten, Durchsatzverteilung, geplante Flow-Zeit für Bereitstellung und Beträge in Arbeit.

Neue Change-Beschleunigungsmetriken, die sich auf den Pfad zur Automatisierung konzentrieren.

Automatisierte vs. manuelle Changes, angewendete Change-Richtlinienentscheidungen, ROI

Zu den aktualisierten Filterfunktionen gehören Service, Configuration Item, Produkte und Nach Datum.

Zeigen Sie mit einem neuen Registerkartendesign Detailinformationen zu den erfassten Daten an, damit Sie im Arbeitsbereich bleiben.

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 wurden 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).
  - Es werden Vernichtungsregeln 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

DevOps Versionshinweise zur Change-Geschwindigkeit

Store-Versionshinweise

DevOps Versionshinweise zur Change-Geschwindigkeit

Versionsverlauf