Die DevOps-Mentalität für ServiceNow Instanzen - Teil 1
Es ist fast 15 Jahre her, dass der Begriff DevOps geprägt wurde, sich zu einer Bewegung entwickelte und dann zu einer philosophischen Praxis wurde, die den Nachteil von Agile verbesserte. Die Vorteile von DevOps müssen nicht extra erwähnt werden, aber ich frage mich, ob es nicht Zeit für eine weitere Verbesserung ist. IDC prognostiziert, dass in den nächsten drei Jahren 750 neue Anwendungen entwickelt werden. Angesichts der Fülle an Möglichkeiten, diese Anwendungen zu codieren, ist es wahrscheinlich, dass ein erheblicher Prozentsatz dieser Anwendungen auf Low-Code-, No-Code- oder Plattformen wie ServiceNow und Salesforce entwickelt werden wird. Die kategorische Annahme, dass traditionelle DevOps-Tools den Anforderungen von Plattformen wie ServiceNow und Salesforce genügen, um das DevOps-Nirwana zu erreichen, ist naiv und engstirnig. In diesen beiden Blogs möchte ich einige der Unzulänglichkeiten von DevOps-Tools bei der Unterstützung der Anwendungsentwicklung ServiceNow aufzeigen und einige Gedanken und Grundsätze für einen Weg in die Zukunft darlegen.
ServiceNow Instanzen - I Don't Git It
Git ist ein Open-Source-Versionskontrollsystem, das 2005 von Linus Torvalds für die Entwicklung des Linux-Kernels entwickelt wurde. Es eignet sich hervorragend für die Verfolgung von Codeänderungen und ermöglicht eine nicht-lineare Softwareentwicklung zwischen vielen Entwicklern. Codeänderungen können verwaltet, nachverfolgt und in einen Master-Zweig zusammengeführt werden, der dann freigegeben werden kann. Git eignet sich hervorragend für die dateibasierte Softwareentwicklung. Die bereitzustellende" Anwendung ist eine Sammlung von Dateien, die vorhandene Dateien auf dem Zielserver oder -container überschreiben. Was ist mit plattformbasierten Anwendungen, die mehr mit RDBMS-Systemen als mit Dateisystemen zu tun haben?
In einem typischen, stark vereinfachten Git-Workflow arbeitet ein Entwickler an einer separaten Kopie oder einem Klon des Masters, nimmt seine Änderungen vor und überträgt sie zurück an den Master, wo die Änderungen mehrerer Entwickler zusammengeführt werden. Die Herausforderung bei ServiceNow besteht darin, dass die Übergabe und Zusammenführung außerhalb von ServiceNow stattfindet und die Entwickler ihre Änderungen in separaten Instanzen kodieren. Eine ServiceNow Instanz repräsentiert ein Ökosystem, nicht ein Dateisystem. Code-Zusammenführungen auf Git stellen keine gleichwertige Zusammenführung in den einzelnen ServiceNow Instanzen dar, in denen die Entwickler arbeiten. Mit anderen Worten: Entwickler in einer Instanz haben keine Ahnung, wie die Plattform von Entwicklern in anderen Instanzen angepasst oder aktualisiert wurde.
ServiceNow Instanzen - Ökosysteme vs. Dateisysteme
Die jahrzehntelange Erfahrung hat dazu geführt, dass moderne Anwendungen in immer kleinere Komponenten aufgeteilt werden, so dass auch die Änderungen kleiner ausfallen können. Kleinste Änderungen verringern die Wahrscheinlichkeit von Ausfällen, erfordern kleinere Änderungsfenster (wenn überhaupt) und ermöglichen häufigere Aktualisierungen. Die Plattform ServiceNow ermöglicht Mikroänderungen, die ebenfalls häufig veröffentlicht werden können. Es gibt jedoch einen Unterschied zwischen einer plattformbasierten und einer dateibasierten Anwendungsarchitektur. Da ServiceNow so viele Dienste und infrastrukturelle Abläufe bereitstellt, ist die App-Entwicklung schnell. Das bedeutet aber auch, dass eine Codeänderung in einer plattformbasierten App mehr Bindegewebe hat als in einer dateibasierten.
Änderungen in einer Instanz von ServiceNow müssen schnell in andere Sub-Prod-Instanzen übertragen oder synchronisiert werden, da die Änderungen eines Entwicklers die Codierungsbemühungen eines Entwicklers in einer anderen Instanz erheblich beeinträchtigen können - vielleicht sogar deren Codierungsbemühungen zunichte machen, rückgängig machen oder duplizieren. Die Externalisierung dieser Änderungen und ihre Zusammenführung in einem System wie Git behebt dieses Problem nicht. Es verschlimmert die Situation und zwingt Entwickler oder Versionsverwalter dazu, einen Git-Bericht zu durchsuchen und mit dem abzugleichen, was auf der Zielinstanz vorhanden ist. Dieser Aufwand ist sehr mühsam und fehleranfällig. Die Einführung von mehr manueller und fehleranfälliger Arbeit ist das Gegenteil von dem, was ServiceNow DevOps zu erreichen versucht. Im Kern geht es bei der DevOps-Philosophie um Häufigkeit, Schnelligkeit und Effizienz.
Ich lade Sie auch ein, Teil 2 dieser Serie zu lesen, in dem ich erörtere, welche Fähigkeiten ServiceNow DevOps-Teams benötigen, um ihren Coding Output zu maximieren.
Verwandte Artikel
Die Bereicherung von I.T.-Jobs durch KI
Im Zuge des technologischen Fortschritts werden immer mehr Anwendungen der künstlichen Intelligenz (KI) in verschiedenen Branchen eingesetzt. Speziell der Bereich des Wissens
Der geschäftliche Nutzen von Platform Engineering für die ServiceNow Community
Mit der fortschreitenden Digitalisierung der Geschäftsabläufe steigt die Nachfrage nach Unternehmensanwendungen, die Arbeitsabläufe automatisieren, Kundenerlebnisse verbessern und die Produktivität steigern können.
Revolutionierung der ServiceNow Entwicklung ohne War Rooms: Wie xtype die Bereitstellungs- und Freigabeprozesse rationalisiert
In der schnelllebigen Welt der digitalen Transformation können manuelle und fehleranfällige Prozesse die Unternehmensleistung und -effizienz erheblich beeinträchtigen. Ein solcher