article How to use GitFlow and DABs for seamless Databricks Deployments in Technical Blog

How to use GitFlow and DABs for seamless Databricks Deployments

abhay-jalisatgi — Tue, 13 May 2025 12:51:18 GMT

🚀 Tired of chaotic Databricks deployments?
Discover how combining GitFlow, Databricks Asset Bundles (DABs), and GitHub Actions can bring structure, scalability, and sanity to your data workflows. Whether you're dealing with hotfixes, production releases, or parallel feature development, this guide shows how to tame complexity and deploy with confidence across DEV, QA, and PROD.

🔧 From version control to environment-specific automation—this is the CI/CD blueprint your data team needs.

👉 Read on to learn how to turn Git discipline into Databricks delivery excellence.

Re: How to use GitFlow and DABs for seamless Databricks Deployments

TomDudziak — Wed, 13 Aug 2025 13:44:27 GMT

Gartner already in 2020 recommended trunk-based development:
https://www.gartner.com/en/documents/3984368#:~:text=Summary,and%20more%20time%20delivering%20functionality

Atlassian encourages against Gitflow calling it a "legacy workflow" that "has fallen in popularity in favor of trunk-based workflows, which are now considered best practices":
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Why do Databricks still try to promote Gitflow?

Re: How to use GitFlow and DABs for seamless Databricks Deployments

Abser786 — Thu, 14 Aug 2025 14:47:57 GMT

Thanks for sharing the model and workflow for change management, I have a question that when two different team works on two project with their feature branches, only one project is ready for production deployment, in this case both team alreay merging their feature branches into develop branch periodically, so creating release branch from develop branch for production release will include other project as well right, this gives conflict, not?, so how should we handle it. I suggest to directly merge the release branch to main branch during prod release, your thought please.

Re: How to use GitFlow and DABs for seamless Databricks Deployments

abhay-jalisatgi — Sun, 07 Sep 2025 19:47:04 GMT

@TomDudziak

While trunk-based development is indeed considered an industry best practice for many engineering teams—especially those prioritizing continuous integration and rapid deployment—GitFlow still has value in certain contexts.Databricks often works with enterprise customers in regulated industries (finance, healthcare, public sector) where:

Long-lived release branches provide a clear audit trail for compliance.
Hotfix branches allow for controlled production patches without impacting ongoing feature development.
Multiple concurrent releases need to be managed for different environments or clients.

In these situations, GitFlow’s structured branching model can make release governance and risk mitigation easier, even if it trades off some of the speed and simplicity of trunk-based development.That said, Databricks doesn’t enforce GitFlow—it’s one of several patterns we support. For teams able to adopt trunk-based workflows, we actively encourage it, but we also recognize that some customer environments require the guardrails GitFlow provides.

Re: How to use GitFlow and DABs for seamless Databricks Deployments

abhay-jalisatgi — Sun, 07 Sep 2025 19:51:46 GMT

@Abser786
That’s a great question—you’re pointing at one of the classic trade-offs with GitFlow when multiple projects share the same develop branch.

You’re right that if both teams are merging into develop, then cutting a release branch from develop will naturally pick up all merged changes—even those not production-ready. This can cause the conflict you mentioned.

There are a few common ways teams handle this:

Feature toggles / flags: Teams merge regularly into develop, but production-incomplete features are hidden behind flags so they don’t affect the release branch.
Project-scoped release branches: Instead of treating develop as a single integration branch for everyone, teams can maintain separate “integration” branches per project and only merge into the shared develop once both projects are production-ready.
Release branch directly from feature branch (exception case): For urgent or isolated production releases, you can branch directly from the feature branch (or a hotfix branch) instead of from develop.
Trunk-based alternative: Some teams sidestep this problem by using trunk-based development and releasing from main with very short-lived branches.

Regarding your suggestion to merge release branches directly into main: that is a valid simplification if your team is comfortable treating develop purely as a staging/integration branch and using main as the only stable production branch. The trade-off is that you lose some of the isolation GitFlow’s release branch model provides for parallel stabilization.

In practice, the right approach depends on your team’s release cadence and whether features can be safely toggled off if they’re not ready.