The Release Branching Model is a Project Management/Development model for enterprise Power BI projects. It borrows proven concepts from other Git branching models, provides a high degree of automation in conjunction with the source control and deployment features of
pbi-tools, and enables teams to successfully collaborate on Power BI report and dataset projects (support for Dataflows coming).
In short, it answers the question:
How to get changes into Production in a structured, fast, and controlled way?
- Continuously ship business value: A regular, predictable release cadence improves buy-in from business, see Versioned Releases.
- Production is guarded: Direct Production access removed in favor of system-driven workflow.
- Enable parallel development: Scalability is achieved by dividing work on a milestone among different team members.
- Deployments are automated: Removal of manual steps provides maximum consistency and reliabilty.
- Hold all communication in one system: The DevOps project (combining git repository, issue tracker, PR reviews) automatically becomes a vital repository for organizational knowledge.
- Quick feedback: Developers get to see their changes in a Dev/Test environment immediately, removing blockers and delays.
How it works
In a nutshell
mainbranch always represents Production.
- All previous releases are tagged in the git repository.
- Before work on a new release starts, features and bugs from the backlog are grouped together in a release milestone and a new
Release/x.xbranch is created off
- Developers begin work on issues assigned to them by creating a new feature branch (e.g.,
Issue/102-mt) off the Release branch.
- The developer creates a Pull Request (PR) from the Feature branch to the Release branch once work is ready for review. The PR triggers a deployment into the Dev/Test environment. Optionally, automated tests could be run at this stage, for instance using Tabular Editor’s Best Practice Analyzer.
- The Development Lead reviews the PR and raises questions on the PR conversation tab. Any further commits by the developer trigger new Dev/Test deployments.
- Once a PR is signed off, the changes are merged into the Release Integration branch, which triggers a deployment into the UAT environment. Here, feedback can be collected from external stakeholders.
- When all issues in scope have been integrated into the Release branch, Release Notes are updated and the Release branch is merged into
main, which triggers a Production deployment.
- The head of
mainis tagged with the version number, and a release is created in the project (GitHub/GitLab).
- The new release is now in Production.
Note: This effectively allows to work on Power BI projects similar to software projects, for which mature development workflows have long been established.
|Git Repository||Keeping all artifacts of a Power BI project under source control is required for change control, versioning, automated deployments, and team collaboration.|
|Issue Tracker/Backlog||It is key to hold all bugs and features for a given project in an issue tracker that’s integrated with the Git source control system. This allows to link all report/dataset changes to their corresponding issue, including all conversations that took place during review.|
|Release Milestone||Grouping a set of issues into a milestone as part of release planning is important since it defines a clear release scope and allows tracking of development progress using burn-down charts and other project management tools.|
|Versioned Releases||Similar to software releases (for instance, Power BI Desktop 2.106 or Visual Studio Code 1.68), Power BI datasets and reports can be developed as versioned releases: Each version represents a particular snapshot of features, and those versions can be referred to without ambiguity by business stakeholders, project leads, documentation writers, testers, developers. All git source control systems allow the tagging of particular points in a project’s history with a version number.|
|Deployment Environments||At least three environments are recommended for a Continuous Deployment setup: Dev/Test, Staging/UAT, Production. In a Power BI context, each environment usually consists of a different workspace.|
|CI/CD Pipeline||The CI/CD pipeline brings everything together in a highly automated fashion. Triggers ensure that processes are system driven. Ultimately, publishing access to Power BI workspaces can be removed from individual developers and entirely delegated to CI/CD pipelines, ensuring a maximum protection of Production environments.|
Note: All of the above are provided by any current DevOps system, for instance GitHub, Azure DevOps, GitLab, Bitbucket etc.
|Business Stakeholder(s)||They’re your customer and sponsor. Actively involve them in release planning. Convince them of a model that delivers value on a regular cadence. Involve them early as new features become available in UAT.|
|Project Lead||The most important role in the model. Enforces the process and enables the developer team. Could also be split between Product Owner and Technical Lead. Find a description of project lead workflows here.|
|Developer(s)||Require thorough training on the process. Will value the model once the delivery improvements become tangible. Find a description of developer workflows here.|
- How it works
- Setup: Power BI
- Setup: GitHub (Azure DevOps, GitLab instructions to follow)
- Workflows: Project Lead
- Workflows: Developer