Databricks repo - Azure Glossary

Understand the concept

In plain English

Databricks repo is the legacy/common name for Azure Databricks Git folders that connect workspace notebooks and files to Git repositories. In plain English, it helps teams manage Databricks code with branches, commits, pulls, pushes, reviews, and CI/CD instead of unmanaged workspace edits. You see it when teams clone a repository into a Databricks workspace, collaborate on notebooks, or promote code through dev, test, and production. It affects source control, collaboration, release quality, credential management, notebook ownership, CI/CD, audit evidence, and rollback. A useful review confirms owner, scope, evidence, and rollback before production changes.

Why it matters

Databricks repo matters because production Databricks code needs reviewable history, controlled promotion, and rollback rather than one-off notebook edits. Without a clear definition, teams can lose code changes, deploy unreviewed notebooks, mix personal credentials with production workflows, or fail to reproduce the commit behind a job run. The term gives architects, developers, platform engineers, security reviewers, data owners, and support teams common language for ownership, scope, identity, telemetry, rollback, and cost evidence. That matters during releases, audits, incidents, and budget reviews because a successful query, notebook, endpoint, or setting can still produce the wrong business outcome when dependencies are misunderstood.

Official wording and source

A workspace Git integration, now called Git folders, for versioning notebooks and files used in Databricks development and CI/CD. Microsoft Learn places it in Azure Databricks Git folders; operators confirm scope, configuration, dependencies, and production impact. Use the linked source for exact Azure behavior.

Open Microsoft Learn

Technical context

Technically, Databricks repo is surfaced through Git folders UI, workspace browser, Git credentials, Databricks CLI repos commands, branch dialogs, commit history, pull operations, and deployment bundles. Engineers validate it by checking repo path, remote URL, branch, commit hash, pull status, uncommitted changes, credential owner, workspace permissions, and jobs referencing files. Treat portal views, Databricks CLI output, workspace APIs, SQL, audit logs, and deployment files as separate evidence sources. The key detail is new documentation favors Git folders over Repos, but many teams still use repo language when discussing workspace Git integration.

Exam context

Compare with

Databricks notebook GitHub Actions deployment Repository

Where it is used

Where you see it

In the Databricks UI, Databricks repo appears near workspace Git folders, where operators confirm scope, ownership, permissions, health, and recent production changes. Reviewers capture evidence before approving the change.
In CLI or API output, Databricks repo appears as repo IDs, helping teams compare live state with deployment files and approved runbooks. Reviewers capture evidence before approving the change.
During incidents, Databricks repo appears when a production job fails and teams must prove which branch or commit, forcing support teams to connect symptoms with permissions, dependencies, and rollback options.
In architecture reviews, Databricks repo appears when platform teams design software delivery, helping teams explain risk, dependencies, ownership, evidence, and safe operating boundaries. Reviewers capture evidence before approving the change.

Common situations

Designing or reviewing Databricks repo for production Databricks workloads.
Troubleshooting access, reliability, cost, or performance symptoms related to Databricks repo.
Collecting audit or change evidence before changing Databricks repo in a live workspace.
Teaching architects and operators where Databricks repo fits in the Azure Databricks platform.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Insurance source control Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Evergreen Insurance, a insurance organization, needed to solve production notebooks changed without a reliable commit history. The platform team used Databricks repo to turn a risky operating gap into a governed Azure Databricks workflow.

Goals

Move Databricks code into Git folders
Tie job runs to reviewed branches or commits
Reduce rollback time below thirty minutes
Remove personal Git credentials from shared operations

Approach using Databricks repo

The team designed the solution around Databricks repo rather than treating it as background terminology. The platform team replaced unmanaged workspace edits with Git folders and documented branch, pull, commit, and promotion procedures. Job tasks referenced reviewed paths, and Git credential events were added to the audit checklist. They documented the owner, production scope, identity path, network boundary, monitoring signal, cost assumption, and rollback step. Read-only CLI, SQL, or API checks were captured before release, while mutating actions were limited to approved change windows. The design integrated with Unity Catalog, Azure Monitor, Microsoft Entra groups, tags, deployment records, and workload run history so support engineers could verify the same answer from the workspace UI and command line.

Potential outcomes

Rollback time fell from four hours to twenty minutes
All production jobs referenced reviewed repository paths
Three personal credentials were removed from shared workflows
Change review defects dropped thirty two percent

What to learn

Git folders make Databricks code operationally traceable instead of workspace-local guesswork. For glossary readers, Databricks repo is valuable when evidence, ownership, and safe operations are designed together.

Scenario 02 Retail inventory delivery Scenario, objectives, solution, measured impact, and takeaway.

Scenario

FreshCart Grocery, a retail organization, needed to solve data engineers duplicated notebooks across workspaces to test inventory logic. The platform team used Databricks repo to turn a risky operating gap into a governed Azure Databricks workflow.

Goals

Create a single repository workflow for dev, test, and production
Reduce duplicate notebook copies by fifty percent
Improve peer review before release
Support CI/CD promotion for inventory jobs

Approach using Databricks repo

The team designed the solution around Databricks repo rather than treating it as background terminology. Engineers cloned the repository into Databricks Git folders, standardized branches, and linked deployment jobs to reviewed notebook paths. They separated exploratory notebooks from production tasks and documented pull procedures. They documented the owner, production scope, identity path, network boundary, monitoring signal, cost assumption, and rollback step. Read-only CLI, SQL, or API checks were captured before release, while mutating actions were limited to approved change windows. The design integrated with Unity Catalog, Azure Monitor, Microsoft Entra groups, tags, deployment records, and workload run history so support engineers could verify the same answer from the workspace UI and command line.

Potential outcomes

Duplicate notebook copies dropped seventy percent
Inventory release defects fell twenty seven percent
Peer reviews happened before workspace promotion
Production job source could be traced to one branch

What to learn

A Databricks repo keeps collaboration disciplined when multiple workspaces share the same codebase. For glossary readers, Databricks repo is valuable when evidence, ownership, and safe operations are designed together.

Scenario 03 Port scheduling code Scenario, objectives, solution, measured impact, and takeaway.

Scenario

HarborWorks Port Authority, a public sector organization, needed to solve analytics code for vessel scheduling was locked inside one administrator workspace path. The platform team used Databricks repo to turn a risky operating gap into a governed Azure Databricks workflow.

Goals

Make scheduling code accessible to approved engineers
Preserve branch history for operational changes
Avoid leaking secrets in committed notebooks
Provide rollback evidence during peak shipping windows

Approach using Databricks repo

The team designed the solution around Databricks repo rather than treating it as background terminology. The team moved notebooks and files into a Git folder, replaced embedded credentials with secret references, and required branch-based review. Read-only CLI checks captured repo path, remote URL, and current branch before releases. They documented the owner, production scope, identity path, network boundary, monitoring signal, cost assumption, and rollback step. Read-only CLI, SQL, or API checks were captured before release, while mutating actions were limited to approved change windows. The design integrated with Unity Catalog, Azure Monitor, Microsoft Entra groups, tags, deployment records, and workload run history so support engineers could verify the same answer from the workspace UI and command line.

Potential outcomes

Approved engineers gained controlled access without admin sharing
Two embedded secrets were removed before commit
Peak-window rollback evidence was available immediately
Scheduling release approvals became audit-ready

What to learn

Databricks repo practices protect both code history and the operations that depend on that code. For glossary readers, Databricks repo is valuable when evidence, ownership, and safe operations are designed together.

Azure CLI

Use CLI and API checks for Databricks repo when you need repeatable evidence instead of a one-off workspace screenshot. Read-only commands confirm live configuration, permissions, identifiers, and health before a change window.

Useful for

Inventory Databricks repo across workspaces before migration, access review, audit, or production release.
Compare live Databricks repo settings with Terraform, Databricks Asset Bundles, SQL definitions, or runbook expectations.
Capture read-only evidence for incidents, compliance reviews, cost analysis, and rollback planning.
Confirm related identities, permissions, endpoints, clusters, warehouses, or catalogs before running mutating commands.

Before you run a command

Confirm the active Azure subscription, Databricks workspace host, authentication profile, and tenant before collecting evidence.
Use read-only list, get, describe, show, or query commands first; separate discovery from mutation.
Check whether the command uses Azure CLI, Databricks CLI, SQL, or a workspace API, because authentication scopes differ.
Record the target workspace, catalog, schema, object name, endpoint, cluster, or warehouse in the change ticket.

What the output tells you

Whether Databricks repo exists in the expected workspace, account, catalog, schema, endpoint, or compute scope.
Which owner, identifier, permissions, status, runtime, size, path, or dependency fields are currently configured.
Whether the issue is missing access, wrong workspace, stale metadata, unhealthy compute, or a downstream dependency.
Which related object should be checked next before approving a production change.

Mapped commands

Databricks repo operational checks

direct

databricks repos list

databricks repos get <repo-id>

databricks repos update <repo-id> --branch <branch>

databricks git-credentials list

Architecture context

Pillar: Azure Well-Architected Framework Security: Security review for Databricks repo focuses on Git credentials, repository permissions, workspace ACLs, branch protections, secret leakage in notebooks, service principal access, and audit logs for credential changes. Do not assume that workspace visibility, a successful query, or a working notebook proves access is appropriate. Check Microsoft Entra groups, workspace permissions, Unity Catalog privileges, secret scopes, service principals, managed identities, private connectivity, storage credentials, and audit logs as applicable. Use read-only commands first and capture evidence before changing policy. In production, least privilege should map to named groups, applications, owners, approved tickets, and tested runbooks. Remove broad access, stale tokens, unmanaged secrets, and undocumented exceptions before incident paths form. Reliability: Reliability for Databricks repo depends on known commit state, branch discipline, job references, pull behavior, deployment bundle consistency, rollback to prior commits, and protection from accidental workspace edits. A glossary term becomes operationally useful when support teams can predict what fails if it is missing, stale, misconfigured, overloaded, or deleted. Check job dependencies, serving endpoints, query history, lineage, retry behavior, monitoring alerts, deployment dependencies, and owner escalation before changing live configuration. For Databricks platforms, also verify replay, idempotency, cluster or warehouse availability, and last successful run. The goal is boring recovery: detect failure, protect data, restore service, and explain the incident without guessing. Operations: Operations for Databricks repo asks how it is deployed, observed, changed, and restored. Start by finding the owning account, workspace, catalog, schema, endpoint, cluster, warehouse, repo, or job. Then compare the UI with Databricks CLI output, workspace APIs, SQL definitions, notebooks, Terraform, bundles, audit logs, and run history. Keep runbooks clear about safe read-only checks, escalation, rollback, and expected owners. For production, alerts, tags, permissions, naming, and deployment records should show what changed, when it changed, and whether the current state matches design. Capture owner, scope, evidence, and rollback before changing production. Capture owner, scope, evidence, and rollback before changing production. Cost: Cost impact for Databricks repo comes from wasted engineering time from untracked changes, failed deployments, duplicate repos, long-running debug sessions, and jobs rerun because source versions are unclear. The term may look like a governance or development detail, but it can drive cluster hours, SQL warehouse usage, serverless serving spend, storage growth, metadata sprawl, diagnostic retention, or wasted troubleshooting time. Operators should ask whether the setting is necessary, right-sized, scheduled, tagged, and observable. Use usage dashboards, query history, serving metrics, job run history, and cloud cost analysis before assuming more capacity is the answer. Good cost control keeps evidence close to the workload and owner. Performance: Performance review for Databricks repo looks at notebook and job performance is indirect, but repo discipline improves testability, dependency management, review quality, and repeatable performance baselines. The fastest fix is not always larger compute; sometimes the problem is weak file layout, missing optimization, poor warehouse sizing, a cold endpoint, broad permissions, inefficient notebooks, stale metadata, or an untested model dependency. Check latency, throughput, queue time, query plans, Spark metrics, endpoint metrics, run duration, and user-visible delay where applicable. Then test one controlled change at a time. Good performance work ties measurements to user impact and avoids masking design issues with larger resources.

Security: Security review for Databricks repo focuses on Git credentials, repository permissions, workspace ACLs, branch protections, secret leakage in notebooks, service principal access, and audit logs for credential changes. Do not assume that workspace visibility, a successful query, or a working notebook proves access is appropriate. Check Microsoft Entra groups, workspace permissions, Unity Catalog privileges, secret scopes, service principals, managed identities, private connectivity, storage credentials, and audit logs as applicable. Use read-only commands first and capture evidence before changing policy. In production, least privilege should map to named groups, applications, owners, approved tickets, and tested runbooks. Remove broad access, stale tokens, unmanaged secrets, and undocumented exceptions before incident paths form.
Cost: Cost impact for Databricks repo comes from wasted engineering time from untracked changes, failed deployments, duplicate repos, long-running debug sessions, and jobs rerun because source versions are unclear. The term may look like a governance or development detail, but it can drive cluster hours, SQL warehouse usage, serverless serving spend, storage growth, metadata sprawl, diagnostic retention, or wasted troubleshooting time. Operators should ask whether the setting is necessary, right-sized, scheduled, tagged, and observable. Use usage dashboards, query history, serving metrics, job run history, and cloud cost analysis before assuming more capacity is the answer. Good cost control keeps evidence close to the workload and owner.
Reliability: Reliability for Databricks repo depends on known commit state, branch discipline, job references, pull behavior, deployment bundle consistency, rollback to prior commits, and protection from accidental workspace edits. A glossary term becomes operationally useful when support teams can predict what fails if it is missing, stale, misconfigured, overloaded, or deleted. Check job dependencies, serving endpoints, query history, lineage, retry behavior, monitoring alerts, deployment dependencies, and owner escalation before changing live configuration. For Databricks platforms, also verify replay, idempotency, cluster or warehouse availability, and last successful run. The goal is boring recovery: detect failure, protect data, restore service, and explain the incident without guessing.
Performance: Performance review for Databricks repo looks at notebook and job performance is indirect, but repo discipline improves testability, dependency management, review quality, and repeatable performance baselines. The fastest fix is not always larger compute; sometimes the problem is weak file layout, missing optimization, poor warehouse sizing, a cold endpoint, broad permissions, inefficient notebooks, stale metadata, or an untested model dependency. Check latency, throughput, queue time, query plans, Spark metrics, endpoint metrics, run duration, and user-visible delay where applicable. Then test one controlled change at a time. Good performance work ties measurements to user impact and avoids masking design issues with larger resources.
Operations: Operations for Databricks repo asks how it is deployed, observed, changed, and restored. Start by finding the owning account, workspace, catalog, schema, endpoint, cluster, warehouse, repo, or job. Then compare the UI with Databricks CLI output, workspace APIs, SQL definitions, notebooks, Terraform, bundles, audit logs, and run history. Keep runbooks clear about safe read-only checks, escalation, rollback, and expected owners. For production, alerts, tags, permissions, naming, and deployment records should show what changed, when it changed, and whether the current state matches design. Capture owner, scope, evidence, and rollback before changing production. Capture owner, scope, evidence, and rollback before changing production.

Common mistakes

Treating Databricks repo as an isolated object instead of checking identity, Unity Catalog, networking, monitoring, and cost context.
Running mutating commands before confirming the Databricks profile, workspace URL, Azure subscription, and target name.
Using a personal admin token for production evidence instead of approved service principal or group-based access.
Assuming a successful notebook, query, or endpoint call proves the design is secure, reliable, and cost-controlled.