Die DevOps-Mentalität für ServiceNow Instanzen - Teil 2

In meinem letzten Blogeintrag mag es so ausgesehen haben, als ob ich wirklich auf Git herumgehackt hätte. Die Realität könnte nicht weiter von der Wahrheit entfernt sein. Git ist eine wertvolle Bibliothek für die Speicherung bestimmter ServiceNow Artefakte, aber ich weise auf die Einschränkungen hin, die Git bei der Bewältigung der grundlegenden Realitäten von ServiceNow SDLCs in Kombination mit plattformbasierten Anwendungsarchitekturen hat. In diesem Blog werde ich näher darauf eingehen, welche Fähigkeiten DevOps-Teams benötigen, um ihren Coding-Output zu maximieren.

‍

ServiceNow Ändert das Packaging Mashup

ServiceNow Anwendungen, Skripte und XML sind nicht die einzigen Assets, die an einer Produktionsbereitstellung beteiligt sind, und sie sind auch nicht die einzigen Dinge, die in einer CI/CD-Pipeline verfolgt werden müssen. ServiceNow Produktions-Pushes umfassen häufig Plugins, Plugin-Aktivierung, Datenladen, Skriptausführung und Update-Sets. Eine geeignete DevOps-Lösung für ServiceNow muss über all diese Dinge verfügen und sie in einem "bereitstellbaren" Paket organisieren, das die Produktions-"Nutzlast" darstellt.

Die Nutzung der nativen ServiceNow -Funktionen in allen Continuous-Delivery-Automatisierungsmechanismen bietet die beste support für die Aktivierung von Plugins, das Laden von Daten, die Ausführung von Skripten und die Bereitstellung von Anwendungen, Skripten und XML-Dateien. Die Implementierung von Automatisierungsmechanismen außerhalb von ServiceNow kann die Sichtbarkeit verringern und den manuellen Arbeitsaufwand erhöhen, da die Plattform die einzige Version der Wahrheit ist, die zählt.

‍

ServiceNow Freigaben - Synchronisierung vs. Zusammenführung

Das Zusammenführen von Änderungen aus mehreren Zweigen funktioniert recht gut für dateibasierte Anwendungen. Für die Entwicklung von ServiceNow -Apps funktioniert es einigermaßen gut, obwohl Sie das Zusammenführen und die Konfliktlösung außerhalb von ServiceNow erledigen müssen. Diese manuelle Arbeit in einem Tool außerhalb von ServiceNow ist keineswegs mühsam, aber könnte es nicht einen besseren Weg geben, der die architektonische Natur von ServiceNow berücksichtigt?  

In der DevOps-Philosophie ist schnelles, genaues und kontinuierliches Feedback eine der effektivsten Methoden, um die Sicherheit von Produktversionen zu erhöhen, die Codequalität zu verbessern und schnelle und häufige Versionen zu ermöglichen. Was wäre, wenn dieses Feedback über alle Sub-Prod-Instanzen hinweg automatisiert werden könnte? Stellen Sie sich vor, ein Entwickler nimmt eine Änderung in seiner Entwicklungsinstanz vor, überträgt sie an eine QA-Instanz und lässt diese Änderungen automatisch an alle anderen Entwicklerinstanzen zurücksynchronisieren. Durch diese Rücksynchronisierung werden die Änderungen sofort an andere Entwickler weitergegeben, Kollisionen bei der Codierung reduziert und die Codequalität erhöht, da jeder Entwickler kontinuierlich von einem Standard-"Image" ausgeht.

‍

ServiceNow Veröffentlichungen - Wissen ist die halbe Miete

Eine der größten Herausforderungen bei der Veröffentlichung von ServiceNow ist es, sich darüber klar zu werden, was in dieser Version enthalten sein wird. Es kostet viel Zeit und Mühe, Kalkulationstabellen zu prüfen, sich mit mehreren Entwicklern abzusprechen und die Qualität und Relevanz der Daten in den Kalkulationstabellen sicherzustellen, auf die Sie sich bei Ihrer Arbeit außerhalb der Arbeitszeit stützen. Es scheint undenkbar, wenn nicht sogar ein DevOps-Antipattern zu sein, dass all die CI/CD-Automatisierung in manueller und fehleranfälliger Arbeit gipfeln wird.

Viele Unternehmen geben einfach auf und klonen regelmäßig die Produktionsinstanzen, was oft zusätzliche ServiceNow Lizenzkosten verursacht. Wenn wir aber Sub-Prod-Instanzen automatisch zurücksynchronisieren können, dann sind wir auch in der Lage, eine übersichtliche und ständig aktualisierte view zu haben, welche Änderungen in welcher ServiceNow Instanz vorhanden sind und welches Änderungspaket für die Produktionsbereitstellung bereit ist.

Ganz gleich, welche DevOps-Tools Sie verwenden, sie haben ihren Platz und ihre angemessene Verwendung. Was ich befürworte, ist eine gründliche Reflexion über den Kontext und die Realitäten plattformbasierter Ökosysteme und die Verwendung des richtigen Werkzeugs für die richtige Aufgabe, anstatt blind ALLE dateibasierten App-Entwicklungswerkzeuge auf plattformbasierte Ökosysteme wie ServiceNow anzuwenden. Meines Erachtens ist eine Kombination aus traditionellen DevOps-Tools und nativen Anwendungen für ServiceNow , die die von mir beschriebenen Herausforderungen angehen, der beste Weg nach vorne.