Qualitätsprüfung vor dem Deployment

Die meisten Deployment-Probleme sind vor dem Import bereits im Export sichtbar. Man muss nur hinsehen und zwar bevor der Klick auf Importieren fällt. Das hier ist die kurze Prüfliste dafür. Warum die einzelnen Punkte schiefgehen steht ausführlich unter häufige Fehler beim Deployment.

Abhängigkeiten und Umgebungsvariablen

• Abhängigkeiten: Die fehlenden Abhängigkeiten aus der "solution.xml" samt Version gegen die Zielumgebung halten. Eine vorhandene aber zu alte Lösung zählt als fehlend.
• Umgebungsvariablen: Steckt im Export ein Wert neben der Definition? Dann bewusst entscheiden ob er die Zielumgebung überschreiben soll.
• Löschungen: Beim Upgrade verschwindet was in der neuen Fassung fehlt. Die Löschliste vorher ansehen.

Den Solution Checker gelaufen haben

Nicht direkt vor dem Deployment sondern als Dauerzustand: Der Solution Checker sollte auf dem Entwicklungsstand (in der Entwicklungsumgebung) regelmäßig laufen damit vor der Auslieferung keine Überraschungen mehr darin stehen. Kritische Funde in der Kategorie Sicherheit oder Upgrade-Fähigkeit sind ein Grund die Auslieferung zu verschieben. Der Rest ist Ermessenssache sollte aber dokumentiert sein.

Nicht verwaltete Schichten in der Zielumgebung

Gibt es dort nicht verwaltete Anpassungen an Komponenten welche gleich verwaltet überschrieben werden sollen? Dann greift die Auslieferung an diesen Stellen nicht. Die Solution-Layer-Ansicht der betroffenen Komponenten zeigt es.

Verbindungen für die Flows

Enthält die Lösung Power-Automate-Flows hängen sie an Connection References. Gibt es in der Zielumgebung für eine davon noch keine Verbindung kommt der Flow zwar an. Er bleibt aber ausgeschaltet bis jemand die Verbindung zuordnet. Vor dem Import sollte deshalb geklärt werden wer die fehlenden Verbindungen anlegt und unter welchem Konto sie laufen sollen. Ein Dienstkonto ist hier fast immer besser als das persönliche Konto dessen von demjenigen der zufällig gerade importiert.

Versionsnummer und Änderungsnotiz

Das klingt erstmal banal entscheidet aber im Fehlerfall über die Reaktionszeit: Ist die Versionsnummer hochgezählt und gibt es eine Zeile dazu was in dieser Version enthalten ist? Wenn drei Wochen später etwas auffällt ist diese Zeile der Unterschied zwischen gezieltem Rollback und Raten.

Sprachen der Zielumgebung

Ein kleiner Punkt mit ärgerlicher Wirkung: Manche Lösungen enthalten Übersetzungen für Sprachen welche in der Zielumgebung nicht aktiviert sind. Diese Beschriftungen gehen beim Import nicht mit. Der Abgleich der aktivierten Sprachen ist ein Einzeiler in der Vorbereitung und erspart das Nachpflegen von Hand.

Was diese Liste nicht leistet

Sie ersetzt keinen Testimport in eine Staging-Umgebung und keinen fachlichen Test. Sie fängt die Fehler ab deren Ursache schon im Paket steckt. Das sind erfahrungsgemäß die meisten aber nicht alle. Ein Import kann auch an Zuständen scheitern die nur die Zielumgebung kennt.

Wer die Liste zum ersten Mal auf eine bestehende Auslieferungspraxis anwendet findet fast immer etwas. Danach wird sie schnell Routine und Routine ist bei Deployments das eigentliche Ziel.