Der App-Source-Code liegt sicher verwahrt in der Source-Code-Verwaltung. Was ist mit der SQL-Datenbank? Lose Skript-Sammlung oder nur eine operative Datenbankinstanz? Welche Skripte sind aktuell? Was passiert, wenn die Datenbankinstanz beschädigt wird oder verloren geht? Wie können Änderungen vorgenommen werden ohne dabei unbemerkt Fehler an anderen Stellen einzubauen?
Hier helfen SQL-Datenbankprojekte. Egal ob operative Datenbank oder Data Warehouse, die gesamte Struktur der SQL-Datenbank (Tabellen, Sichten, gespeicherte Prozeduren, etc.) wird in Form einzelner SQL-Objekte in einem SQL-Datenbankprojekt verwaltet. Dadurch kann die Datenbank ebenfalls als Quellcode in einer Versionsverwaltung abgelegt und mit CI/CD-Pipelines automatisch in verschiedenen Umgebungen bereitgestellt werden.
Zum ausführlichen Vergleich der Feature-Sets auf Microsoft Learn.
Fabric Lakehouse und Fabric Warehouse sind zwar besonders, da sie nur einen SQL Analytics Endpoint bereitstellen und intern mit Parquet-Dateien arbeiten. Aber auch diese Objekte lassen sich in einem SQL Datenbank Projekt verwalten, wobei bestimmte Einschränkungen zu berücksichtigen sind.
Für dieses Beispiel haben wir vorab in Fabric ein Warehouse "SampleDWH" erstellt und mit den Beispieldaten von Microsoft beladen.
In VS Code (SQL Database Projects Extension) können wir das Schema des Warehouses über das Feature "Create Project From Database" importieren.
Da wir für eine detailliertere Analyse zusätzliche Kennzahlen benötigen, erweitern wir die View "vw_PaymentAnalysis" um die noch fehlenden Spalten.
Das Erstellen des Projekts gibt uns sofort die Rückmeldung, dass wir einen Fehler in unserem Source-Code haben. Es gibt ein Problem mit einer der neu hinzugefügten Spalten in der bearbeiteten View. Die referenzierte Spalte [TollAmount] kann nicht aufgelöst werden.
Nach kurzer Prüfung ist klar, wir haben einen Tippfehler. Der Spaltenname wird zu [TollsAmount] korrigiert und die erneute Erstellung des Projekts ist erfolgreich.
Abschließend können wir das geänderte Datenbank Schema auf der Zielplattform bereitstellen.
Dazu müssen wir zunächst eine Verbindung zur Zielplattform herstellen. Durch einen Abgleich zwischen dem Schema im SQL Projekt und der Datenbank-Instanz werden die Unterschiede identifiziert.
Die notwendigen Änderungen können wir entweder als SQL Statements in einem Skript generieren lassen, das wir anschließend manuell gegen die Datenbank-Instanz ausführen. Oder wir veröffentlichen die Änderungen direkt.
Schauen wir anschließend in Fabric mit dem Explorer in das Warehouse Schema, sehen wir die neu hinzugefügten Spalten.
Alle Informationen zu SQL-Datenbankprojekten gibt es auf Microsoft Learn.
Du entwickelst auf der Produktivumgebung oder hast zwar eine Entwicklungsumgebung aber immer nur den aktuellen Entwicklungsstand?
Was, wenn diese eine Version versehentlich gelöscht wird oder der Admin ein Backup vom Server einspielen muss und damit einen alten Stand wiederherstellt? Wie kommst Du zu einem lauffähigen Entwicklungsstand zurück, wenn eine Deiner letzten Änderungen zu einem Fehler an ganz anderer Stelle geführt hat und das erst eine Woche später aufgefallen ist? Wie hältst Du den Überblick über unzählige Kopien und Zwischenstände Deiner Entwicklungsarbeit?
Was das Backup für die Datenbank ist, ist die Versionskontrolle für Deine Entwicklung! Diese hilft Dir, Deine Entwicklungsarbeit zu sichern und zu versionieren, auch im Team. Die Nachverfolgung aller Änderungen ist problemlos möglich und jederzeit kannst Du auf einen älteren Entwicklungsstand zurückgreifen.
Entwicklung mit Netz und doppeltem Boden!
Bei Entwicklungsprozessen, die auf einer gemeinsamen zentralen Umgebung aufsetzen, wie beispielsweise einem Fabric-Arbeitsbereich, muss darauf geachtet werden, dass sich Entwickler nicht gegenseitig in ihrer Arbeit stören. Grundsätzlich lassen sich zwei Szenarien unterscheiden.
Lokale Entwicklung mit Client-Tools
Entwicklung in isoliertem Arbeitsbereich
Alle Informationen zu Microsoft Fabric-Git-Integration gibt es auf Microsoft Learn.
