Hi @DineshOjha,

I lost track of this... just remembered. Please see the responses below. 

1. Where to deploy Bundles in the workspace

Your proposed flow is perfectly compatible with Bundles and CI/CD best practices. On the workspace location... technically, you can set the target’s root_path to something like /Workspace/<service_principal>/<app_name> and deploy there, as long as the deploying identity (CI/CD SP) has permission to write into that path and humans who need to debug (e.g., app team) have at least read access. 

The Bundles docs commonly show a pattern like /Workspace/.bundle/${bundle.target}/${bundle.name} (or a similar structured path), and then you secure that folder. So structurally, you have two good options. Per‑SP home, per app subfolder (/Workspace/<service_principal>/<app_name>) and Neutral "system" root for all bundles (/Workspace/.bundle/prod/${bundle.name}).

From Databricks’ perspective, both are fine as long as the ACLs are correct. For a large estate (200+ apps), the neutral .bundle namespace tends to age better for discoverability and governance, but your per‑SP approach is not wrong.. It’s more of an org‑convention choice.

Running the jobs from Control‑M is also fine. You’re just triggering Databricks jobs via API, and the location of deployed assets doesn’t change that.

2. Source as Azure GIT repo vs Workspace

Your understanding is correct. If a job is configured with source = Git (Git‑with‑jobs, or Git folders), then the Databricks identity that pulls from Git (user or SP) needs Git credentials/permissions. If a job is configured with source = Workspace (tasks point at workspace notebook paths), and Azure DevOps does the git checkout and then calls databricks bundle deploy, then the Databricks service principal does not need Git access. DevOps talks to Git.... the SP only talks to Databricks.

Bundles already assume Git is your source of truth and handle deployment from the checked‑out repo into the workspace. In that model, it’s very common to use WORKSPACE as the job source (tasks reference the deployed notebook/script paths), and let Bundles + CI/CD ensure that workspace state is in sync with Git.

With the workspace source (with Bundles) approach, the simpler mental model is Git → CI/CD → Bundles → workspace; jobs read workspace. You also get full power of Bundles: targets, run_as, permissions, deployment modes, etc. And, there is no need to manage Git credentials on the Databricks SP unless you also use Git folders directly.

Git source (Git‑with‑jobs) approach is most useful if you aren’t using Bundles and want jobs to pull from Git directly at run time. More limited job/task types, and job configuration itself isn’t in source control in the same way as with Bundles.

Given you are standardising on Bundles and already using Azure DevOps, you may want to consider workspace source for jobs (deployed by Bundles), and keep Git access concentrated in Azure DevOps and any interactive developer identities.

3. CI/CD using DAB

The core best practice doesn’t change with Bundles. Keep unit tests (pytest) in your CI system, close to the code. This is still the primary mechanism for fast feedback and correctness, regardless of Bundles.

What Bundles add is a good place for integration tests where you define a test/run-unit-tests job as a resource inside the bundle (for example a small job that runs a test notebook or a script calling your wheel). 

The official Azure DevOps + Bundles example shows this pattern: build/test artifact, then deploy bundle, then run a test job from the bundle. So... keep pytests in Azure Pipelines as you do today, and optionally add bundle‑defined test jobs for integration/end‑to‑end checks.

4. Notebooks vs python tasks

A common pattern that fits what you’re doing today... Keep all real logic in a wheel (or at least a Python package). In jobs, either run a python_wheel_task directly (no notebook at all), or use a very thin notebook that imports your wheel and calls main() with parameters.

That gives you the best of both worlds. Testability and CI friendliness from the wheel, plus optional notebook ergonomics when you want them.

Hope this helps.

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