What is Version Control and why does it matter?
Version Control, a term very familiar to Software and Web Development teams, is the management of changes to documents, computer programs, large web sites, and other collections of information. As self-service Business Intelligence tools like Power BI adoption rates are on the rise, version control is becoming more and more necessary for Business and Data Analysts. However, for most non-developer staff at small to large organizations may find it difficult to procure a license for Visual Studio, GitHub, or other version control services.
Power BI has no inherent version control strategy for production-reports. Of course, many Power BI developers or audience members are aware of saving new versions with different filenames such as “Quarterly Business Report – Broken.pbix” or “Sales Management – Working.pbix”. Using this strategy of development can get out of hand quickly, and worse, adds bloat to your storage.
The Business Intelligence Team at IronEdge employs Visual Studio’s Azure DevOps connection which requires a developer’s license for each member of the team that works on reports. If you find yourself struggling with version control issues in Power BI while developing production reports, there is hope indeed. In this post I will outline a no-overhead version control strategy for all file types, with a focus on Power BI, and close it out with a potentially time saving governance strategy for your Power BI reports in the Power BI service. I must emphasize, however, that if you have the means TFS (Azure DevOps) or GitHub are a much more refined and low cost alternative for non-developers.
A Version Control approach to report development.
For many Power BI Developers or development teams, a license for a Team SharePoint Site is made available and is widely used for file-sharing on O365. Aside from its ability to host files for teams to share files and provide a file location for Power BI service, SharePoint Online allows for version control for any type of file that is uploaded. To view version history, simply hover over a file in SharePoint and click on the actions button to the right of the name of the file. (Note: In this example I am creating and modifying a .pbix file)
In the context menu, you’ll find the ‘Version History’ button, clicking this will bring up a new dialogue menu outlining the versions of the file that have been uploaded to SharePoint.
This Version History dialogue box contains the version number, the modified date and time, the author of the modification (which includes creation), and the size of the file at the point of check in. Note that in the screenshot above, the file version 1.0 does not have comments, and the version 2.0 was checked out then immediately checked in and given a comment. Additionally, the version number only iterates by an integer of 1, with no ability to add a decimal point or further digits, at least for now.
Comments in SharePoint Online
In the screenshot above showing the dialogue box for the Version history, there is a column for comments. In your SharePoint Online implementation, you may see a column for comments displayed in the line where the file is shown.
The comment column comments in a SharePoint folder differ from the comments in the version history check in comments. The comments shown in the “Comments” column are modified or created in the right hand details menu. A comment is made by clicking on the comments in the right-hand menu and entering text and clicking the check mark when done.
To create comments in the version history dialogue box you must utilize the Check In/Check Out feature in SharePoint.
Checking in/out and Version comments
Checking In and Checking Out files is a fundamental practice in Version Control hosting services. Checking out in either GitHub, Visual Studio, GitLab or any other hosting service provides notice to your team that you are either working on, reviewing or changing a file or file-tree. To check a file out in SharePoint Online there are a few options, the main method beginning with the context menu on a specific file. The Check Out option is listed in the “More” sub-menu.
Checking out a file does not download the most recent version in SharePoint however, and you will have to do that yourself. When a file is checked out, there will be a notification in the SharePoint window that you have successfully checked it out. Once checked out, the file will have an icon that points out to viewers that it is checked out. Also, any team members or those with access will not be able to edit the file by uploading a new version. Note: this is for non-Office files like Excel or Word files that are operating as an online file.
Example of Checkout Icon in Sharepoint
Once you have made your edits to the file and are ready for it to be updated as a new version, first upload and replace the file. After it has successfully been replaced, go back to the context menu where the Check Out button is found, and click “Check In”. You will be prompted to enter comments for the check in, and here is where you can enter a comment that will appear in the Version History dialogue box.
Example of Check In Comments
Version History Dialogue with check in comments.
Some considerations to Check Outs and Check Ins: You cannot create an initial comment for Version 1.0, and in the screenshot above Version 2.0 was created by simply checking out the file and checking in with a comment added. The only new version in the screenshot is version 3.0 where I had uploaded right before checking in. To make things simpler refer to the check list below. The order of operations ensures that there will not be a version for a premature Check In and then the edited file upload.
Version History Process for Sharepoint Online
- Check out the file you would like to edit, ensuring no one with access can overwrite the file.
- Make changes to the file.
- Upload and Replace the file in the same SharePoint folder.
- Open the context menu for the file and Check In.
- A prompt will open to enter version comments.
It is important to remember that this methodology for Version Control does not support the features required for an entire software code-base nor is it as robust as many git hosting services or Azure DevOps/Visual Studio. You cannot check out an entire folder and its contents, nor can you see differences in the file between versions in a side-by-side view. This process is mostly manual and can be a boon to teams that find it difficult to attain new licensing for software or services. This process also has a lower barrier to entry in that if a user is comfortable with SharePoint online, there is a good chance that this process can be adopted by users with even entry-level proficiencies.
As you can see, a version control strategy is in your grasp with no requirement to procure a license for any third party tool. SharePoint has the means to get your team on a rudimentary Version Control strategy immediately, with very little training required. I will reiterate though that if you are able to acquire a license for another Version Control tool for your team, it will be a boon to ensuring your team is able to be on the same page with evolving projects especially while so much of the workforce is working remote. Once you have mastered the process of leveraging sharepoint as a source for version control, be sure to look out for the next post in the series where I will discuss how to leverage these processes in your report administration strategy.