Das ist die ServiceNow DevOps Pipeline, Dummkopf

Viele ServiceNow Kunden denken, sie hätten ein "Code-Qualitäts"-Problem, obwohl sie in Wirklichkeit ein "ServiceNow DevOps"-Problem haben. Hier ist der Grund dafür.

‍

Wenn die Nachfrage aus dem Unternehmen wächst und die Entwicklung von ServiceNow in der Organisation zu skalieren beginnt, führt die Verantwortung der Kernplattformteams, eine sichere Produktionsfreigabe zu gewährleisten, zu strengeren QS- und Freigabeanforderungen für die Überführung neuen Codes von der Entwicklung durch die Testinstanzen. Und schließlich in die Produktion. Zu diesen Anforderungen gehören in der Regel mehrere Code-Reviews, Funktionstests, Integrationstests und ein offener Slot für eine geplante Produktionsfreigabe. Der langwierige Prozess verlangsamt alles, ist aber eine notwendige Barriere gegen ernsthafte Probleme. Wenn man die isolierte Natur der ServiceNow Entwicklung* hinzufügt, wird der Engpass des Freigabeprozesses immer größer, was zu Rückstandsproblemen für das Unternehmen und scheinbaren "Qualitäts"-Problemen für die Plattformbesitzer führt. Tatsächlich ist der Prozess, Änderungen schnell genug in die Produktion zu bringen, ineffizient und sie sind nicht in der Lage, Änderungen zwischen den Teams gleichzeitig zu synchronisieren, was viele der scheinbaren "Code"-Probleme, mit denen sie derzeit konfrontiert sind, vermeiden würde.

‍

Der Grund dafür ist, dass viele Probleme wie Kollisionen, komplexe Abhängigkeiten und Ordnungsprobleme einfach dadurch entstehen, dass Code zu lange in Sub-Prod-Instanzen stecken bleibt, während verschiedene Teams nichts von den Änderungen in der Pipeline mitbekommen, weil sie auf ServiceNow weiter an neuerem Code arbeiten.

‍

Aber bitte verstehen Sie mich. Codequalität und Codierungsstandards sind an und für sich wichtig. Wenn jedoch die Pipeline-Probleme nicht zuerst gelöst werden, ist hochwertiger Code zeitlichen Problemen ausgesetzt, da Abhängigkeiten nicht frühzeitig gelöst werden können und sich immer mehr potenzielle Probleme auftürmen, je länger er in der Pipeline verweilt. Die Lösung liegt natürlich in der Integration von Scans und Prüfungen der Codequalität in die Auslieferungspipeline Ihrer Update-Sets und Anwendungen. Doch ohne Automatisierung der Pipeline kommen Sie nicht weiter.

‍

ServiceNow ist die robusteste Plattform für die schnelle Erstellung von Geschäftsanwendungen, aber aufgrund ihrer grundlegenden Multi-Instanz-Architektur auch sehr anfällig für diese Art von Problemen. ServiceNow macht es einfach, auf jeder Instanz zu bauen. Es macht es einfach, Änderungen von einer Instanz zu einer anderen zu verschieben, indem man Update-Sets und skalierte Anwendungen verwendet, aber wenn Ihr Fußabdruck wächst und mehr Teams und mehr Instanzen eingerichtet werden, wird der Bedarf an Automatisierung, Echtzeit-Synchronisation und einem integrierten Code-Qualitäts- und Sicherheitsprozess zu einer Notwendigkeit - kurz gesagt, was Sie brauchen, ist intelligentes ServiceNow DevOps. Allerdings bedeutet der Aufbau eines intelligenten ServiceNow Devops-Betriebs nicht, dass Sie den traditionellen DevOps-Weg gehen müssen. Meiner Meinung nach ist genau das der Grund, warum Sie das nicht tun sollten. Da es sich bei ServiceNow um eine geschlossene environment handelt, ist es am besten, native ServiceNow Devops-Fähigkeiten aufzubauen, mit Hilfe von Tools wie xtypedie Ihnen dabei helfen, ServiceNow Bereitstellung und Freigabe zu automatisieren, eine wichtige Säule in Ihrer ServiceNow DevOps-Strategie.

‍

Ich kann Ihnen gar nicht sagen, wie oft ich mit Kunden gesprochen habe, die ihr Problem als Qualitätsproblem identifizierten, obwohl sie ein DevOps-Problem hatten. Die gute news ist, dass dies mit dem richtigen Fokus und Aktionsplan schnell behoben werden kann. Sobald Sie Ihren Prozess automatisieren, wird die Qualitätsverbesserung viel pragmatischer und datengesteuerter, als wenn Sie versuchen, einem fehlerhaften und manuellen Vorgang bessere Codierungsstandards aufzuerlegen.

‍

*In ServiceNow ist jede Instanz von allen anderen Instanzen isoliert. Es gibt keine eingebaute Synchronisation zwischen den Instanzen und keine gemeinsame Code-Basis. Sie entwickeln in einem "Walled Garden", der sich ständig von der Basislinie und allen anderen Instanzen entfernt, da sich die Änderungen an der Basislinie häufen und Sie schließlich alle paar Monate einen Klon erstellen müssen.