Die Kernaussagen auf einen Blick.
- Databricks Asset Bundles (DABs) sind das offizielle YAML-basierte Deployment-Format für Objekte innerhalb eines Databricks Workspace: Jobs, Pipelines, Modelle, Volumes, Dashboards und Schemas in einem versionierten Repo.
- Asset Bundles und Terraform arbeiten auf zwei verschiedenen Ebenen: Bundles deployen Workspace-Objekte (Objekt-IaC), Terraform verwaltet die Plattform darunter (Plattform-IaC). Ein Ersatz sind sie deshalb nicht.
- Vor dem ersten Bundle-Setup sollten drei Punkte festgelegt werden: Schnitt zwischen Bundle und Terraform, Target-Schema pro Stage, CI/CD-Trigger für Validate und Deploy.
- Mein Vorschlag: Bundles als Standard für Workspace-Objekte einführen, Terraform auf der Workspace-, Metastore- und Policy-Schicht halten.
- Die Promotion zwischen Umgebungen sollte über Targets und nicht über separate Repositories erfolgen.
Inhaltsverzeichnis
Warum du Terraform trotzdem brauchst
In einem Plattform-Review zeigte sich, dass Jobs auf vier unterschiedliche Arten bereitgestellt wurden: aus der UI direkt in Prod, aus einem databricks-cli-Wrapper-Skript, aus einem Terraform-Modul mit dreihundert Zeilen Job-Definition und aus einem ersten Asset-Bundle-Pilot, der nur in Dev lief. Die Job-Definitionen wichen in Cluster-Profil, Permissions und Trigger zwischen Dev und Prod ab. Bevor ein Job geändert werden konnte, musste zunächst geklärt werden, welcher Deployment-Weg dafür maßgeblich war.
Diese Situation tritt häufig auf, sobald mehrere Teams dieselbe Databricks-Plattform nutzen. Die Workspace-Infrastruktur ist sauber in Terraform abgelegt, Accounts und Metastore stehen in Code, Cluster Policies sind versioniert. Die Workspace-Objekte werden dagegen häufig über unterschiedliche und nicht abgestimmte Wege verwaltet: ein Job per UI, ein zweiter aus einem Wrapper, ein weiterer Job wird über ein separates Terraform-Repository verwaltet, für das keine klare Verantwortung mehr besteht. Dadurch ist nicht mehr eindeutig nachvollziehbar, welches Werkzeug für welche Objekte zuständig ist.
Was passiert, wenn ein Job in Dev anders konfiguriert ist als in Prod? Wer ändert die Job-Definition, wenn der Owner gewechselt hat? Welche Permissions gelten für den Job, wenn er morgen produktiv läuft? Wie wird Quellcode reproduzierbar zwischen den Workspaces bereitgestellt? An welcher Stelle entscheidet sich, ob ein Bundle einen Job überschreibt, der direkt in der UI bearbeitet wurde?
Was sind Databricks Asset Bundles?
Databricks Asset Bundles (DABs) sind das offizielle YAML-basierte Deployment-Format für Databricks-Projekte. Microsoft Learn führt Asset Bundles als Werkzeug für Source Control, Code-Review, Testing und CI/CD in Databricks-Projekten. Ein Bundle besteht aus einer zentralen databricks.yml, ergänzenden Ressourcendefinitionen und der Databricks CLI. Über die CLI werden Validierung, Deployment und Ausführung einheitlich gesteuert. Databricks hat Asset Bundles 2023 als General-Availability-Feature der Databricks CLI eingeführt. Inzwischen firmiert das Format offiziell als Declarative Automation Bundles; der frühere Name Databricks Asset Bundles (DABs) ist weiterhin gebräuchlich und bleibt in der CLI (databricks bundle …) sichtbar.
Mit einem Bundle werden Workspace-Objekte versioniert als Code beschrieben: Jobs, Lakeflow Declarative Pipelines, registrierte Modelle, Model-Serving-Endpoints, Volumes, Dashboards, Schemas und Apps. Es bindet diese Objekte an konkrete Target-Workspaces (Dev, Stage, Prod), setzt Variablen abhängig von der jeweiligen Zielumgebung und deployed alles über die Databricks CLI. Auch Lakeflow Jobs, Declarative Pipelines und Designer-Exporte verwenden dieses Format: Sie landen in derselben databricks.yml-Struktur.
Wie die Lakeflow-Komponenten in einem gemeinsamen Plattform-Modell zusammenspielen, zeigen wir im Überblick zu Data Engineering auf Databricks.
Asset Bundles decken jedoch nicht alle Ebenen der Plattform ab: kein Ersatz für die Workspace-Infrastruktur (Accounts, Metastore, Workspaces, IAM, Cluster Policies bleiben Terraform-Aufgabe), sie sind kein allgemeines Werkzeug zur Synchronisierung von Workspace-Inhalten, kein Universal-IaC für die Cloud-Schicht. Bundles arbeiten immer innerhalb eines konkreten Workspace: sie deployen in einen Workspace, Account-, Netzwerk- und grundlegende Plattformressourcen liegen außerhalb ihres Anwendungsbereichs.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie ist ein Databricks Declarative Automation Bundle aufgebaut?
Ein Bundle ist ein Verzeichnis mit einer Root-Datei databricks.yml und beliebigen YAML-Includes darunter. Die Root-Datei definiert Metadaten, lädt Module per Glob, deklariert Variablen und beschreibt Targets.
Vier Bereiche bilden die zentrale Struktur eines Bundles:
bundle
Programmatischer Name und optional Git-Metadaten – taucht in Deployment-Pfaden, der Job-UI und dem Audit-Trail auf.
include
Glob-Liste auf weitere YAML-Dateien – Ressourcendefinitionen lassen sich auf mehrere Verzeichnisse aufteilen, etwa resources/jobs/, Pipelines oder Modelle.
variables
Konfigurierbare Werte mit Typ, Standardwert und optionaler Auflösung bestehender Workspace-Objekte – pro Target überschreibbar, auch aus CLI-Flags oder Environment-Variablen.
targets
Stage-Profile mit eigenem Workspace-Host, Run-As-Identity, Mode, Variablen-Overrides und Default-Permissions – pro Deployment wird genau eine Zielumgebung gewählt.
Der resources-Block (als Top-Level-Key oder als Include) beschreibt die Workspace-Objekte. Die Ressourcendefinitionen orientieren sich direkt an den jeweiligen Databricks-REST-APIs. Dadurch lassen sich neue API-Funktionen häufig ohne grundlegende Änderungen am Bundle-Modell ergänzen: sobald die API einen Konfigurations-Schlüssel kennt, akzeptiert das Bundle ihn.
Platzhalter wie ${workspace.current_user.userName}, ${bundle.target}, ${var.environment} oder ${resources.jobs.ingest.id} lassen sich in jedem Block einsetzen. So bleiben Workspace-spezifische Pfade, IDs und Hostnamen aus den Ressourcendateien heraus, und dasselbe Bundle läuft in mehreren Workspaces.
Databricks Asset Bundle Targets: Dev, Stage und Prod sauber trennen
Targets beschreiben die Konfiguration der einzelnen Umgebungen. Jedes Target hat einen Workspace, eine Run-As-Identity, einen Modus und beliebige Variablen-Overrides.
Modus development
Default für ein Dev-Target – Bundle landet im User-Home-Pfad, Jobs bekommen ein [dev <username>]-Präfix, Pipelines laufen mit Continuous-Off, Schedules sind pausiert.
Modus production
Für Stage- und Produktionsumgebungen – Bundle landet im konfigurierten Workspace-Pfad, Schedules sind aktiv, als Run-As sollte eine technische Identität verwendet werden.
Run-As
Identity, unter der Jobs, Pipelines und Endpoints laufen – in Dev der User, in Prod ein Service Principal. Abweichende Berechtigungen führen häufig dazu, dass Prozesse in Stage funktionieren und in Prod fehlschlagen.
Workspace
Host-URL pro Target – dasselbe Bundle lässt sich ohne abweichende Ressourcendefinitionen in mehrere Workspaces deployen.
Variablen-Overrides
Pro Target beliebig überschreibbar: Catalog-Name, Schema-Suffix, Volume-Pfad, Cluster-Policy-ID – Standardwerte werden zentral definiert.
| Target | Mode | Run-As | Schedule-Aktivität | Pfad-Konvention |
|---|---|---|---|---|
| dev | development | User (Dev) | pausiert | /Users/<user>/.bundle/<name> |
| stage | production | Service Principal Stage | aktiv | /Shared/.bundle/<name> (Stage-Workspace) |
| prod | production | Service Principal Prod | aktiv | /Shared/.bundle/<name> (Prod-Workspace) |
Damit ist für jede Umgebung festgelegt, welche Ressourcen unter welcher Identität und mit welchen Einstellungen ausgeführt werden. Die Promotion erfolgt anschließend durch das Deployment desselben Bundles in das nächste Target, etwa über bundle deploy --target prod in der CI-Pipeline.
Welche Objekte kann ein Bundle deployen?
Bundles unterstützen einen großen Teil der produktiv relevanten Workspace-Ressourcen. Der unterstützte Umfang wird mit neuen CLI-Versionen regelmäßig erweitert; Microsoft Learn pflegt die vollständige Resource-Typen-Übersicht. Die wichtigsten Typen für produktive Datenplattformen:
| Resource-Typ | Use Case | Anmerkung |
|---|---|---|
| jobs | Lakeflow Jobs mit Tasks, Triggern, Cluster-Bindung | API-Parität, alle Task-Typen unterstützt |
| pipelines | Lakeflow Declarative Pipelines | Source-Pfade, Catalog/Schema, Edition, Channels |
| models & registered_models | MLflow-Modelle, UC Registered Models | Eigentum, Aliasse, Beschreibung |
| model_serving_endpoints | Model-Serving-Endpoints | Routes, Scaling, Permissions |
| volumes | Unity-Catalog-Volumes (Managed und External) | Storage-Pfad und Eigentum |
| schemas | Unity-Catalog-Schemas | Catalog-Bindung, Eigentum |
| dashboards | AI/BI-Dashboards (Lakeview) | Serialisierte Dashboard-JSON |
| apps | Databricks Apps (Lakehouse Apps) | App-Definition und Resources |
| experiments | MLflow-Experiments | Workspace- und UC-Variante |
| quality_monitors | Lakehouse Monitoring auf UC-Tabellen | Schedule, Output-Schema |
| genie_spaces | AI/BI Genie Spaces für NL-Abfragen auf UC-Daten | nur Direct-Deploy-Engine, ab CLI 1.3.0; warehouse_id + serialisierter Space |
Berechtigungen können direkt an der jeweiligen Ressource definiert werden: permissions: mit Service-Principal-, Gruppen- und User-Einträgen plus konkretem Level (CAN_VIEW, CAN_RUN, CAN_MANAGE). Dadurch werden Berechtigungen versioniert und gemeinsam mit der Ressourcendefinition geprüft.
Als Quellartefakte können unter anderem Notebooks, Python-Dateien, Wheels, dbt-Projekte und SQL-Dateien verwendet werden (relativ zum Bundle-Root oder aus dem Workspace bezogen). Python-Wheels können im Rahmen des Deployments gebaut und als Artefakte bereitgestellt werden: databricks bundle deploy lädt sie als Artefakt mit hoch. Die bereitgestellten Artefakte können anschließend von den definierten Jobs und Pipelines verwendet werden.
Wie die Job-Resource im Detail aussieht, klären wir im Überblick zu Lakeflow Jobs. Wie die Pipeline-Resource zu Catalog, Schema und Source-Code steht, erklären wir in Lakeflow Declarative Pipelines.
Databricks Bundle Deploy: CLI-Kommandos für Validate, Deploy, Run und Destroy
Bundles laufen über die Databricks CLI. Der Lebenszyklus eines Bundles wird im Wesentlichen über fünf CLI-Kommandos gesteuert.
init
Erzeugt aus einem Template ein neues Bundle-Verzeichnis – aus Databricks-Templates (mlops-stacks, default-python, default-sql) oder einem eigenen Git-Repo mit Go-Templating, Hooks und Prompts.
validate
Prüft Syntax, Schema-Konformität und Substitutionen und liefert die effektiv aufgelöste Konfiguration zurück – Pflicht in jeder Pull-Request-Pipeline vor dem Deploy.
deploy --target <name>
Erstellt oder aktualisiert die definierten Ressourcen im gewählten Workspace, lädt Source-Files hoch und legt eine Deployment-State-Datei ab. Ein erneutes Deployment ohne Änderungen erzeugt keine Ressourcenduplikate.
run <resource> --target <name>
Führt eine bereits bereitgestellte Ressource direkt aus – Job, Pipeline oder Endpoint. Sinnvoll für End-to-End-Tests aus der CI heraus, ohne zusätzlichen UI-Klick.
destroy --target <name>
Entfernt alle deployed Resources des Bundles aus dem Target-Workspace – geeignet für temporäre Entwicklungsumgebungen und automatisierte Bereinigung.
Das User-Facing-Format (YAML plus CLI) bleibt gleich, aber das Deployment-Backend ist im Umbruch. Historisch rief die CLI intern den Databricks-Terraform-Provider auf und verwaltete einen Terraform-State im Workspace. Seit CLI 0.279.0 gibt es zusätzlich die Direct-Deploy-Engine: Sie spricht die Databricks-REST-APIs direkt über das Go-SDK an, ohne Terraform-Provider, und legt einen eigenen JSON-State (resources.json) ab. Für neue Bundles ab CLI 1.3.0 ist sie der Default; den Terraform-Pfad will Databricks 2026 abkündigen, bestehende Bundles lassen sich per databricks bundle deployment migrate umstellen. In beiden Fällen liegt der State im Workspace und muss nicht in einem eigenen Backend verwaltet werden.
Die typische Schleife im Repo: Code ändern, databricks bundle validate, databricks bundle deploy --target dev, databricks bundle run <job>. Änderungen lassen sich damit reproduzierbar über wenige CLI-Schritte testen und bereitstellen.
Databricks Asset Bundles CI/CD: GitHub Actions, Azure DevOps und GitLab
Der größte Nutzen von Asset Bundles entsteht durch die Einbindung in eine CI/CD-Pipeline. Ohne CI/CD verbessert ein Bundle zwar Versionierung und Validierung, schiebt Änderungen aber noch nicht automatisch von Dev über Stage nach Prod.
Der typische Bundle-CI/CD-Pfad folgt einem festen Muster: Aus der lokalen Dev-Umgebung wird das Bundle direkt und manuell in den Dev-Workspace deployt, während der Weg nach Stage und Prod ausschließlich über Version Control und die CI/CD-Strecke läuft, erst nach Commit, Tests und Approval. Diesem Pfad folgt auch die Databricks-Dokumentation für die CI/CD-Integration.
Microsoft Learn dokumentiert die End-to-End-CI/CD-Integration mit GitHub Actions für Asset Bundles und verweist auf vergleichbare Patterns für Azure DevOps und GitLab. Ein typisches produktives Setup umfasst drei Schritte:
PR-Validate
Bei jedem Pull Request läuft `databricks bundle validate --target stage` gegen ein Stage-Setup, optional ergänzt um Dry-Run-Deploys in einen Feature-Branch-Workspace. Erfasst YAML-Fehler, fehlende Substitutionen und Schema-Verletzungen vor dem Merge.
Deploy Stage on Merge
Nach dem Merge in den Hauptbranch wird das Bundle automatisch in der Stage-Umgebung bereitgestellt. Die Stage-Identity ist ein Service Principal mit Stage-Workspace-Berechtigungen; der Runner authentifiziert sich über OIDC oder ein gespeichertes Token.
Deploy Prod nach Approval
Vor dem Produktionsdeployment erfolgt eine ausdrückliche Freigabe. Der Prod-Deploy nutzt einen separaten Service Principal mit Prod-Berechtigungen und einen anderen Workspace-Host – getrennte Identitäten pro Stage.
Die Authentifizierung in der Pipeline läuft über Service Principals und OAuth-Token (M2M) oder über OIDC-basierte föderierte Identitäten. Langfristige statische Tokens sollten in neuen Setups möglichst vermieden werden.
Der grundsätzliche Ablauf ist bei GitHub Actions, Azure DevOps und GitLab vergleichbar: Runner installiert die Databricks CLI, lädt das Bundle, authentifiziert sich gegen den Target-Workspace und ruft validate und deploy. Unterschiede bestehen vor allem in der Authentifizierung und der jeweiligen Pipeline-Syntax (OIDC, Managed Identity, Workload Identity Federation). Wo ein Coding-Agent Bundle-Definitionen und Pipeline-Skripte generiert und debuggt, zeigen wir im Überblick zu Genie Code.
Permissions, Service Principals und Run-As in Asset Bundles
Berechtigungen können über das Bundle versioniert statt manuell in der Oberfläche gepflegt werden. Das Berechtigungsmodell basiert auf drei Mechanismen:
Pro-Resource-Permissions
Jeder Resource-Block trägt einen permissions-Eintrag mit Service Principals, Gruppen und Usern plus Level, Teil des regulären Review- und Deployment-Prozesses, konsistent über Targets hinweg.
Bundle-Default-Permissions
Im Target lässt sich eine Default-Permission-Liste setzen, die alle Resources erben, sofern sie keine eigene Definition tragen, etwa „alle Jobs in diesem Bundle: Plattform-Team CAN_MANAGE”.
Run-As-Identity
Pro Target festgelegt: in Dev der Benutzer, in Stage und Prod ein Service Principal. Im Production-Mode ist ein User als Run-As nicht zulässig.
Service Principals werden über Terraform auf der Account- oder Workspace-Ebene angelegt und mit den nötigen Workspace-, Cluster-Policy- und Catalog-Berechtigungen versehen. Das Bundle referenziert nur den application_id (oder im Lookup-Modus den Namen) und greift damit auf die bereits vorhandene Identity zu. Anlage, Verwaltung und Rotation der technischen Identitäten bleiben Aufgabe der Plattform-IaC.
Abweichende Berechtigungen zwischen den Umgebungen führen häufig erst beim Produktionslauf zu Fehlern. Ein Dev-Deploy als User und ein Prod-Run als Service Principal mit anderen Berechtigungen zeigen den Unterschied erst beim ersten Prod-Run. Das Bundle kann die vorgesehenen Berechtigungen transparent dokumentieren. Drift lässt sich jedoch nur vermeiden, wenn parallele manuelle Änderungen ausgeschlossen werden. Wie Bundles die Deployment-Basis für ML-Engineering-Agents bilden, klären wir im Überblick zu ML-Engineering-Agents.
Databricks Asset Bundles vs Terraform: Welche Ressource gehört wohin?
Asset Bundles und Terraform werden häufig miteinander verglichen, obwohl sie unterschiedliche Ebenen abdecken. Sie ergänzen sich und sollten nicht als gegenseitiger Ersatz betrachtet werden.
Terraform und OpenTofu eignen sich für Account-, Workspace- und grundlegende Plattformressourcen: Accounts, Workspaces, Metastore, Catalogs, External Locations, Storage Credentials, Cluster Policies, Account-Level-IAM, Netzwerk-Integration. Der Databricks-Terraform-Provider deckt diese Schicht vollständig ab und ist das einzige Werkzeug, das Account-API und Workspace-API gleichzeitig adressiert.
Asset Bundles eignen sich für Anwendungs- und Datenobjekte innerhalb eines bestehenden Workspace: Jobs, Pipelines, Modelle, Endpoints, Volumes, Dashboards, Schemas. API-Parität pro Resource macht das Format robust gegen neue Features, die CLI-Strecke und der Targets-Mechanismus sind auf Promotion ausgelegt.
| Aspekt | Asset Bundles | Terraform / OpenTofu |
|---|---|---|
| Scope | Workspace-Objekte | Account, Workspace, Plattform-Schicht |
| Typische Owner | Daten-Teams, Data Engineering | Plattform-Team, Cloud-/Security-Engineering |
| API-Parität | hoch, eins zu eins zur Resource-API | hoch, aber Job-Definitionen sind vergleichsweise umfangreich |
| State | im Workspace verwaltet | externer Backend-State (S3/Blob/GCS) |
| Promotion über Stages | nativ über Targets | über Workspaces und Variablen-Files |
| Lock-Mechanismus | Bundle-Lock pro Target | Backend-Lock |
| Migration aus UI | databricks bundle generate aus existierendem Job | terraform import |
In Terraform oder OpenTofu sollten verwaltet werden:
- Accounts, Workspaces, Account-IAM und SCIM-Gruppen
- Cloud-Infrastruktur wie VNets, Subnets, Private Endpoints und Customer-managed Keys
- Unity Catalog auf Metastore-Ebene einschließlich Storage Credentials und External Locations
- Catalog-Anlage und Grants auf Catalog-Ebene
- Cluster Policies, Instance Pools und Pool-Berechtigungen
- Service Principals einschließlich OAuth- oder Token-Konfiguration
- Workspace-Konfiguration wie IP Access Lists und Workspace-Bindings
In Asset Bundles sollten verwaltet werden:
- Lakeflow Jobs einschließlich Tasks, Triggern und Job-Berechtigungen
- Lakeflow Declarative Pipelines und Designer-Exporte
- MLflow-Experiments, Registered Models und Model-Serving-Endpoints
- Dashboards, Apps und Quality Monitors
- Inhalte innerhalb bestehender Schemas wie Tabellen-Definitionen über Pipelines
- Notebooks, Python-Wheels, dbt-Projekte und SQL-Dateien als Quellartefakte
Schemas und Volumes liegen in einer Grauzone, da beide Ressourcentypen sowohl in Terraform als auch in Asset Bundles definiert werden können. Empfehlenswert ist, die Anlage des Schemas einschließlich Owner und Grants in der Plattform-IaC zu halten und nur die schema-internen Inhalte über das Bundle zu deployen. Werden dieselben Ressourcen in beiden Werkzeugen definiert, entstehen zwei konkurrierende Konfigurationsquellen.
In einer produktiven Plattform werden beide Werkzeuge üblicherweise gemeinsam eingesetzt: Terraform legt Workspaces, Metastore-Schicht, Policies und Identitäten an, Bundles deployen die Workspace-Objekte hinein.
Vom UI-Job zum CI/CD-Bundle: Migration bestehender Databricks Jobs
Die Einführung von Asset Bundles lässt sich in drei klar abgegrenzte Schritte unterteilen.
Inventur und Generate
Erfassen, welche Workspace-Objekte produktiv genutzt werden und wie sie derzeit deployt werden – Jobs, Pipelines, Modelle aus welcher Quelle (UI, Terraform, Skript). Für UI-Jobs liefert `databricks bundle generate job --existing-job-id <id>` eine erste YAML-Definition, die anschließend bereinigt und parametrisiert wird.
Targets und Variablen
Pro Stage einen Target-Eintrag anlegen und umgebungsspezifische Werte (Host, Catalog, Schema-Suffix, Cluster-Policy-ID) in Variablen überführen. In Dev als User deployen, in Stage und Prod als Service Principal; ein Testdeployment in einer isolierten Umgebung deckt fehlende Variablen früh auf.
CI/CD-Strecke
Pull-Request-Trigger auf `validate`, Merge-Trigger auf Stage-Deploy, manueller Approval auf Prod-Deploy. Der bisherige UI-Job wird währenddessen vor manuellen Änderungen geschützt oder pausiert – die Bundle-Variante übernimmt die Schedule-Aktivität.
Was Asset Bundles nicht entscheiden: Workspace, Compute und Plattform-Architektur
Asset Bundles setzen auf bereits getroffenen Plattformentscheidungen auf. Grundlegende Architekturentscheidungen müssen unabhängig vom Bundle getroffen werden.
Workspace-Topologie
Wie viele Workspaces, mit welchem Schnitt (pro Team, pro Stage, pro Domäne)? Bundles verwenden bestehende Workspaces, legen deren Topologie aber nicht fest.
Cluster-Hoheit
Werden Cluster im Bundle definiert oder über Cluster Policies zentral vorgegeben? Beide Wege funktionieren, solange die Zuständigkeiten klar geregelt sind.
Compute-Modell
Job-Cluster, Shared-Cluster oder Serverless? Asset Bundles bilden verschiedene Compute-Modelle ab, geben jedoch keines davon vor.
Designer-Workflow
Lakeflow Designer kann Pipelines visuell bauen und als Bundle-YAML exportieren – die Designer-Ausgabe landet im selben Repo wie hand-geschriebene Bundles.
Wie wir Unity Catalog über mehrere Workspaces strukturieren, zeigen wir im Überblick zu Unity Catalog; wie sich Serverless für Jobs und Pipelines einordnet, im Überblick zu Serverless auf Databricks; wie der Designer-Export-Pfad in produktive Workflows passt, im Überblick zu Lakeflow Designer.
Diese Fragen sollten als übergreifende Plattformstandards entschieden werden. Sie sollten nicht individuell in jedem Bundle neu beantwortet werden.
Grenzen von Databricks Asset Bundles
Asset Bundles ist ein Deployment-Format für Workspace-Objekte. Wer Plattformlogik in Bundles verlagert, erhöht die Komplexität und verwischt Zuständigkeiten.
Workspace-scoped
Ein Bundle deployed in genau einen Workspace. Für mehrere Workspaces werden separate Targets verwendet – workspace-übergreifende Ressourcen werden nicht direkt durch ein Bundle verwaltet. Multi-Workspace-Topologien brauchen weiterhin Terraform für die darüberliegende Schicht.
Kein Account-Level-Scope
Account-API-Ressourcen (Workspaces, Account-IAM, Metastore-Bindings, Unity-Catalog-Metastores selbst) lassen sich nicht im Bundle definieren – dafür bleibt Terraform oder ein vergleichbares IaC-Werkzeug zuständig.
Unterschiedlicher Reifegrad der Resource-Typen
Jobs, Pipelines und Schemas haben stabile Resource-Definitionen. Neuere Resources wie Apps, Quality Monitors oder Genie Spaces sind nicht in jedem CLI-Release vollständig abgedeckt – vor dem Einsatz prüfen, welche CLI-Version sie vollständig unterstützt.
State im Workspace verwaltet
Der Deployment-State liegt im Workspace. Geht er verloren, lässt sich die Zuordnung meist durch ein erneutes Deployment wiederherstellen; ein vollständiger Reset erfordert `bundle destroy` plus erneuten Deploy. Backend-Locks gibt es als eingebauten Bundle-Lock pro Target.
Permissions-Drift bleibt möglich
Ein Bundle-Deploy plus parallele UI-Änderung am selben Job erzeugt Drift. Beim nächsten Deployment wird die im Repository definierte Konfiguration erneut angewendet und die UI-Änderung überschrieben – produktive Jobs sollten deshalb in der UI read-only bleiben.
Mit Blick auf diese Grenzen bleibt das Bundle, was es ist: das Deployment-Format für Workspace-Objekte. Ohne klare Zuständigkeiten werden Plattform- und Objektkonfigurationen mit den falschen Werkzeugen verwaltet, und die Trennlinie wird unscharf.
Fazit
Asset Bundles sind besonders sinnvoll, sobald mehrere Jobs, Pipelines oder weitere Workspace-Objekte reproduzierbar betrieben werden müssen.
Besonders relevant sind sie für Plattformen, auf denen Jobs bislang manuell oder über mehrere unterschiedliche Deployment-Wege verwaltet werden: hand-konfigurierte Jobs in der UI, paralleler Terraform-Code für Jobs und uneinheitliche, selbst entwickelte Deployment-Skripte. Ebenso für Teams, die Lakeflow Jobs, Declarative Pipelines und Designer-Exporte aus einem gemeinsamen Repo deployen wollen.
Gute Kandidaten sind:
- Unterschiedliche Jobkonfigurationen in Entwicklungs- und Produktionsumgebungen
- Workspace-Migrationen, die bislang manuell durchgeführt werden
- CI/CD-Pipelines, die auf selbst gebauten
databricks-cli-Wrappern aufsetzen - Sehr umfangreiche und schwer wartbare Jobdefinitionen in Terraform
- Lakeflow-Designer-Pipelines ohne klaren Repo-Pfad
Für Account-, Workspace-, Metastore- und Policy-Ressourcen bleibt Terraform oder OpenTofu zuständig. Accounts, Workspaces, Metastore, Cluster Policies und Account-IAM lassen sich im Bundle nicht definieren. Diese Ressourcen sollten weiterhin getrennt als Plattforminfrastruktur verwaltet werden.
Mein Vorschlag: Asset Bundles sollten als einheitlicher Deployment-Weg für Workspace-Objekte eingeführt werden, Terraform bleibt auf der Plattform-Schicht und Targets werden sauber pro Stage geführt. Werden dieselben Jobs zusätzlich in Terraform verwaltet, entstehen zwei konkurrierende Konfigurationsquellen, die mitlaufen und Pflege kosten.
Entscheidend ist nicht die Einführung eines weiteren Werkzeugs. Ziel ist eine eindeutige Aufteilung zwischen der Verwaltung der Plattforminfrastruktur und dem Deployment der Workspace-Objekte.
Als erster Schritt sollte eine Pipeline mit Validierung im Pull Request und automatischem Stage-Deployment nach dem Merge eingerichtet werden; ein manueller Approval-Schritt vor Prod schließt die Strecke.
FAQ
Databricks Asset Bundles (DABs) ist das offizielle YAML-Deployment-Format für Workspace-Objekte. Ein Bundle definiert Jobs, Lakeflow Declarative Pipelines, registrierte Modelle, Model-Serving-Endpoints, Volumes, Schemas und Dashboards als Code, bindet sie an Target-Workspaces und deployed sie über die Databricks CLI. Das Format ist seit 2023 General Availability und Teil der Standard-CLI.
