Ist SSIS der letzte Teil Ihres Stacks, der sich CI/CD verwehrt?

Modernes DevOps erreicht den Großteil einer Microsoft Datenplattform und endet am SSIS-Projekt. Die Packages liegen in Git, die Release-Pipeline deployt die .ispac, und alles zwischen diesen beiden Tatsachen wird von Hand gemacht: XML mergen, Umgebungsvariablen mappen und beim ersten eingeplanten Lauf herausfinden, ob das Release funktioniert hat.

Warum SSIS sich CI/CD widersetzt

• Ein Package ist XML, das sich schlecht vergleichen lässt. Layout-Koordinaten, GUIDs und Logik stehen in derselben Datei, eine kleine Änderung sieht also wie eine große aus, und zwei Änderungen an einem Package mergen selten sicher.
• Umgebungen sind Mappings. Dev, Test und Prod sind SSISDB-Umgebungsvariablen und Parameter Mappings, von Hand gepflegt und vor jedem Release aktualisiert.
• Ein Release ist ein Dateipaket, kein Diff. Die .ispac zu deployen ersetzt das Projekt. Was sich geändert hat, ist nicht Teil dessen, was deployt wurde, und Package XML ist nichts, was Review-Tooling in einem Pull-Request prüfen kann, die Validierung wartet also auf den ersten Lauf.
• Rollback ist die vorherige Datei. Für einen Rollback deployen Sie die letzte .ispac neu und zu hoffen, dass ihre Mappings noch passen. Was das Release im Warehouse bereits geändert hat, ist nicht Teil davon.

Das ist kein Designfehler von SSIS. Es wurde entworfen, bevor Continuous Delivery die Norm war, und das merkt man.

Wo Release-Management hingehört

• In den Generator. Wenn das Warehouse aus einem Modell kommt, ist ein Release der Unterschied zwischen zwei Zuständen dieses Modells, und das Tool weiß, wovon jeder Unterschied abhängt.
• Mit dem Rollback inklusive. Ein generiertes Release weiß, was es geändert hat, seine Umkehrung existiert also, bevor es läuft.
• Die Fachlogik versionieren, nicht das XML. Git und Gitflow auf dem Modell liefern ein Diff, das sich als Änderung am Warehouse liest, nicht an einem Dateilayout.

Was sich mit Datavault Builder ändert

Datavault Builder generiert versionierte Deployment- und Rollback-Skripte pro Umgebung aus dem Modell, mit Git und Gitflow-Unterstützung eingebaut. Ein Release beginnt als Vergleich zweier Zustände, Ihre lokale Umgebung, ein Zustand in Git, eine andere Live-Umgebung, eine ZIP-Datei oder ein Ordner, und Sie wählen, welche Unterschiede deployt werden.

• Das Merge-Problem verschwindet. Zwei Engineers ändern das Modell auf zwei Branches und mergen ein Modell, keine Package-Datei. Die Loads werden aus dem Ergebnis neu generiert.
• Umgebungen sind eine Konfiguration, keine Mapping-Tabelle. Verbindungsdetails pro Umgebung werden einmal gehalten; das Release für Test oder Prod wird mit ihnen angewendet generiert.
• Jedes Release trägt seinen Rollback. Und die Modellversion, zu der es gehört.
• Unterschiede werden vor dem Deployment in die nächste Umgebung verglichen. Was Prod gleich erhält, ist die Liste der Unterschiede zwischen seinem Zustand und Ihrem. Wählen Sie ein Datenprodukt, und das Tool schlägt den Hub, den Satelliten, die Staging-Tabelle und die Quelle vor, die es braucht.
• Ihr Pipeline-Tooling bleibt. Azure DevOps oder GitHub Actions führen das generierte Paket aus. Sie müssen SSIS nicht mehr verstehen.

Was zu entscheiden ist

Prüfen Sie die Deployment-Logs des letzten Quartals und zählen Sie zwei Dinge: die Releases, die eine manuelle Änderung am Umgebungs-Mapping brauchten, und die Package-Merges, die gelöst wurden, indem jemandes Arbeit neu gemacht wurde. Das ist die Wartung, die ein generiertes Release beseitigt.