Databricks Asset Bundles zijn nu Declarative Automation Bundles
Behandel een Databricks-project als één deployable release unit. Houd code, jobs, Lakeflow-pipelines, permissies en environment targets in version control en valideer, plan en promote daarna hetzelfde project door dev en productie.
Repository
Declarative Automation Bundle
Eén projectdefinitie
dev
developmentpersoonsnamen · schedules paused · snelle iteratie
prod
productiestabiele identiteit · controls · productieresources
Het project blijft consistent. Targets wijzigen de deploymentcontext zonder de codebase te klonen.
De productnaam veranderde. De bundleworkflow blijft compatibel.
Vóór 16 maart 2026
Databricks Asset Bundles
Huidige naam
Declarative Automation Bundles
Bestaande configuratie blijft geldig
De naamswijziging is non-breaking. Bestaande databricks.yml-bestanden en het databricks bundle CLI-command blijven werken.
Source control
ongewijzigd
databricks.yml
ongewijzigd
bundle CLI
ongewijzigd
Wat is veranderd
Gebruik de nieuwe naam, behoud hetzelfde projectmodel
Databricks hernoemde Asset Bundles omdat het woord asset ambigu was geworden op het platform. De nieuwe naam beschrijft het doel beter: declaratieve automatisering voor complete Data & AI-projecten.
Een bundle is een release-eenheid voor een project
Het combineert bronbestanden, resourcedefinities, artefacts en deploymenttargets.
De workflow is software engineering
Versiebeheer, code review, testen en CI/CD vormen de kern van de use case.
De scope is breder dan notebooks
Jobs, Lakeflow-pipelines, dashboards, schema's, volumes en veel andere Databricks-resources kunnen onderdeel zijn van dezelfde projectdefinitie.
Bundle-opbouw
Houd projectintentie naast de code
Een gerichte bundle moet de bestanden en Databricks-resources bevatten die één team volgens dezelfde lifecycle uitbrengt. Databricks adviseert kleinere bundles in plaats van één platformbrede bundle.
Manufacturing-project
factory-production-analytics
Eén ownership-grens, één promotion path en één releasecadans.
Wat databricks.yml coördineert
Het rootmanifest verbindt code, resources en deploymentcontext.
Bundle
identiteit + CLI-beperking
naam · databricks_cli_version
Opnemen
resource-configuratie
resources/*.yml
Variabelen
environmentinputs
catalogus · schema · warehouse
Targets
deploymentcontext
dev · staging · prod
Rechten
resource-toegang
groepen · service principals
Artifacts & sync
deploybare code
wielen · bestanden · gedeelde mappen
bundle:
name: factory-production-analytics
databricks_cli_version: '>= 1.3.0'
engine: direct
include:
- resources/*.yml
targets:
dev:
mode: development
default: true
prod:
mode: productionDezelfde bundle, andere operating mode
Targets moeten omgevingscontext wijzigen, niet aparte kopieën van het project maken.
Snelle, geïsoleerde iteratie
Stabiele identiteit en strengere controles
run_as identiteit die door jobs of pipelines wordt gebruikt hoeft niet dezelfde te zijn.Environmentstrategie
Gebruik één bundle voor dev, staging en productie
Databricks adviseert dat één bundle de omgevingen voor een project dekt. Gebruik target modes, variabelen en targetoverrides voor waarden die echt verschillen.
Clone de repository niet per environment
Promoveer hetzelfde Git-controlled project via verschillende targets.
Override alleen environmentconfiguratie
Catalogi, schema's, warehouse-referenties en run-identities kunnen variëren zonder businesslogica te dupliceren.
Houd secrets buiten de bundle
Gebruik Databricks-authenticatie, connections en secretmanagement. Bundlevariabelen zijn configuratie, geen secret store.
Deploymentworkflow
Zet een Git-wijziging om in een expliciet deploymentplan
Validatie vangt configuratieproblemen af. Planning laat zien wat er zal veranderen. Met de directe deployment-engine kan een JSON-plan worden beoordeeld en opnieuw afgespeeld, zodat de goedgekeurde acties ook daadwerkelijk op productie worden toegepast.
databricks bundle validate -t prod
databricks bundle plan -t prod -o json \
> plan.json
databricks bundle deploy -t prod \
--plan plan.jsonValideren
Plan
Deploy goedgekeurd plan
Selectief --select deployments zijn nuttig voor development, maar Databricks adviseert ze niet voor productiepromotie.
CI/CD
Gebruik CI/CD voor productiepromotie, niet een developerlaptop
Declarative Automation Bundles zijn de door Databricks aanbevolen CI/CD-aanpak. Gebruik voor geautomatiseerde deployments een service principal en waar mogelijk workload identity federation zodat de pipeline niet afhankelijk is van een langlevend Databricks-secret.
Review de bronwijziging
Pull-request-checks moeten code, tests en bundle-configuratie valideren vóór promotie.
Pipeline-identiteit federeren
Azure DevOps, GitHub Actions en andere CI-systemen kunnen OIDC-identitytokens uitwisselen voor Databricks OAuth-tokens.
Scheid deploy- en run-permissies
De CI-identity heeft permissie nodig om te deployen. De workload zelf kan draaien onder een dedicated run_as service principal.
Productie-promotion-lane
Van Git naar Databricks zonder opgeslagen deployment secrets
Ontwikkelaar
Pull request
bron + bundleconfiguratie
CI-pipeline
Control
Productiegoedkeuring
review exact geplande acties
Databricks
Deploy goedgekeurd plan
stabiele bundle-identity + production run_as
Bestaande resources adopteren
Breng bestaande jobs en pipelines onder bundlebeheer zonder ze opnieuw te maken
Bestaande workspace-resources kunnen worden omgezet in bundleconfiguratie. De belangrijke stap is de gegenereerde resourcedefinitie aan het bestaande remote object te binden voordat normale deployments het overnemen.
Generate
Create bundle YAML from an existing job, pipeline, dashboard or app.
Beoordeling
Remove workspace-specific noise and align the definition with your project standards.
Bind
Associate the bundle resource key with the existing remote resource ID.
Deploy
Apply future changes through the bundle without creating a duplicate resource.
databricks bundle generate job --existing-job-id 123456789
databricks bundle deployment bind factory_job 123456789 -t prod
databricks bundle plan -t prodDeploymentgrens
Gebruik Bundles voor Databricks-projecten en Terraform voor externe infrastructuur
De huidige Databricks developer guidance is duidelijk: gebruik Declarative Automation Bundles voor Databricks-resources in de projectlifecycle. Houd Terraform voor cloud-level resources en privileged platformadministration.
Declarative Automation Bundles
Project-owned Databricks-resources
Lakeflow Jobs en pipelines
broncode en artifacts
dashboards en projectschema's
resource-permissies en run-identities
Terraform + Azure CLI
Cloud- en platformfundament
Azure-networking en private endpoints
storage accounts en Key Vault
workspace- en accountprovisioning
adminacties buiten het projectteam
Direct-deployment-engine
De Terraform-backed bundle-engine wordt uitgefaseerd
De directe deployment engine is nu het huidige pad. Hij gebruikt de Databricks Go SDK, produceert rijkere plans en is niet langer afhankelijk van de Terraform-provider voor bundle-deploymentstate.
Origineel model
Terraform-engine gepland voor uitfasering
Bundle-deployments gebruikten oorspronkelijk de Databricks Terraform-provider en Terraform-state.
GA · CLI 1.3.0
Direct engine
Nieuwe bundles gebruiken standaard direct deployment. Plans kunnen field-level diffs tonen en tijdens deployment opnieuw worden afgespeeld.
CLI 1.14.0+
Automatisch migratiepad
Bundles die nog op de Terraform-engine draaien kunnen na een schone dry-run-conversie automatisch worden gemigreerd. Databricks adviseert over te stappen op directe deployment.
Snellere deployments
Databricks rapporteert deploymentverbeteringen tot 40% met de direct engine.
Replaybare plannen
Maak een JSON-plan, keur het goed en pas tijdens deployment precies dat plan toe.
Breder resourcebereik
Direct deployment ondersteunt aanvullende Databricks-resourcetypen en optionele immutable folders.
Gedeeld template
ffa-data-product-template
Productie
bundle A
Voorraad
bundle B
Levering
bundle C
Schaal de werkwijze
Standaardiseer met templates, niet met één gigantische bundle
Custom bundletemplates laten een platformteam folderstructuur, algemene CI-bestanden, tests en resource-defaults vastleggen. Projectteams behouden aparte bundle-identities en releasen onafhankelijk.
Maak een herhaalbaar startpunt
Gebruik databricks bundle init met een standaard- of custom template.
Houd bundles klein en gericht
Splits op ownership, permission boundary, releasecadans of behoefte aan onafhankelijke rollback.
Deel gemeenschappelijke code bewust
Meerdere bundles kunnen in één repository staan en gedeelde folders gebruiken waar gemeenschappelijke libraries echt bij elkaar horen.
Veelgemaakte fouten
Vermijd deploymentpatronen die environment drift opnieuw introduceren
Bundles helpen wanneer de projectdefinitie de source of truth is. Handmatige workspacewijzigingen en onduidelijk ownership ondermijnen dat model snel.
Vermijd
Separate bundle copies for dev and prod
Betere default
One bundle with environment targets
Vermijd
One giant bundle for the whole data platform
Betere default
Split by ownership and release lifecycle
Vermijd
Deploying production from a developer identity
Betere default
Use CI/CD with a production service principal
Vermijd
Long-lived CI secrets
Betere default
Use workload identity federation where possible
Vermijd
Generating YAML and deploying immediately
Betere default
Bind existing remote resources before adoption
Vermijd
Using --select for production promotion
Betere default
Promote the complete tested release unit
Vermijd
Keeping new bundles on the Terraform engine
Betere default
Use the direct deployment engine
Hoe Food For Analytics dit implementeert
Titan gebruikt bundles als release unit voor Databricks-dataproducten
Platforminfrastructuur en projectdelivery hebben verschillende lifecycles. Titan houdt Azure- en workspacefunderingen in platform-IaC, terwijl Databricks-jobs, pipelines en projectconfiguratie via Declarative Automation Bundles bewegen.
Start consistent
Titan-projecttemplate
Gemeenschappelijke repo-structuur, validatie, permissions en targetconventies worden één keer gedefinieerd.
Titan op Azure Databricks
Projectbundle
Ieder owned dataproduct kan als één source-controlled release-unit bewegen in plaats van afhankelijk te zijn van handmatige workspaceconfiguratie.
Promoveer bewust
Dev naar productie
CI valideert en plant de deployment, waarna productie de goedgekeurde bundledefinitie ontvangt.
FAQ
Veelgestelde vragen
Praktische antwoorden over Databricks Asset Bundles en Declarative Automation Bundles.
Wanneer zijn Databricks Asset Bundles hernoemd?
Databricks hernoemde Databricks Asset Bundles op 16 maart 2026 naar Declarative Automation Bundles. De hernoeming is non-breaking en bestaande bundleconfiguratie hoeft niet te worden herschreven.
Moeten nieuwe projecten de directe deployment engine gebruiken?
Ja. De direct deployment engine is generally available en is de standaard voor nieuwe bundles die met Databricks CLI 1.3.0 en hoger worden gemaakt. Databricks adviseert bestaande bundles op de Terraform-engine te migreren naar direct deployment omdat de oudere engine wordt uitgefaseerd.
Wat is het aanbevolen deploymentpatroon voor productie?
Gebruik een production target, deploy via CI/CD, gebruik een stabiele niet-persoonlijke bundle-identity en gebruik een service principal voor production workloads. Voor CI/CD-authenticatie adviseert Databricks waar mogelijk workload identity federation in plaats van long-lived secrets.
Zijn Declarative Automation Bundles een vervanging voor Terraform?
Niet voor het hele platform. Huidige Databricks-developerrichtlijnen adviseren Bundles voor Databricks-projectresources en Terraform voor cloud-level resources, workspaceprovisioning, networking en andere privileged platformadministratie.
Kunnen bestaande Databricks-jobs en pipelines in een bundle worden opgenomen?
Ja. Bundle-configuratie kan worden gegenereerd uit bestaande resources. Bind de gegenereerde bundle-resource vóór normale deployment aan de bestaande remote resource, zodat het bestaande object wordt bijgewerkt in plaats van gedupliceerd.
Moeten dev en productie aparte bundles gebruiken?
Meestal niet. Databricks adviseert één bundle per beheerd project over de verschillende omgevingen heen. Gebruik development- en production-targets om deploymentinstellingen, identiteiten en omgevingsspecifieke configuratie te variëren.
Praktische laag
Maak Databricks-releases herhaalbaar
Definieer de projectgrens, environmenttargets en productie-identity voordat je handmatige workspaceconfiguratie omzet in geautomatiseerde deployment.
Eén release-unit
Gereviewd plan
Gecontroleerde productie