Die Basis für den CI Prozess ist die Nutzung von GitHub als zentrales Repository für sämtliche Projekt-Artefakte: Von PySpark Ingestion Skripten bis hin zum fertigen dbt-Gold-Modell. Sobald der Code in GitHub gepusht wird, übernimmt GitHub Actions die Rolle der Orchestrierung der CI/CD-Pipeline. Ziel ist es, automatische Tests und Validierungen durchzuführen, bevor der Code in die Databricks Umgebung eingespielt wird. Folgende Tests werden dabei ausgeführt:

• Validierung des PySpark Codes: Bei Änderungen in Ingestion-Scripts stellen wir via Unit Tests sicher, dass kritische Logikbausteine, zum Beispiel API Calls, weiterhin wie erwartet funktionieren. Des Weiteren wird geprüft, ob Formatierungen sowie gängige Programmierstandards eingehalten wurden.

• dbt-Tests: Die Pipeline führt zunächst ein dbt compile durch, wodurch sichergestellt wird, dass alle SQL Referenzen korrekt aufgelöst werden können und keine Syntax Fehler in den Modellen enthalten sind. Danach werden über ein dbt run –select my_changed_model+ und dbt test –select my_changed_model+ Kommando alle downstream-abhängigen Modelle sowie damit verbundene Tests ausgeführt. Dabei werden sowohl generische technische Tests, wie Einmaligkeit von Primärschlüsseln (unique) oder Abwesenheit von Null-Werten (not_null), als auch spezifische fachliche Tests mit eigens dafür definierten SQL-Statements durchgeführt.

Erst wenn in der Pipeline alle PySpark- sowie dbt-Tests erfolgreich gelaufen sind, erfolgt der finale Schritt der CI-Pipeline. Wir benutzen Databricks Asset Bundles (DABs) um den gesamten Stand unseres Projektes automatisiert und konsistent auf der Databricks Umgebung bereitzustellen. Anstatt Files, Skripte und Ressourcen in der GUI zu konfigurieren, wird die gesamte Projektkonfiguration sowie Infrastruktur in einer zentralen Konfigurationsdatei databricks.yml definiert. Dieses Vorgehen bietet uns einige entscheidende Vorteile:

• Vollständige Automatisierung & Validierung: Über den Befehl databricks bundle validate wird das gesamte Projekt inklusive der Konfigurationsdatei auf syntaktische Fehler, Korrektheit und Vollständigkeit geprüft. Nach erfolgreicher Validierung wird durch databricks bundle deploy das gesamte Paket durch die GitHub Action in die Zielumgebung eingespielt.
• Umgebungs-Unabhängigkeit: Über DABs können wir das Deployment auf verschiedene Umgebungen wie dev, test oder prod steuern. In der Konfigurationsdatei des DAB definieren wir dafür umgebungsabhängige Variablen, die dann beim Deployment auf die entsprechende Umgebung korrekt gemappt werden. Dadurch stellen wir sicher, dass Code, der in der Entwicklungsumgebung erfolgreich getestet wurde, konsistent bis in die Produktionsumgebung wandert.
• Atomarität und Konsistenz: Ein DAB wird technisch als eine untrennbare Einheit betrachtet. Das bedeutet, dass bei einem Deployment entweder alle definierten Ressourcen erfolgreich aktualisiert werden oder, im Fehlerfall, das System auf dem vorherigen stabilen Zustand verharrt. Diese Atomarität verhindert Drift zwischen dem Code im Git-Repository und der tatsächlichen Konfiguration in Databricks.