Bundle deployment history
This feature is in Private Preview. To try it, reach out to your Databricks contact.
Deployment history provides a structured, auditable record of every Declarative Automation Bundles deployment in your workspace. A deployment is a bundle deployed to a specific target. Each time you deploy, a new version is recorded.
For each deployment, you can review:
- Deployment metadata: The identity who deployed, the timestamp, the target, and the resulting status.
- Source control context: The Git repository, branch, commit SHA, and any release tag associated with the version.
- Resource changes: The resources created, updated, deleted, or recreated in each version, along with configuration diffs.
- Post-deploy state: The full inventory of resources managed by the deployment, such as jobs, Lakeflow pipelines, dashboards, and Unity Catalog tables.
Deployment history is a single place to validate deployments, investigate regressions, and answer questions such as who last modified a job or pipeline. It's the foundation for governed deployments for teams that manage Databricks resources as code.
For an overview of bundles, see What are Declarative Automation Bundles?. To learn how to deploy a bundle, see Deploy bundles and run workflows from the workspace and Declarative Automation Bundles deployment modes.
Enable deployment history
To record deployment history for a bundle, set record_deployment_history to true in the bundle configuration. See Configuration reference.
View deployments
To view deployments, do one of the following:
- From a bundle's Deployments pane, open the deployment history for that bundle. See Deploy bundles and run workflows from the workspace.
- For a job, pipeline, or dashboard managed by a bundle, use the Managed by indicator to jump to the deployment that owns it.
- Search for a bundle by name to open its deployment history directly.
The deployments list displays all deployments (and corresponding versions and resources) that you have CAN_READ access to.
You can filter and sort the list by the following columns:
Column | Description |
|---|---|
Name | The bundle and target, or the deployment display name. |
Target | The deployment target, such as |
Status | The state of the latest deployment. |
Last deployed at / by | When the deployment last ran and the identity who ran it. |
Resource count | The number of resources the deployment manages. |
View deployment version details
Select a deployment from deployment history to open its details, then select a version to discover information such as when the deployment was initiated and by whom, the source Git repository and branch, the commit SHA (linked to the diff in your Git provider), and the release tag, if one applies.
Use the version history dropdown in the header to move between versions.
Resource changes
The Changes tab lists changes made to resources in the selected version. It includes:
- Resource changes: A table of the actions taken per resource, showing the resource key (such as
jobs.ETL_Main), the action (Create, Update, Delete, or Recreate), the status, and the timestamp. - Configuration diff: A side-by-side comparison that highlights which settings changed, such as cluster size or schedule.
- Notebook snapshots: For notebook resources, a link to the notebook revision that was deployed.
- Errors: Failed updates show an inline error message.
Post-deploy state
The Post-deploy state tab shows the inventory of live resources the deployment manages after the version was applied:
- Resource key and type: The logical name and resource type.
- Databricks ID: The physical resource ID, linked to the resource in the workspace.
- Last changed: The version that last modified the resource, such as
Changed in v42.
Deployment history from the CLI
For automated workflows, you can access deployment history with the Databricks CLI bundle-deployments commands. See databricks bundle-deployments.
Limitations
- Deployment history is only available for new bundle deployment targets. There is no migration path yet for existing bundles or targets.
- Underlying entities of deployments (such as job runs) may have retention policies.
- Only deployments using the direct engine are supported. See Migrate to the direct deployment engine.