Saubere ServiceNow-Releases: Update Sets sind kein Deployment-Konzept

Es gibt eine Frage, mit der ich in jedem Plattform-Audit den Reifegrad einer ServiceNow-Organisation einschätzen kann: Wie kommt eine Änderung von der Entwicklungsinstanz nach Produktion?

Wenn die Antwort lautet "der Entwickler schiebt sein Update Set durch", weiß ich ziemlich genau, was mich in den nächsten Tagen erwartet. Kollisionen zwischen Update Sets verschiedener Entwickler. Vergessene Abhängigkeiten, die in der Testinstanz zufällig da waren und in Produktion fehlen. Hotfixes, die direkt in Prod gebaut und nie zurückportiert wurden, sodass die nächste Migration sie überschreibt. Und niemand, der verbindlich sagen kann, welcher Stand eigentlich wo ist.

Der Kern des Problems: Update Sets werden als Deployment-Prozess missverstanden. Sie sind aber nur ein Transportmittel. Der Prozess muss drumherum gebaut werden, und die gute Nachricht ist: Das geht ohne große Toolkette, mit Disziplin und vier Bausteinen.

Baustein 1: Ein Release-Zug statt Einzelfahrten

Die wichtigste Umstellung ist konzeptionell. Änderungen werden nicht einzeln transportiert, wann immer ein Entwickler fertig ist, sondern gesammelt und in festen Abständen gemeinsam, zum Beispiel alle zwei Wochen. Der Begriff Release-Zug trifft es gut: Der Zug fährt zu festen Zeiten, wer fertig ist, fährt mit, wer nicht, nimmt den nächsten.

Das klingt nach Verlangsamung und ist in Summe das Gegenteil. Die Einzeltransporte verursachen genau die Kollisionen und Reihenfolge-Probleme, deren Behebung dann Tage kostet. Ein gebündeltes Release wird einmal getestet, einmal freigegeben, einmal transportiert. Ausnahmen für echte Notfälle gibt es weiterhin, aber sie heißen dann auch so, werden dokumentiert und bleiben selten, statt der Normalfall zu sein.

Baustein 2: Batching nutzen

Technisch unterstützt die Plattform das Bündeln längst: Update Sets lassen sich zu Batches mit einem Parent zusammenfassen. Der ganze Batch wird gemeinsam in die Zielinstanz übertragen und in der richtigen Reihenfolge committet. Damit ist auf einen Blick sichtbar, was zu einem Release gehört, und das Reihenfolge-Roulette einzelner Commits entfällt.

In der Praxis bewährt sich ein Parent pro Release-Zug, darunter die Update Sets der einzelnen Storys. Wer mag, ergänzt ein Naming-Schema für den Parent mit Release-Datum, dann ist auch ein Jahr später nachvollziehbar, was wann gefahren ist.

Baustein 3: Vier Augen vor dem Commit

Die Preview-Funktion vor dem Commit zeigt Kollisionen und fehlende Abhängigkeiten an. Sie ernst zu nehmen, statt alle Warnungen routiniert wegzuklicken, ist die halbe Qualitätssicherung. Die andere Hälfte: Ein zweiter Mensch schaut vor dem Commit auf die Liste der Änderungen.

Das Vier-Augen-Prinzip wirkt hier doppelt. Es fängt fachliche Fehler ab, vor allem aber diszipliniert es schon beim Entwickeln. Wer weiß, dass ein Kollege die Änderungsliste liest, packt keine ungetesteten Nebenbei-Änderungen mehr ins Update Set. Genau diese Beifänge sind erfahrungsgemäß die häufigste Ursache für Produktionsüberraschungen.

Baustein 4: Benennung erzwingen

Ein Update Set namens "Fix" oder "Änderungen KW3" hilft niemandem, am wenigsten demjenigen, der ein halbes Jahr später einen Fehler eingrenzen muss. Eine Konvention aus Story-Nummer und Kurzbeschreibung ist in fünf Minuten eingeführt und zahlt sich bei jeder Fehlersuche aus. Wichtig ist nur, dass sie verbindlich ist: Was falsch benannt ist, fährt nicht mit dem Zug.

Und wo bleibt das richtige DevOps?

Wer mit Scoped Applications arbeitet, sollte sich zusätzlich die Source-Control-Integration anschauen: Apps lassen sich mit Git-Repositories verknüpfen, womit Stände versioniert, Branches möglich und Reviews außerhalb der Instanz machbar werden. Für ernsthafte Eigenentwicklung ist das der richtige Weg, und die ServiceNow-eigenen DevOps-Werkzeuge können das weiter ausbauen.

Aber das ist die zweite Stufe. Die meiste Konfigurationsarbeit in den meisten Organisationen passiert weiterhin im globalen Scope, und dort bleibt der disziplinierte Update-Set-Prozess die Grundlage, auf der alles andere aufbaut. Eine teure Pipeline auf einem chaotischen Prozess automatisiert nur das Chaos.

Nichts von alledem ist glamourös, und genau das ist der Punkt. Release-Disziplin ist wie Zähneputzen: unspektakulär, täglich, und man bemerkt ihren Wert erst richtig, wenn sie gefehlt hat. Ich habe jedenfalls noch keine Instanz gesehen, die an zu viel davon gelitten hätte.