Verbesserung der ServiceNow DevOps Flow Metriken: Mittlere Zeit bis zur Erkennung

Verringerung der MTTD mit xtype

In der traditionellen Softwareentwicklung bezieht sich MTTD auf die Zeit, die vom Zeitpunkt der Übergabe des fehlerhaften Codes bis zur Entdeckung des daraus resultierenden Fehlers vergeht. Die Entwicklung von ServiceNow unterscheidet sich jedoch davon, da Update-Sets und Anwendungen in der Regel nicht an ein Versionskontrollsystem (VCS) übergeben werden. Stattdessen markieren die Entwickler ihre Update-Sets als "vollständig" oder als eine Anwendung, die für die Migration zu Ihrer QA/Test-Instanz bereit ist. Die meisten Unternehmen verfügen über ausgereifte Prozesse, die bei der Weitergabe von Änderungen an die Produktion für Sicherheit und Compliance sorgen. Wie kann die DevOps-Flow-Metrik von MTTD auf die Now-Plattform angewendet und verbessert werden? 

Ein typischer MTTD-Fluss

1. Ein oder mehrere Entwickler nehmen Änderungen in der Dev-Instanz vor
2. Die Änderungen werden in einem oder mehreren Update-Sets oder einer App erfasst
3. Die Update-Sets, Update-Set-Batches oder Anwendungen werden dann für die Migration auf eine Testinstanz geplant.
4. Das Testen erfolgt (manuell und automatisiert) in der Testabteilung, in der Fehler entdeckt und an die Entwickler zur Behebung weitergeleitet werden.

Strategien zur Verringerung von MTTD

Verschiebung des Fehlerbewusstseins nach links

Eine der Herausforderungen bei der Entwicklung auf der Now-Plattform besteht darin, dass die Sub-Prod-Instanzen anders aussehen als die Produktionsinstanzen und sich voneinander unterscheiden. Dieser Unterschied bedeutet, dass Vorschauprobleme und Fehler potenziell in jedem Update-Set oder jeder entwickelten App enthalten sind. Das Problem ist, dass die Entwickler von diesen Problemen erst nach Tagen oder Wochen erfahren, wenn ihre Arbeit auf die nächste Instanz migriert wird.

xtype löst environment Inkonsistenzen, indem nachgelagerte Änderungen vorgelagert synchronisiert werden. Diese Synchronisierung bedeutet, dass alle Sub-Prod-Instanzen so produktionsähnlich wie möglich sind und gleich aussehen. Die Entwicklung in replizierenden Instanzen verringert die Wahrscheinlichkeit, dass Vorschaufehler oder Abhängigkeitsprobleme überhaupt erst auftreten. Fehler, die zu dem Zeitpunkt auftreten, an dem ein Entwickler in seiner environment arbeitet und nicht Tage oder Wochen später in einer anderen environment.

Die Entdeckung von Vorschaufehlern oder Abhängigkeitsproblemen zum Zeitpunkt der Entwicklung verbessert die Qualität des produzierten Codes und verringert gleichzeitig den Zeitaufwand für die Behebung dieser Probleme im nachgelagerten Prozess. In diesem Fall ist MTTD praktisch augenblicklich, so dass ein Entwickler bei der Behebung von Fehlern auf dem Höhepunkt seiner Leistungsfähigkeit erwischt wird, da sie im Kontext der gerade durchgeführten Arbeit auftreten.

Migrieren Sie einen Aktualisierungssatz nach dem anderen

Sofern keine Abhängigkeiten bestehen, sollten Sie mit der Stapelaktualisierung von Sets oder der Migration einer Sammlung von Änderungen, die in einem Arbeitsblatt aufgeführt sind, nicht warten. Wenn Sie die Bereitstellung von Änderungen hinauszögern, verlängert sich der Fehlerbehebungsprozess, da die Entwickler Probleme außerhalb des Kontextes ihrer aktuellen Entwicklungsarbeit beheben müssen. Vergessen Sie nicht, dass die Entwickler nicht warten, nachdem ein Update-Set als "abgeschlossen" markiert wurde. Sie fahren mit der nächsten User Story fort.

Diese Verzögerung bedeutet, dass sie sich daran erinnern müssen, was sie vor Tagen oder Wochen getan haben, um ihre Bemühungen in den richtigen Kontext zu setzen. Außerdem müssen die Entwickler ohne Synchronisierung den Unterschied zwischen der Instanz, die sie gerade untersuchen, und der Instanz, auf der sie entwickelt haben, herausfinden. Environment Homogenität kann nicht vorausgesetzt werden, so dass Unterschiede untersucht und als Schuldige ausgeschlossen werden müssen.

Es ist einfacher, ein einzelnes Update-Set oder eine einzelne Anwendung zu beheben als eine ganze Liste von Änderungen. Wenn Sie eine Massenfreigabe per Tabellenkalkulation vornehmen, müssen Dutzende von Änderungen durchgesehen werden. Bei der Freigabe eines einzelnen Aktualisierungssatzes muss nur eine einzige Änderung untersucht werden (plus environment Inkonsistenzen). Die Verringerung der Anzahl der gleichzeitig freigegebenen Änderungen verkürzt die MTTD und die MTTR (mittlere Zeit bis zur Lösung).

xtype Kontrollierte Synchronisation reduziert MTTD

xtypeDie kontrollierte Synchronisierung ermöglicht es Entwicklern, Probleme proaktiv zu erkennen, während sie Code schreiben, und nicht erst Tage oder Wochen später. Außerdem wird sichergestellt, dass alle Sub-Prod-Instanzen so produktionsähnlich wie möglich sind, wodurch die Wahrscheinlichkeit von Fehlern bei der Bereitstellung verringert wird. Anders ausgedrückt: Wenn ein Fehler in einer Sub-Prod-Instanz auftritt, ist die Wahrscheinlichkeit hoch, dass er auch in der Produktionsumgebung auftritt, so dass Sie bei der Bereitstellung proaktiv vorgehen können.

Das beeindruckendste Merkmal der kontrollierten Synchronisierung von xtype ist, dass es sich Ihre Korrekturschritte merkt und sie ausführt, während es Ihre Update-Sets, Anwendungen und Batches synchronisiert. Teams, die xtype nutzen, profitieren von einer höheren Codequalität, einer schnelleren Veröffentlichungsgeschwindigkeit und einem geringeren Risiko von Verzögerungen.

Zusammenfassend lässt sich sagen, dass xtype eine proaktive Fehlererkennung ermöglicht, indem es Entwicklern sofortigen Zugriff auf Änderungen in der gesamten ServiceNow Landschaft gibt. Anstatt Tage oder Wochen zu warten, um Fehler zu finden, können Probleme innerhalb von Sekunden oder Minuten nach einer Änderung erkannt werden. xtype kontrollierte Synchronisierung stellt die Homogenität der Instanzen sicher, wodurch Fehler in die Entwicklung verlagert, MTTD minimiert und Verzögerungen bei ServiceNow Releases vermieden werden.

‍