ServiceNow Plattform-Engineering - Warum die klassischen DevOps-Tools nicht anwendbar sind

Klassische DevOps-Konzepte und -Werkzeuge wurden für dateibasierte Codebasen entwickelt und konzentrierten sich auf einen Entwicklungsstapel, der sich grundlegend von der paketierten Plattformarchitektur von ServiceNow (sowie von vielen anderen Plattformen wie z. B. Salesforce) unterscheidet. Um dies besser zu verstehen, finden Sie hier einen detaillierten historischen und technischen Überblick über DevOps, seine Kernkonzepte und Komponenten und wie sich die Dinge in ServiceNow DevOps unterscheiden. Die gute news ist, dass es einen nativen Weg gibt, die gleichen großen Vorteile in ServiceNow zu erreichen, nur auf eine etwas andere Weise. Wie auch immer, lassen Sie uns eintauchen.

Geschichte von DevOps

Der Begriff DevOps wurde von Patrick Debois im Jahr 2009 geprägt, als er die ersten DevOpsDays in Gent, Belgien (wo er lebte), ins Leben rief. Patrick wurde zuvor von der Präsentation "10 Deploys per Day: Dev and Ops Cooperation at Flikr" von John Allspaw und Paul Hammond auf der Velocity-Konferenz 2009. Ironischerweise war Patrick nicht auf dieser Konferenz, ließ sich aber von ihrer Präsentation inspirieren, organisierte die erste DevOps-Konferenz und prägte so den Begriff.

Die Vorgeschichte zu 2009 ist, dass Patrick und Andrew Schafer 2008 die einzigen Teilnehmer einer "Gleichgesinnten"-Sitzung waren, die sich mit der Anwendung agiler Prinzipien auf die Infrastruktur beschäftigte. Obwohl sie zu diesem Zeitpunkt die einzigen waren, die Interesse zeigten, trugen Patrick und Andrew ihre Gedanken zusammen und gewannen schnell eine Anhängerschaft, zu der auch John Willis gehörte. Die Zusammenarbeit zwischen diesen Gleichgesinnten bereitete Patrick darauf vor, den nächsten evolutionären Schritt zu tun (was ihm intuitiv erschienen sein muss) und DevOps zu prägen.

Was genau ist DevOps?

Die oben skizzierte kurze Geschichte zeigt hoffentlich, dass DevOps eine Philosophie ist, die sich aus jahrzehntelanger Erfahrung und Lernen beim Schreiben, Bereitstellen und Unterstützen von Code entwickelt hat. DevOps umfasst Agile, Continuous Integration und Continuous Delivery-Praktiken und -Vorschriften. Die Einführung von DevOps erfordert oft eher einen Kulturwandel in Unternehmen als die Anschaffung spezieller Tools. Aus diesem Grund ist ein großes Ökosystem von Tools, ISVs und Beratern entstanden, die support DevOps-Einführung und -Umstellung unterstützen.

Wenn Sie zehn Personen nach der Definition von DevOps fragen, werden Sie wahrscheinlich zehn verschiedene Antworten erhalten, auch wenn ihre Antworten gemeinsame Elemente und Themen aufweisen. Für die Zwecke dieses Artikels werde ich DevOps wie folgt definieren: DevOps ermöglicht es kleinen Teams, unabhängig voneinander Code zu entwickeln, zu testen und schnell, sicher und zuverlässig für Kunden bereitzustellen, während diese Teams gleichzeitig in der Lage sind, schnell und sicher auszufallen. Die meisten in der DevOps-Gemeinschaft sprechen über schnelles Versagen, aber meiner Erfahrung nach ist sicheres Versagen wichtiger als schnelles Versagen allein. Produktionsausfälle in der Finanzdienstleistungs- oder Gesundheitsbranche können schwerwiegende Folgen haben.

DevOps-Werkzeuge

Wie bereits erwähnt, gibt es ein Ökosystem von Tools, Anbietern und Beratern auf dem DevOps-Markt. DevOps-Tools haben sich auf der Grundlage jahrzehntelanger Erfahrung entwickelt, um die Herausforderungen und Anforderungen an die Zusammenarbeit mehrerer Entwickler und Teams zu bewältigen, die Code in mehreren Dateien schreiben und speichern. Die Verwaltung der unzähligen Änderungen in unzähligen Dateien und Zeilen innerhalb dieser Dateien war eine echte Herausforderung.

DevOps-Tools, die die Planung und Verfolgung von User Stories ermöglichen, sind wertvoll für die Anwendung von DevOps auf die Entwicklung von ServiceNow . CI/CD-Tools sind jedoch ungeeignet, da sie für die Herausforderungen von dateibasierten Anwendungen konzipiert wurden. Bei einer plattformbasierten Anwendung sind Sie jedoch nicht Eigentümer des überwiegenden Teils des Codes, und Ihr Code wird nicht nativ in Dateien verwaltet.

CI/CD für ServiceNow?

Versionskontrolle
Versionskontrollsysteme (VCS) wie git sind großartige Werkzeuge für die Verwaltung von Änderungen an mehreren Dateien durch mehrere Personen. VCS eignen sich jedoch nicht für die Verwaltung von ServiceNow XML-Dumps, da die exportierten XML-Dateien serialisierte Systemdumps sind, die plattformspezifische Datenelemente enthalten. ServiceNow XML-Dateien können zwar von Menschen geschriebenen Code enthalten, aber oft wird der von Ihnen geschriebene Code nicht wirklich exportiert. Stattdessen werden nur die Datensatzlokatoren, die auf Ihren Code verweisen, exportiert. Wenn Sie einen Aktualisierungssatz importieren, ruft ServiceNow den Code von der entfernten Instanz ab. Letzten Endes werden die XML-Dateien von ServiceNow von der Plattform für die Plattform erstellt.

Die Vorteile des Zusammenführens von Zweigen, die XML-Dumps enthalten, werden zunichte gemacht, da sich die GUIDs, SYS IDS, Hash IDs und Hunderte anderer systemabhängiger Deklarationen zwischen den Instanzen von ServiceNow immer unterscheiden werden. Darüber hinaus gehen VCS davon aus, dass es einen Master-Zweig gibt - die endgültige Version der Wahrheit, mit der alle Zweige letztlich abgeglichen (zusammengeführt) werden müssen.

Dieses Konzept gibt es in ServiceNow nicht wirklich. Das, was einem Master-Zweig in ServiceNow am nächsten kommt, ist Ihre PROD-Instanz. Es macht keinen Sinn, Ihre gesamte PROD-Instanz in ein VCS zu exportieren und von dort aus Zweige zu erzeugen, denn die unvermeidliche Konfliktlösung, die stattfinden muss, wird später in Ihrer PROD-Instanz stattfinden, NICHT in einem VCS. Und wie würden Sie die Konflikte zwischen all den vom System erzeugten Daten überhaupt in Einklang bringen?

Wenn Sie von einem Ihrer ServiceNow Spezialisten verlangen, ein weiteres Tool wie Git oder ein anderes VCS zu erlernen und dann zwischen den beiden Tools zu wechseln, führt dies zu Produktivitätsverlusten. Untersuchungen zeigen, dass die Produktivität derjenigen, die den Kontext wechseln, im Durchschnitt um 40 % sinkt, verglichen mit denjenigen, die dies nicht tun. ServiceNow Fachleute sehen sich aufgrund der gestiegenen Nachfrage bereits mit einem wachsenden Rückstand konfrontiert. Warum sollte man die Vorlaufzeit bis zur Lieferung verlängern, indem man von ServiceNow Spezialisten verlangt, ein neues Tool zu erlernen, das für ihre Arbeit nicht geeignet ist?

CI & CI Tools
Unter Continuous Integration (CI) versteht man die kontinuierliche Integration oder Zusammenführung von Codeänderungen, die von einzelnen Softwareentwicklern vorgenommen werden. CI ist eine gängige Praxis in modernen, leistungsstarken Softwareentwicklungsunternehmen. Es gibt viele CI-Tools, wie Jenkins, GitLab und Travis CI, um nur einige zu nennen. Mit CI können Sie sowohl die Anzahl der Mitarbeiter als auch die Leistung der Entwicklungsteams erhöhen. CI ermöglicht es mehreren Entwicklern, unabhängig voneinander und parallel an Funktionen zu arbeiten. Wenn sie bereit sind, ihre Funktionen in den Hauptzweig (Endprodukt) einzubringen, können sie dies unabhängig voneinander tun und erhalten schnelles Feedback über den Erfolg oder Misserfolg der von ihnen vorgenommenen Codeänderungen.

Es besteht ein Unterschied zwischen KI als Praxis und KI als Werkzeug(e). Bei dateibasierten Anwendungen ist CI entscheidend für die Zusammenführung der Änderungen mehrerer Entwickler zu einem interoperablen Ganzen. Das Ende für dateibasierte Anwendungen ist der Master-Zweig. Bei ServiceNow ist der Master-Zweig Ihre PROD-Instanz, die Sie in der Regel klonen, um den Entwicklern eine Entwicklungsumgebung environment zur Verfügung zu stellen. Da CI-Tools extern zu ServiceNow sind, was gibt es da zusammenzuführen? Sie können einige Update-Sets, Daten, Anwendungen und andere ServiceNow Elemente exportieren, aber nicht alle ServiceNow Elemente können exportiert werden. Wie bereits erwähnt, ist der meiste Code in den exportierten XML-Dateien systemgeneriert.

ServiceNow verfügt über eingebaute Mechanismen, um Änderungen von einer Instanz in eine andere Instanz zu verschieben oder zu migrieren. ServiceNow warnt auch vor Konflikten zwischen zwei oder mehreren Bereitstellungen. VCS sind nicht in der Lage, eine vergleichbare Erfahrung für ServiceNow zu bieten, da sie nicht nativ für ServiceNow sind und eine unnötige bidirektionale Konvertierung erforderlich ist. Diese Konvertierung ist mit zusätzlichem Aufwand verbunden, ohne dass ein klarer Nutzen oder eine Verbesserung des Produktivitätsdurchsatzes zu erkennen ist.

Code Reviews
Das Konzept der Code Reviews gab es schon lange vor DevOps und CI/CD. Code-Reviews sind ein manueller Gate-Check für Codeänderungen, bevor sie in den Stammzweig eingebunden werden. Der Zweck von Code-Reviews besteht darin, Qualität und Sicherheit zu gewährleisten, indem Entwickler daran gehindert werden, Fehler zu machen, die mit der Arbeit in Silos verbunden sind. Außerdem kann so sichergestellt werden, dass die Codierungsstandards und bewährten Verfahren für jedes Projekt eingehalten werden. Einige Tools können den Code automatisch scannen, um die Konformität mit den Best Practices der Syntax zu gewährleisten und potenzielle Risiken aufzuzeigen.

Aber was genau überprüfen Sie, wenn es um ServiceNow geht? Die Plattform repräsentiert oder generiert 99 % der Codebasis für eine Anwendung oder ein Update-Set. Sie sind weder Eigentümer dieses Codes, noch sind Sie für dessen Pflege verantwortlich. Außerdem sind die XML-Dateien, die Sie vermutlich überprüfen würden, eine schwindelerregende Sammlung von TL;DR serialisierten Token, Tags und IDs. Die XML-Dumps von ServiceNow wurden für die Aufnahme durch die Plattform konzipiert - der Mensch war nicht als Konsument vorgesehen. Die Durchführung von Code-Reviews für den Code von ServiceNow ist wenig sinnvoll.

Schlussfolgerung

Das Leitprinzip bei dem Versuch, die Entwicklung und Migration von ServiceNow "DevOps" zu gestalten, sollte nicht einfach darin bestehen, DevOps-Tools anzuwenden. Dieser Ansatz entspricht der klassischen Redewendung, dass man versucht, einen eckigen Pflock in ein rundes Loch zu stecken. Das Erzwingen von dateibasierten Werkzeugen für plattformbasierte Funktionen wird die Probleme, die Sie eigentlich zu lösen versuchen, verschlimmern und verstärken.

Stellen Sie sich vor, Sie wenden Werkzeuge und Techniken, die für Verbrennungsmotoren gedacht sind, auf ein Elektrofahrzeug an. Bestimmte Konzepte und Grundsätze für die Wartung von Fahrzeugen lassen sich auf die Wartung von Elektroautos übertragen, nicht aber die spezifischen Tools und Rezepte. Die Herausforderung, vor der wir als DevOp-Praktiker und ServiceNow Fachleute stehen, besteht darin, die DevOps-Philosophie nicht mit den DevOps-Tools zu verwechseln. ServiceNow DevOps muss die systemeigenen Funktionen und Fähigkeiten von ServiceNow zusammen mit den DevOps-Prinzipien einbeziehen, nutzen und Vorteile daraus ziehen, um DevOps- und CI/CD-Ergebnisse zu erzielen.