3 Gründe, warum CI/CD-Integrationen Ihr ServiceNow Backlog nicht adressieren können

Wir alle sind mit Continuous Integration (CI) vertraut - der Praxis des Zusammenführens (oder Integrierens) von Quellcode-Änderungen, die von Entwicklern mehrmals am Tag in ein fertiges Projekt vorgenommen werden. Integration" ist hier das Schlüsselwort - und es hilft zu erklären, warum die Anwendung von CI-Tools auf ServiceNow so kompliziert ist. Um zu verstehen, warum das so ist, sollten wir zu den Grundlagen zurückkehren und mit dem Versionskontrollsystem (VCS) beginnen. Werkzeuge wie Git helfen Ihnen, Ihre Quellcodedateien zu verwalten, Änderungen von Entwicklern zusammenzuführen und Konflikte zu bewältigen. Wenn Sie mehrere VCS-Änderungen pro Tag als Teil des CI-Prozesses übertragen, wird ein vorgeschriebener Arbeitsablauf in Gang gesetzt (siehe Abbildung 1). Der automatisierte Workflow erkennt Konflikte, erstellt Binärdateien, führt Post-Build-Tests durch und stellt die Anwendung auf einer CI environment bereit. Danach setzt die CD-Pipeline ein und umfasst eine Reihe von Testautomatisierungsaufgaben.

Bei jedem Schritt gibt es Überprüfungen. Wenn ein Problem auftritt, schlägt der CI-Build fehl und wird zur Fehlerbehebung an die Entwickler zurückgegeben. Warum also versagt dieser CI-Prozess bei der Bearbeitung des ServiceNow Backlogs? Untersuchen wir drei Fehler, die Menschen bei der Anwendung von CI/CD in ihrem ServiceNow environment machen.

Fehler Nr. 1: Sie gehen davon aus, dass ein CI-Tool die Bereitstellung Ihres ServiceNow Backlogs beschleunigen wird.

Was ist an dieser Annahme falsch? Schließlich sind die oben beschriebenen Tools darauf ausgelegt, Ihren CI-Workflow zu automatisieren.

Hier liegt das Problem. In ServiceNow sind viele dieser CI-Automatisierungsprozesse im Kontext von ServiceNow überflüssig. Wenn beispielsweise Git oder ein anderes VCS-Tool Konflikte identifiziert, welche Konflikte werden dann identifiziert? Klassischerweise erkennen VCS-Werkzeuge Konflikte in Quellcode-(Text-)Dateien. Der Quellcode ist der Grundbaustein für dateibasierte Anwendungen, so dass es wichtig ist, Konflikte zu erkennen, bevor der Code in Binärdateien umgewandelt wird. Bei Plattformen wie ServiceNow ist die Plattform selbst der Baustein für Ihre kodierten Funktionen, Anpassungen, Konfigurationen oder Anwendungen. Die Identifizierung eines Konflikts in einem ServiceNow Export (XML-Datei) ist nicht gleichbedeutend mit der Identifizierung eines Konflikts zwischen Update-Sets in zwei Instanzen.

Automatisierte Binärtests? Für ServiceNow werden keine Binärdateien erstellt, daher ist dieser klassische CI-Automatisierungsschritt unnötig. Das Testen auf Anwendungsebene bezieht sich auf Ihre ServiceNow Anpassungen, Funktionen und Änderungen, aber warum sollten Sie diese Funktion einem CI-Tool überlassen, wenn ServiceNow bereits ein natives Automated Test Framework für diesen Zweck bietet? Täuschen Sie sich nicht: ServiceNow enthält so viele native Automatisierungs- und Testfunktionen, dass das Hinzufügen eines CI-Tools zusätzliche Verzögerungen, Overhead und Fachwissen bedeutet.

Irrtum Nr. 2: Sie denken, dass ServiceNow Exporte Quellcode sind.

Was ist an dieser Annahme falsch? Schließlich sind die oben beschriebenen Werkzeuge dazu gedacht, Ihren CI-Workflow zu automatisieren: news : Diese ServiceNow Exporte sind kein Quellcode. Ihre Exportdateien (XML) enthalten eine Reihe von maschinenspezifischen Kriterien, von GUIDs über Record Locators bis hin zu verschiedenen System-IDs und Tags. Diese IDs sind für jede Instanz eindeutig, was bedeutet, dass ein VCS-Tool Unterschiede zwischen Exportdateien fälschlicherweise entweder als neuen "Code" oder als geänderten "Code" erkennt, was beides nicht korrekt ist. Die XML-Dateien können so groß sein und so viele eindeutige Bezeichner enthalten, dass ein VCS wahrscheinlich Tausende von Konflikten erkennen wird, die nicht behoben werden müssen. Die XML-Exporte sind nicht für Menschen zum Lesen und Verstehen gedacht, sondern für eine ServiceNow -Instanz zur Interpretation. Der geplante Anwendungsfall für CI-Tools entspricht nicht der Realität von ServiceNow .

Ja, die Exporte von ServiceNow enthalten Ihre kodierten Funktionen, Anpassungen und Konfigurationen. Es sind jedoch nur einige von ihnen enthalten. Die XML-Dateien enthalten Datensatzlokatoren, die auf Ihren "Code" auf entfernten Instanzen verweisen. Ohne Zugriff auf diese entfernten Instanzen wird der Import der XML-Dateien fehlschlagen. Außerdem enthalten die Exporte von ServiceNow nicht alles, was Sie über die Instanzen hinweg migrieren möchten, z. B. Daten, Plugins, Plugin-Aktivierungen, Update-Sets, andere XML-Dateien und mehr. Wenn die XML-Exporte also nur einen Teil dessen enthalten, was Sie für die instanzübergreifende Migration benötigen, welchen Nutzen bieten dann die CI-Tools?

Fehler Nr. 3: Sie gehen davon aus, dass ein VCS für ServiceNow auf die gleiche Weise funktioniert wie für die dateibasierte Entwicklung.

Um dies zu erklären, sollten wir uns zunächst ansehen, was Sie in ein VCS einbringen. Für ServiceNow fügen Sie XML-Exporte hinzu - aber wie wir gesehen haben, decken diese nicht alles ab, was Sie brauchen, und die Exporte sind nicht mit Quellcode zu verwechseln. Dieser Unterschied bringt uns zu dem enormen Unterschied zwischen klassischem Software Engineering und Platform Engineering - und das ist ein Design-Bias, der in jedes CI-Tool eingebaut ist. In der traditionellen Softwareentwicklung haben Sie Ihre Quellcodedateien (Textdateien), die von den Entwicklern verfasst und geändert werden. CI-Tools gehen davon aus, dass es sich bei dem, was Sie bewegen und automatisieren, um eine Sammlung von Textdateien handelt, die zu Binärdateien oder versandfähigen Paketen kompiliert werden.

Die Plattformtechnik ist anders. Bei ServiceNow werden bis zu 98 % der Funktionalität, von der Ihre Funktionen, Anpassungen, Konfigurationen und Änderungen abhängen, bereits von ServiceNow innerhalb der Plattform bereitgestellt. Mit anderen Worten: Software besteht aus zwei Arten von High-Level-Code - Anwendungslogik und Geschäftslogik. Bei herkömmlicher dateibasierter Software müssen die Entwickler sowohl die Anwendungs- als auch die Geschäftslogik schreiben. Die Anwendungslogik ist der Code, der es der Software ermöglicht, mit dem Host-Ökosystem (Betriebssystem, Infrastruktur, Dateisystem, Datenbank usw.) zu interagieren. Bei ServiceNow ist die Anwendungslogik bereits Teil der Plattform, so dass sich die Entwickler auf die Erstellung von Geschäftslogik und Regeln konzentrieren können.

Da Sie bis zu 98 % des "Codes" für Ihre Unternehmenslösungen weder besitzen noch darauf zugreifen können, ist die Verwendung eines CI-Tools überflüssig. Die Funktionen, Anpassungen, Konfigurationen und Anwendungen, die Sie in ServiceNow entwickeln, setzen voraus, dass die Plattform eine robuste Reihe von Funktionen, Diensten und Möglichkeiten bietet.

xtype reduziert Ihren Rückstand drastisch

xtype wendet CI als eine Reihe von Prinzipien an, die an die nativen ServiceNow Assets und die sofort einsatzbereiten Funktionen angepasst sind. xtype verfolgt automatisch alle Update-Sets in Ihren ServiceNow Instanzen und ermöglicht es Ihnen, diese zu gruppieren, zu benennen und in einer Version zu veröffentlichen. Diese Releases werden dann automatisch an Ihre Produktionsinstanz(en) weitergeleitet, wobei die nativen ServiceNow Automatisierungsmechanismen zum Einsatz kommen.

xtype synchronisiert auch alle vorwärts migrierten Update-Sets rückwärts, so dass alle Sub-Prod-Instanzen über die neueste Version einer Änderung oder eines Hot-Fixes verfügen. Diese Synchronisationsschleife stellt sicher, dass die Entwickler stets mit den neuesten Updates arbeiten, was Konflikte und Fehlerbehebungen reduziert. Durch die Instanzsynchronisierung wird auch die Notwendigkeit des Klonens reduziert und die Zeit bis zur Nutzbarkeit nach einem Klonen verkürzt.

Um herauszufinden, wie xtype Ihrem Unternehmen helfen kann, den ServiceNow ROI zu erhöhen, den Rückstand bei der Bereitstellung zu verringern und die Produktivität zu steigern, besuchen Sie ServiceNow ROI & Value Calculator.