Hey @Gopal_PV ,
For Power BI Deployment Pipelines (Dev → Test → Prod), source control is handled through Git integration at the workspace level — not directly inside the deployment pipeline itself. The recommended approach for a small or medium-sized company is to treat Dev as the only Git-connected workspace, and use Deployment Pipelines strictly for promotion across environments.
Here is a clean and practical best-practice setup.
First, connect only the Dev workspace to Git (Azure DevOps or GitHub). This ensures all development changes are committed to a repository. Developers work only in Dev, commit changes with proper comments, and create pull requests for review. This gives you full version history, change tracking, and rollback capability.
Second, use a structured branching strategy. For small and medium teams, a simple model works best:
- main → Production-ready code
- dev → Active development
- feature branches → Individual work
Developers create feature branches, raise pull requests into dev, test changes, and once validated, merge into main before promoting to Production through the Deployment Pipeline.
Third, use Deployment Pipelines only for environment promotion (Dev → Test → Prod). Do not allow direct editing in Test or Prod workspaces. Lock down permissions so only Dev is editable. This prevents configuration drift and keeps everything Git-driven.
Fourth, parameterize environment-specific settings. Use:
- Data source parameters
- Deployment rules in the pipeline
- Different connection strings per stage
This avoids hardcoding server names, database names, or credentials inside reports.
Fifth, implement governance basics:
- Naming conventions for reports, datasets, and semantic models
- Folder structure in Git repository
- Mandatory pull request reviews
- Version tagging for production releases
For small/medium companies, keep it simple:
- One repository per Power BI project
- One Deployment Pipeline per solution
- Limited workspace admin access
- Documented release checklist
Important note: Only Power BI items stored in Fabric-supported format (PBIP projects) work well with Git integration. If you are still using PBIX files only, consider moving to the new Project (PBIP) format for better source control experience.
In summary, the best practice is:
Develop in Dev workspace connected to Git → Commit and review via pull requests → Merge to main → Deploy using Deployment Pipeline → No manual edits in Test/Prod.
If this explanation helped, please mark it as the solution so others can find it easily.
If it helped, a quick Kudos is always appreciated it highlights useful answers for the community.
Thanks for being part of the discussion!
