Development Lifecycle in Azure Databricks

• Databricks Git folders connect the workspace to a remote Git provider
• Production jobs should reference a specific branch or tag, not a mutable copy
• Never commit secrets to a Git folder
• Branch, commit, and push from the Git folder UI; open PRs in the provider
• Resolve merge conflicts by pulling main and reconciling text diffs
• A merge to main can trigger CI that deploys the change
• A layered strategy spans unit, integration, end-to-end, and UAT tests
• Unit tests run with pytest; integration and E2E tests exercise real jobs on test data
• A bundle can define a test job so CI runs tests on every deploy
• A bundle is defined in databricks.yml with resources and targets
• Development mode isolates deployments; production mode enforces production settings
• Variables and target overrides parameterize a bundle per environment
• databricks bundle validate checks the configuration before deploying
• databricks bundle deploy -t promotes a bundle to a target environment
• The REST API deploys resources programmatically using a service principal token
• databricks bundle destroy removes deployed resources
• The CLI takes a bundle variable's value from the first source that supplies one: --var, then BUNDLE_VAR_, then variable-overrides.json, then the target's variables mapping, then the default
• A variable declared with a lookup resolves an existing object's ID from its name at deploy time, and errors when the name matches no object or more than one
• Presets override a deployment mode's defaults, but an individual resource's own setting overrides the preset
• Unattended bundle deployment authenticates as a machine identity through environment variables, and silently falls back to the DEFAULT profile when nothing is specified
• Once run_as differs from the deploying identity, only jobs and pipelines are supported
• Adopting an existing job or pipeline starts by generating its bundle definition from the deployed object and then moving the code it references into the bundle's own source tree
• Binding a bundle resource to the existing workspace object is what makes the next deploy update that object instead of creating a second one, and the link is recorded per target
• Unbinding is the deliberate release step that leaves the workspace object in place and no longer subject to later bundle operations
• A permissions block declared at the top level of a bundle applies to every supported resource it defines, while a block on one job or pipeline covers only that resource
• The access levels a specific resource type accepts are broader than the set a bundle-wide block allows, so a run-but-not-modify grant or pipeline ownership has to be declared on the resource itself
• Operational access to bundle-deployed resources must be declared for a group rather than granted to individuals by hand in the workspace

Unlock with Premium — includes all practice exams and the complete study guide.