Risiken bei Solution-Upgrades

Beim Import einer verwalteten Lösung bietet die Plattform zwei Wege an: Upgrade und Update. Sie unterscheiden sich nur in einem Wort und in einem entscheidenden Verhalten. Upgrade ist die Voreinstellung, und Microsoft empfiehlt es ausdrücklich (Microsoft Learn: Upgrade or update a solution).

Ein Update legt die neue Fassung über die alte. Es fügt hinzu und überschreibt, aber es entfernt nichts. Ein Upgrade dagegen gleicht ab: Komponenten welche in der neuen Fassung fehlen werden in der Zielumgebung gelöscht. Das ist der einzige eingebaute Weg, über den Auslieferungsprozess aufzuräumen und gleichzeitig die Stelle an der es gefährlich wird. Weil Upgrade voreingestellt ist wird oft gelöscht, ohne dass jemand das bewusst entschieden hat.

Wo das Risiko konkret liegt

Gelöscht wird was fehlt. Das klingt nach Absicht umfasst aber auch das Versehen. Ein Feld wurde in der Entwicklung aus der Lösung entfernt; vielleicht beim Umbau auf eine segmentierte Solution. Beim Upgrade verschwindet es dann aus der Zielumgebung. Und mit einem Feld verschwinden dann auch seine Daten. Es gibt dafür keine Rückgängig-Funktion, nur die Datensicherung der Umgebung.

Dasselbe gilt für Tabellen, Beziehungen und Auswahllisten. Bei Formularen oder Ansichten ist der Verlust ärgerlich bei Datenfeldern ist er endgültig.

Ein Schritt, und der Sonderfall mit Zwischenstufe

Ein Upgrade läuft heute in einem Schritt: Die neue Fassung wird importiert, ersetzt die alte, fasst vorhandene Patches zusammen und führt die Löschungen aus.

Daneben gibt es die Option „Für Upgrade bereitstellen“ (Stage for Upgrade). Dann wird die neue Fassung zunächst als Warteschlangen-Lösung importiert, erkennbar am Namenszusatz _Upgrade. Erst ein zweiter, eigener Schritt wendet das Upgrade an. Sinnvoll ist das, wenn zwischen den Schritten Daten umgezogen werden müssen, etwa aus einem Feld, das danach verschwindet. Die Tücke liegt genau dort: Bricht der zweite Schritt ab bleibt die Umgebung im Zwischenzustand mit beiden Fassungen. Das passiert etwa wenn eine andere Lösung von einer zu löschenden Komponente abhängt. Das ist reparierbar, aber nicht intuitiv und es passiert bevorzugt abends während des Wartungsfensters.

Was sich vorher aus den Exporten ablesen lässt

Das Schöne an diesem Risiko: Es ist vollständig vorhersagbar. Ein Vergleich der Komponentenlisten von alter und neuer Fassung zeigt exakt was ein Upgrade löschen wird. Die Komponenten stehen in beiden Exporten in der solution.xml unter RootComponents. Bei Tabellen, die vollständig und nicht segmentiert in der Lösung stecken sind die Felder dort allerdings nicht einzeln aufgeführt. Für sie gehört die customizations.xml mit in den Abgleich. Mechanisch bleibt er trotzdem.

Vor jedem Upgrade gehört diese Differenzliste auf den Tisch mit einer bewussten Entscheidung pro Eintrag: Soll das wirklich weg? Bei Feldern zusätzlich die Frage ob Daten darin stehen. Wenn die Antwort unklar ist, ist der sichere Weg ein Update statt eines Upgrades. Und das Aufräumen wird verschoben bis die Antwort klar ist.

Ein verwandter Stolperstein der in dieselbe Vorbereitung gehört: Abhängigkeiten anderer Lösungen auf die zu löschenden Komponenten. Hängt irgendwo ein Formular oder ein Flow einer Nachbarlösung an dem Feld welches verschwinden soll blockiert das den Upgrade-Schritt. Auch das ist vorab prüfbar über die Abhängigkeitsanzeige der betroffenen Komponenten. Es gehört mit auf die Differenzliste.

Die Faustregel

Upgrade ist der Normalfall und die Empfehlung von Microsoft. Gerade deshalb gehört die Löschliste vor jeden Import. Update ist das Werkzeug für den Fall, dass eine Löschung noch nicht entschieden ist. Wer ein Upgrade fährt ohne die Löschliste gesehen zu haben, delegiert eine unumkehrbare Entscheidung an den Zufall.