mode: development not working as expected

[kenmyers-8451]

Hey I'm trying to add mode: development to my "Development" target (which is default) but it does not seem to be working as I expected. Here is what my targets file looks like:

I'm deploying with this command: databricks272 bundle deploy -p dev3 -t Development

databricks272 = an installation of 0.272.0 (I work with a few different teams with different versions so this is the version this team is on), dev3 points to a specific databricks workspace (company has multiple dev workspace). I've tried it with and without -t defined and arrive at the same result.

This is what I see for the job being deployed:

What I expected: per the docs, I expected the job name to be prepended with my short name, [dev ${workspace.current_user.short_name}] and tag it with "dev". However I don't see either of these. This is definitely the resource being deployed by this bundle, if I destroy it then the above job disappears. Am I misunderstanding the definition of "all resources that are not deployed as files or notebooks"?

[kenmyers-8451 · Accepted solution]

I figured out my issue, this team was not including the targets file in their bundle and had a separate targets section in the databricks.yml file. Realized that the targets file wasn't including the variables when I tried to add another variable that wasn't getting used.

[Ale_Armillotta]

Hi @kenmyers-8451 .

I think you missed the presets configuration. If in the preset you add the name_prefix it works. Here there’s the link https://docs.databricks.com/aws/en/dev-tools/bundles/deployment-modes#presets

[SteveOstrowski]

Hi @kenmyers-8451,

Glad you tracked this down. This is a common gotcha with Databricks Asset Bundles (DABs) when splitting configuration across multiple files: if the file containing your target definition (with mode: development) is not listed in the include mapping of your root databricks.yml, the bundle CLI simply never sees it.

For anyone else who runs into this, here is what to check:

HOW INCLUDE WORKS

Your root databricks.yml must explicitly reference any additional YAML files using the include mapping. For example:

# databricks.yml
bundle:
name: my-bundle

include:
- "targets.yml"
- "resources/*.yml"

Without that include entry, settings in a separate targets file (mode, variables, workspace overrides, etc.) will be silently ignored. There is no error or warning, which makes this easy to miss.

WHAT MODE: DEVELOPMENT DOES

Once the target file is properly included, setting mode: development on a target activates these behaviors automatically:

1. Prepends resource names (jobs, pipelines, etc.) with [dev <your_short_name>]
2. Tags jobs and pipelines with a "dev" tag
3. Pauses all schedules and triggers
4. Enables concurrent job runs
5. Marks any Lakeflow Spark Declarative Pipelines as development: true
6. Disables the deployment lock for faster iteration

You can override any of these individually. For example, to keep a schedule active in dev:

targets:
Development:
  mode: development
  default: true

resources:
jobs:
  my_job:
    schedule:
      pause_status: UNPAUSED

You can also customize the prefix and other behaviors using the presets mapping under your target:

targets:
Development:
  mode: development
  presets:
    name_prefix: "custom_prefix_"
    tags:
      custom_tag: "value"

Full details on deployment modes and presets:
https://docs.databricks.com/en/dev-tools/bundles/deployment-modes.html

DEBUGGING TIP

If you ever suspect your configuration is not being picked up, you can run:

databricks bundle validate -t Development

This will show you the fully resolved bundle configuration, including which files were included and the final merged target settings. If your target or its mode does not appear in the output, that confirms the file is not being included.

Docs on the include mapping:
https://docs.databricks.com/en/dev-tools/bundles/settings.html

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.

If this answer resolves your question, could you mark it as "Accept as Solution"? That helps other users quickly find the correct fix.