In klassischen Softwareprojekten gehört CI/CD längst zum Standard: Code wird versioniert, automatisch getestet und zuverlässig in Produktionsumgebungen ausgerollt.

Im Bereich Data Engineering – insbesondere bei Databricks-Projekten – wird dieser Schritt dagegen oft unterschätzt. Viele Pipelines entstehen schnell in Notebooks, werden manuell angepasst und direkt ausgeführt. Das funktioniert anfangs gut – skaliert aber schlecht.

Ohne saubere CI/CD-Prozesse entstehen schnell Probleme:

• Änderungen lassen sich nicht sauber nachverfolgen

• Deployments sind fehleranfällig und inkonsistent

• Tests werden vernachlässigt oder manuell durchgeführt

• Teams blockieren sich gegenseitig, weil Standards fehlen

Gerade bei wachsender Projektgröße wird klar: Datenprojekte brauchen dieselbe Deployment-Disziplin wie Softwareprojekte.

In diesem Artikel zeige ich dir, wie du mit dbx – einem Open-Source-Tool von Databricks – und Azure DevOps eine moderne CI/CD-Pipeline für Databricks aufbaust.
Schritt für Schritt, mit Fokus auf Wiederverwendbarkeit, Automatisierung und Teamskalierbarkeit.

Grundprinzipien von CI/CD im Data Engineering Kontext

CI/CD steht für Continuous Integration und Continuous Deployment – zwei Prinzipien, die für Stabilität und Geschwindigkeit im Entwicklungsprozess sorgen. Auch wenn Data Engineering eigene Herausforderungen mitbringt, bleiben die Grundideen dieselben.

🔵 Continuous Integration (CI)

Continuous Integration bedeutet, dass jeder Code-Change sofort integriert und getestet wird.
Ziel: Fehler früh erkennen und kleinere, kontrollierbare Änderungen deployen.

Für Databricks bedeutet das konkret:

• Jedes Notebook oder Python-Modul wird in Git versioniert

• Pull Requests lösen automatische Tests aus (z. B. Unit-Tests auf Transformationen)

• Fehlerhafte Änderungen werden blockiert, bevor sie in den Haupt-Branch gelangen

💬 Merke: Auch Transformationen und Pipelines sind "Code" – sie verdienen dieselbe Qualitätssicherung wie klassische Software.

🟠 Continuous Deployment (CD)

Continuous Deployment sorgt dafür, dass geprüfter Code automatisch in eine Zielumgebung (z. B. Dev, QA, Prod) ausgerollt wird – ohne manuelle Eingriffe.

Für Databricks-Projekte heißt das:

• Notebooks, Libraries, Jobs oder Workflows werden automatisiert aktualisiert

• Umgebungsabhängige Konfigurationen (z. B. Secrets, Clustergrößen) werden berücksichtigt

• Das Deployment ist wiederholbar und standardisiert

💬 Merke: Je mehr Automatisierung du hast, desto weniger riskierst du manuelle Fehler – und desto schneller kannst du auf Änderungen reagieren.

🔍 Besondere Herausforderungen im Data Engineering

Data Engineering bringt einige Eigenheiten mit, die klassische CI/CD-Prozesse anpassen:

Deshalb brauchen wir Werkzeuge, die speziell für datengesteuerte Workflows geeignet sind – wie dbx.

Was ist dbx? – Der Schlüssel für sauberes Deployment

Um Data Engineering-Projekte auf Databricks sauber und wiederholbar zu deployen, brauchst du ein Tool, das Deployment, Umgebungsmanagement und Workflow-Definition unterstützt. Genau das übernimmt dbx.

🛠️ Was ist dbx?

dbx ist ein leichtgewichtiges Open-Source-CLI-Tool, speziell entwickelt, um:

• Databricks-Projekte nach Best Practices zu strukturieren

• Deployments in verschiedene Umgebungen (z. B. dev, prod) zu automatisieren

• Workflows als Konfigurationsdateien zu verwalten

• CI/CD-Prozesse effizient anzubinden (z. B. mit Azure DevOps)

📦 Typische Struktur eines dbx-Projekts

Ein praxiserprobtes dbx-Projekt folgt einer klaren Trennung:

🔹 app/ → Anwendungscode: Notebooks (als .sql, .py oder .ipynb), Hilfsmodule, evtl. Tests
🔹 resources/ → Workflow-Definitionen als YAML-Dateien
🔹 databricks.yml → Zentrale Steuerdatei für Umgebungen und Deployment-Targets

🧩 Die Rolle der databricks.yml

In der databricks.yml wird gesteuert:

• Welche Umgebungen es gibt (z. B. dev, prod)

• Welche Workflows aus dem resources/-Ordner deployed werden sollen

• Workspace-spezifische Einstellungen (z. B. Zielverzeichnisse, Zugriffe, Cron, …)

Die eigentlichen Workflow-Definitionen (Jobs, Cluster-Settings etc.) liegen als separate YAML-Dateien in resources/.

🧠 Warum diese Struktur sinnvoll ist

• Trennung von Code und Deployment-Logik

• Klarer Pfad von der Entwicklung bis zur Auslieferung

• Mehrere Environments ohne Copy-Paste

• Saubere CI/CD-Integration ohne manuelle Eingriffe

Kurz gesagt:
dbx bringt Struktur, Ordnung und Automatisierung in Databricks-Projekte – genau das, was du für sauberes, skalierbares Arbeiten brauchst.

Beispiel-Workflow: Databricks-Projekt mit Azure DevOps deployen

Jetzt, wo wir die Grundlagen und die Projektstruktur kennen, schauen wir uns an, wie du mit Azure DevOps und dbx eine vollständige CI/CD-Pipeline für Databricks aufbaust.

Ziel:
👉 Automatisiertes Deployment von Code und Workflows auf Databricks – sauber, reproduzierbar und ohne manuelle Klickerei.

🛠️ Voraussetzungen

Bevor wir starten, brauchst du:

• Ein Databricks Workspace (natürlich)

• Service Connection zu Azure für Zugriff auf Key Vaults

• Ein dbx-konformes Projekt (mit app/, resources/, databricks.yml)

• Azure DevOps Repository mit Zugriff auf Pipelines

🔹 Pipeline-Setup: Typischer Ablauf

Ein klassischer CI/CD-Workflow für Databricks mit Azure DevOps besteht aus folgenden Hauptphasen:

📄 Beispiel einer Azure DevOps Pipeline (azure-pipelines.yml)

Hier eine minimal funktionierende Version:

parameters:
- name: service_connection
  displayName: Service Connection
  type: 'string'
  default: 'DefaultConnection'

jobs:
- deployment: BuildAndDeploy
  pool:
    vmImage: 'ubuntu-latest'
  environment: ${{parameters.environment}}
  strategy:
    runOnce:
      deploy:
        steps:
        - task: UsePythonVersion@0
          displayName: 'Use Python 3.9'
          inputs:
            versionSpec: 3.9

        - task: AzureKeyVault@2
          inputs:
            azureSubscription: '${{parameters.service_connection}}' 
            KeyVaultName: 'dbxdatalayer-${{parameters.environment}}-kvault'
            SecretsFilter: 'DATABRICKSHOST,DATABRICKSTOKEN'

        - checkout: self
          persistCredentials: true
          clean: true
          displayName: 'Checkout & Build'

        - script: |
            python -m pip install --upgrade pip
            python -m pip install -e ".[local,test]"
            pip install wheel
            curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh
          displayName: 'Install dependencies'
            
        - script: |
            cd ./${{ parameters.pipeline }}/
            export DATABRICKS_TOKEN=$(DATABRICKSTOKEN)
            export DATABRICKS_HOST='https://$(DATABRICKSHOST)'
            databricks bundle deploy -t [prod | dev]
          displayName: 'Deploy Bundle'

🔍 Was passiert hier im Detail?

• ✅ Python 3.9 wird bereitgestellt als Basisumgebung

• ✅ Secrets (DATABRICKSHOST und DATABRICKSTOKEN) werden sicher aus Azure Key Vault geladen

• ✅ Repository wird sauber ausgecheckt inklusive Credentials

• ✅ Alle Abhängigkeiten werden installiert, inklusive der Databricks CLI (setup-cli)

• ✅ Deployment wird ausgeführt:

  • Mit Umgebungsvariablen für Host & Token

  • In die jeweils konfigurierte Umgebung (prod oder dev)

  • Sauber durch den Befehl databricks bundle deploy

📦 Varianten und Erweiterungen

• Deployment in mehrere Environments (z. B. zuerst dev, nach erfolgreichem Testing dann prod)

• Separate Pipelines für Build & Release (klassisch Azure DevOps Release Pipelines)

• Testläufe vor Deployment (später mit Unit- oder Data Quality Tests)

Mit diesem Setup bringst du jede Änderung im Projekt sauber und standardisiert auf deinen Databricks-Workspace – egal ob du alleine oder im Team arbeitest.

Best Practices für CI/CD in Databricks-Projekten

Ein funktionierendes Deployment-Skript ist gut – aber ein skalierbares, wartbares CI/CD-System ist besser.
Hier sind bewährte Best Practices, damit dein CI/CD-Setup auf Databricks langfristig erfolgreich bleibt:

🔒 1. Secrets niemals im Code speichern

• Zugriffsdaten wie Tokens oder Hosts niemals hartkodieren.

• Nutze Azure Key Vault, Azure DevOps Variable Groups oder Databricks Secrets für alle sensitiven Informationen.

• Zugriff nur über Pipelines automatisieren, nicht manuell.

🛠️ 2. Multi-Environment-Strategie sauber umsetzen

• Deploye klar getrennt nach dev, qa und prod.

• Nutze Parameter in Pipelines (wie $environment) für saubere Trennung.

• Environment-spezifische Konfigurationen (Clustergrößen, Speicherpfade etc.) gehören sauber in databricks.yml.

Ziel: Keine manuellen Deployments in Produktion – alles läuft über kontrollierte Pipelines.

🧹 3. Repository sauber strukturieren

• app/ → Code und Transformationen

• resources/ → Workflows und Bundle-Definitionen

• databricks.yml → zentrale Steuerdatei

• Klar getrennte Ordner und Naming-Conventions helfen extrem, wenn Teams wachsen.

🧪 4. Automatische Prüfungen vor Deployment einbauen

• Nutze Pull Request Checks (z. B. Syntax Checks, Basic Tests)

• Lasse dbx validate oder Databricks CLI Checks laufen, bevor deployed wird.

• Je früher du Fehler abfängst, desto stabiler bleibt dein Deployment.

🛡️ 5. Fehler- und Rollback-Strategien einplanen

• Deployment sollte fehlschlagen, wenn Tests oder Validierungen scheitern – niemals halb durchlaufen.

• Baue Rollback-Pläne für kritische Jobs ein (z. B. frühere Bundle-Version neu ausrollen).

• Überwache Deployments aktiv – etwa über Azure Monitor oder Slack-Alerts.

🎯 Zusammengefasst:

CI/CD in Databricks lohnt sich – nicht nur, um sauberer zu arbeiten, sondern um Skalierbarkeit und Zuverlässigkeit ab dem ersten Projekttag mitzudenken.
Mit einem gut aufgesetzten Prozess wird jede Änderung am Code ein kontrollierter Schritt in Richtung Produktion – automatisch, nachvollziehbar und sicher.