Zwei Solution-Versionen vor dem Deployment vergleichen

Vor jedem Deployment steht dieselbe Frage: Was ist eigentlich anders als beim letzten Mal? Die vollständige Antwort kennt oftmals niemand. Die Änderungsnotiz (falls überhaupt gepflegt) nennt die Funktionen welche gebaut wurden und nicht die Spalte welche beim Aufräumen nebenbei aus der Lösung gefallen ist. Dabei liegt die Antwort komplett vor und zwar in den beiden Lösungsexporten (Alte- und neue Lösung).

Dieser Artikel geht die Änderungen durch die beim Import echten Schaden anrichten können und zeigt, wo man sie im Export findet. Am Ende steht eine Checkliste zum Selbermachen.

Entfernte Spalten: der Punkt mit Datenverlust

Wird eine verwaltete Lösung per Upgrade eingespielt gleicht man Dataverse ab. Alle Komponenten der vorigen Version die in der neuen fehlen werden gelöscht (Microsoft Learn: Aktualisieren oder Verbessern einer Lösung). Bei einer Spalte heißt das: Sie verschwindet und mit ihr alle darin enthaltenen Daten. Bei einer Tabelle sind es die Datensätze. Warum das so oft unbeabsichtigt passiert beschreibe ich ausführlich unter Risiken bei Solution-Upgrades.

Für den Vergleich heißt das: Die Liste der entfernten Tabellen und Spalten ist die wichtigste Liste überhaupt. Wer sie vor dem Import nicht gesehen hat löscht im schlimmsten Fall noch gebrauchte Produktivdaten. Wird die Lösung dagegen nicht verwaltet eingespielt bleiben die Spalten stehen. Dann gehen zwar keine Daten verloren aber niemand pflegt mehr die Spalten und sie wird zum Dataverse Datenmüll.

Dazu kommt ein Fall der im Paket selbst steckt. Eine Spalte fehlt in der neuen Version steht aber noch auf einem Formular oder in einer Ansicht derselben Version. Laut Microsoft entfernt ein Upgrade eine Komponente nur wenn in der Zielumgebung nichts mehr davon abhängt (Microsoft Learn: Aktualisieren oder Verbessern einer Lösung). Ob die Spalte dann bleibt oder das Upgrade an der Abhängigkeit hängen bleibt hängt also davon ab wo der Verweis liegt. Beides will man lieber vorher wissen als während des Wartungsfensters.

Geänderte Spalten: anderer Typ, kürzer oder strenger

Nicht nur was fehlt ist gefährlich. Vier Änderungen an bestehenden Spalten verdienen einen eigenen Blick.

Datentyp. Nach dem Speichern lässt sich der Datentyp einer Spalte nicht mehr ändern, abgesehen von Textspalten welche zu Autonummer-Spalten werden (Microsoft Learn: Erstellen und Bearbeiten von Spalten). Zeigt der Vergleich trotzdem einen neuen Typ, wurde die Spalte in der Entwicklung meist gelöscht und unter demselben Namen neu angelegt. In der Zielumgebung geht das nicht ohne Datenverlust. Sauber ist der Umweg: neue Spalte anlegen, Daten übertragen und die alte Spalte erst in einem späteren Release entfernen.

Maximallänge. Microsoft formuliert es vorsichtig: Das Maximum einer Textspalte lässt sich erhöhen aber man sollte es nicht senken. Denn im System können längere Werte stehen. Der Import selbst verhält sich dsbei unauffällig. Die Folgen kommen später wenn Datensätze mit zu langen Werten gespeichert werden oder eine Schnittstelle lange Werte schreibt. Wichtig ist deshalb nur die Richtung: Länger ist harmlos und kürzer gehört geprüft.

Neue Pflichtfelder. "Business required" ist eine Regel der Oberfläche. Modellgesteuerte Apps erzwingen sie. Die Dataverse-API dagegen gibt keinen Fehler zurück wenn der Wert fehlt (Microsoft Learn: Spaltendefinitionen). Alle Schnittstellen laufen also meist weiter. Getroffen werden die Anwender: Wer einen alten Datensatz ohne diesen Wert öffnet und etwas ändert muss erst das neue Pflichtfeld füllen bevor er speichern kann.

Entfernte Optionswerte. Eine Auswahlspalte übersetzt den Text in den vorkonfigurierten Zahlenwert. Dieser wird gespeichert und nicht wie man denken würde die Beschriftung (Microsoft Learn: Eine Auswahl erstellen). Fällt ein Wert aus der Liste, tragen Datensätze ihn trotzdem weiter nur steht er nicht mehr zur Auswahl. Ansichten, Diagramme und Berichte die auf genau diesen Wert filtern gehören deshalb geprüft. Der sichere Weg: betroffene Datensätze vor dem Import auf einen verbleibenden Wert umstellen.

Rechte: ersetzt, nicht ergänzt

Sicherheitsrollen in einer verwalteten Lösung verhalten sich anders als viele erwarten. Für eigene Rollen gilt beim Import: Die Rechte werden ersetzt und nicht zusammengeführt. Was jemand in der Zielumgebung außerhalb der Lösung an der Rolle geändert hat ist danach weg (Microsoft Learn: Verstehen wie verwaltete Lösungen zusammengeführt werden).

Für den Vergleich heißt das: Jede Rolle mit geänderten Rechten ist eine Frage an den Verantwortlichen, und zwar in zwei Richtungen. Erweiterte Rechte (etwa eine Stufe höher von Geschäftseinheit auf Organisation oder ein neues Löschrech) lassen Benutzer nach dem Import mehr sehen oder ändern. Eingeschränkte Rechte führen zu Fehlermeldungen in Abläufen die bisher funktioniert haben. Beides steht im Export, Recht für Recht und Tabelle für Tabelle. Wie man den Rollenbestand grundsätzlich durchgeht steht unter Sicherheitsrollen in Dynamics 365 prüfen.

Automatisierung, die wegfällt oder dazukommt

Ein Flow oder ein klassischer Workflow welcher in der neuen Version fehlt wird beim Upgrade ebenso gelöscht wie eine Spalte. Daten verschwinden dabei nicht, aber was er bisher still erledigt hat passiert ab dem Import nicht mehr. Oftmals merkt das erst der Fachbereich, Wochen später. Umgekehrt arbeiten neu aktivierte Flows und Plugin-Steps ab dem ersten Moment mit echten Daten.

Bei Plugin-Steps lohnt außerdem der Blick auf geänderte Registrierungen: eine andere Nachricht, eine andere Stufe, synchron statt asynchron oder ein geänderter Spaltenfilter. Der Code ist derselbe jedoch läuft zu einem anderen Zeitpunkt.

Checkliste zum Selbermachen

1. Gleich exportieren: beide Versionen verwaltet oder beide nicht verwaltet. Die Versionsnummer der neuen muss höher sein, sonst ist sie später nicht vom alten Stand zu unterscheiden.

2. Entfernte Tabellen und Spalten auflisten. Für jede klären ob Daten darin stehen und wer entschieden hat, dass sie weg dürfen.

3. Formulare und Ansichten der neuen Version nach Verweisen auf entfernte Spalten durchsuchen, auch in Filtern und Sortierungen.

4. Geänderte Spalten durchgehen: Datentyp, Maximallänge (nur kürzer ist kritisch), Pflichtstufe und entfernte Optionswerte.

5. Rollen: jedes geänderte Recht samt Stufe, getrennt nach mehr und weniger Rechten, vom Verantwortlichen bestätigen lassen.

6. "MissingDependencies" der neuen Version mit der alten vergleichen und neue Einträge gegen die Zielumgebung halten.

7. Neue Connection References und Umgebungsvariablen: Verbindung und Wert für die Zielumgebung vor dem Import klären.

8. Wegfallende und neue Automatisierung (Flows, Workflows, Plugin-Steps) mit dem Fachbereich durchgehen.

Erst danach fällt die Entscheidung zwischen Upgrade und Update. Ist bei einer entfernten Spalte noch offen ob die Daten gebraucht werden ist das Update der vorsichtige Weg und das Aufräumen kommt in die nächste Version. Und vor jedem Upgrade gehört eine Sicherung der Zielumgebung dazu, denn eine Rückgängig-Funktion gibt es nicht.

Mit D365 Audit habe ich unter anderem aus genau diesen Punkten einen Vergleich zweier Lösungsexporte gebaut; die Checkliste funktioniert aber genauso gut ohne Werkzeug.