Paginated Reports (RDL) Version control

[ducky]

Hi 

is there any way that you have implemented versioning control directly on the RDL files? 

We use GIT to store our RLD files and then we push them via API to the PowerBI service but we dont know how to version the rdl file so that later we can use this version when we release to prod. 

for example with PBIX files we can save them to PBIP and use the version control but not the same can be done with RDL files. 

[Anonymous · Accepted solution]

Hi,@ducky .I am glad to help you.
I can not seem to find Microsoft's documentation on git for managing Power BI paginated reports version.
For PBIX files to be converted to PBIP format for versioning, this feature is also in the preview state. So I do not  think there's an official solution for RDL files yet, but maybe in the future your needs will be realised.
Luckily, I found an article discussing git's management of RDL paginated reports files, which also gives some alternatives.
The user himself creates a table for the report server that holds the version information of the report object.
I hope this helps!
URL:

A Versioning system for SSRS – SQLServerCentral

I hope my suggestions give you good ideas, if you have any more questions, please clarify in a follow-up reply.
Best Regards,
Carson Jian,
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[R1k91]

Paginated reports (RDL files) are versionable by design. they're (verbose) XML file therefore you can store them in any version control system. It has been done for ages since SSRS advent (we've dozens of them versioned in TFS, DevOps, GitHub etc.).
they're also supported in Git support for Fabric workspace, therefore you can include them in a git repo attached to your workspace and manage commits and deploy with Azure DevOps or GitHub. and then you can move them trough environments using deployment pipelines.

Overview of Fabric Git integration - Microsoft Fabric | Microsoft Learn

[Poojara_D12]

Hi @ducky 

To manage version control for RDL files:

1. Use Git: Store RDL files in Git, allowing you to track changes, view diffs, and revert to previous versions.
2. Automate Deployment: Use PowerShell scripts or the Power BI API to deploy RDL files from Git to Power BI Service or Report Server.
3. Versioning Convention: Name files with version numbers (e.g., Report_v1.rdl, Report_v2.rdl) or use Git tags for each deployment.
4. Track Metadata: Optionally, store deployment metadata (e.g., Git commit hash) for versioning reference.

This way, you can manage RDL versions similar to PBIX file versioning using Git.

Did I answer your question? Mark my post as a solution, this will help others!
If my response(s) assisted you in any way, don't forget to drop me a "Kudos" 🙂

Kind Regards,
Poojara
Data Analyst | MSBI Developer | Power BI Consultant
Consider Subscribing my YouTube for Beginners/Advance Concepts: https://youtube.com/@biconcepts?si=04iw9SYI2HN80HKS 

[Ray_Minds · Accepted solution]

Hi  While RDL files don't have built-in versioning like PBIX files with PBIP, you can effectively manage RDL file versions in Git by using branches, tags, and commit history. Using CI/CD pipelines or API calls to deploy RDL files ensures a streamlined and automated release process. Just like with PBIX files, leveraging Git for version control and implementing proper release practices will allow you to manage RDL file versions and releases efficiently. 

Step –1 Add RDL Files: You can store RDL files in a Git repository, similar to how you store PBIX files in version control. The RDL files will be treated as text (XML), and Git will track changes between commits, so you can see differences between versions of the file. 

Step –2  Structure Your Repository: Organize your repository in a way that makes sense for your project. For example, you might have separate directories for different environments (e.g., dev, staging, prod), and within each, store the corresponding RDL files. 

Step –3 Branches for Environments: You can use Git branches to represent different stages in the development process (e.g., development, staging, production), and each branch can hold the version of RDL files for that environment. 

Step –4 Tagging for Release Versions: Use Git tags to label specific versions of RDL files when you're preparing for a release. For instance, once you're ready to promote an RDL file to production, you can tag the commit with a version number like v1.0.0. 

Example : 

 git tag -a v1.0.0 -m "Release version 1.0.0" 

git push origin v1.0.0 

Step –5 Track Changes with Git Diff: When multiple users or teams are working on RDL files, you can use git diff to track what has changed in the XML between commits. This allows you to see specific modifications made to the report structure. 

Step –6 Merging RDL Files: If multiple people are editing the same RDL file, you may run into merge conflicts. Since RDL files are XML-based, Git will attempt to merge changes automatically, but you may need to manually resolve conflicts if the changes are complex. 

Best Practices Note: 

1. Store RDL in Git as Binary: Even though RDL is an XML-based file, treating it as binary in Git is an option if you want to avoid merge conflicts. However, this will prevent Git from showing line-by-line changes. The downside is that Git will not be able to track differences between versions automatically, and you may need to manually manage versioning. 
2. Frequent Commits and Descriptive Messages: Since RDL files can be large and complex, commit frequently with descriptive messages that explain what changes were made. This will make it easier to understand why changes were made when reviewing the history. 

   Step –7 CI/CD Pipelines: Automate the process of pushing RDL files to Power BI service using a CI/CD pipeline (e.g., using Azure DevOps or GitHub Actions). Once your changes are committed to a specific branch (e.g., prod), you can set up a pipeline that automatically pushes the latest version of the RDL files to the Power BI service via API. 

   Example: Set up a pipeline trigger for a git push to the prod branch that invokes an API call to push the RDL file to Power BI. 

   Step –8 Pre-Commit Hooks: You can set up Git hooks to validate the RDL files before committing. For example, you could use a pre-commit hook to check that the RDL file conforms to certain standards or has the correct metadata (e.g., version, environment). 

   Step –9 Versioning via File Name: Another option is to version the RDL file itself by including the version in the filename, like Report_v1.0.0.rdl. This is useful if you want to easily track which version of the report was deployed. 

   Example: If you have a release version 1.0.0 of a report, you can store it in your repository as SalesReport_v1.0.0.rdl. When you release a new version (e.g., v1.1.0), you would push the new RDL file as SalesReport_v1.1.0.rdl, keeping both versions in the Git repository. 

   If suggested steps helped in implementing your solution then please let us know by marking my post as a solution which can help the other community members to find it more quickly. 

@ducky

[Anonymous · Accepted solution]

Hi,@ducky .I am glad to help you.
I can not seem to find Microsoft's documentation on git for managing Power BI paginated reports version.
For PBIX files to be converted to PBIP format for versioning, this feature is also in the preview state. So I do not  think there's an official solution for RDL files yet, but maybe in the future your needs will be realised.
Luckily, I found an article discussing git's management of RDL paginated reports files, which also gives some alternatives.
The user himself creates a table for the report server that holds the version information of the report object.
I hope this helps!
URL:

A Versioning system for SSRS – SQLServerCentral

I hope my suggestions give you good ideas, if you have any more questions, please clarify in a follow-up reply.
Best Regards,
Carson Jian,
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.