In this post I want to explain the importance of shifting left when testing Microsoft Fabric deployments. Especially when looking to work with the recommended development process for Microsoft Fabric by Microsoft.
To help with some jargon , shifting left is a development term for moving your testing to be as early as possible in your development process.
By the end of this post, you will know the importance of shifting left when testing Microsoft Fabric deployments. Along the way I provide plenty of links and some examples based on Microsoft’s recommended development process.
If you need help with any Git related jargon used in this post, then I recommend that you read my Microsoft Fabric Git integration jargon guide.
Importance of shifting left when testing Microsoft Fabric deployments
When you intend to perform CI/CD it is vital to implement good development practices. One of which is shifting left to ensure that your testing is done as early as possible in your development process.
Doing this means that if you make a change in your feature workspace that can cause an issue you can catch the issue early in the process. Avoiding any breaking changes affecting other environments.
Which provides you with the easy options to either revoke your change or remove the feature branch and start again. Whereas if you do not test the change and you release to other environments anybody else working with those workspaces are affected.
Plus, depending on the environment where the issue is identified there may be a bigger impact. Potentially requiring more time and effort to resolve.
I often get people asking if the additional development work is worth it. So, I created the below diagram to highlight the potential impact of changes causing issues in different environments.
As you can see, the further along the deployment process an issue goes undetected the greater the impact it has.
Microsoft’s recommended development process
Last September Microsoft released an article with their advice on how to choose the best Fabric CI/CD workflow for you.
Within their article they state that the development process should be the same for all of the suggested deployment scenarios in that article. Their suggestion is to work in an isolated environment to work on a specific feature. Which can be either:
- A separate Microsoft Fabric workspace connected to a feature branch for a specific repository.
- Alternatively, somebody working with an IDE on their local machine where they work with a clone(copy) of the Git repository locally that has a feature branch. For example, working with a Power BI Desktop project in Power BI Desktop.
Microsoft recommends in their article that once done you then merge your updates with the feature branch in the remote repository stored in either Azure DevOps or GitHub. From there, merge the update(s) with next branch you intend to use.
You can visualize this in the below diagram based on a Git repository stored in Azure DevOps.
In reality, the branch names shown above can change depending on your release process and naming conventions
For example, if you intend to deploy using Fabric deployment pipelines you will probably call the preceding branch a name that aligns with the development stage. You can then look to deploy the updates to the other stages within Microsoft Fabric deployment pipelines. Like in the below diagram.
Shifting left with the recommended development process
I really like the fact that Microsoft documented various options. One additional thing I want you to consider though is to shift left. By implementing Continuous Integration into your development process in the form of unit tests.
Ideally by performing your unit or integration tests when you look to merge updates from your feature branches to your development branch. In order to catch potential issues early in your development process.
For example, if you have multiple people working on a Power BI report both in a Fabric workspace and in Power BI Desktop you can look to implement Continuous Integration (CI) tests to catch issues early in the process.
One way you can do this is by using the technique described in the Power BI Project (PBIP) and Azure DevOps build pipelines for validation article.
Which covers running a pipeline in Azure DevOps every time somebody wants to merge to a certain branch. In order to check the quality of your semantic model and Power BI report. You can visualize this in the below diagram.
In reality, the above is a simplified diagram to show how the process works. In my previous post I went into further detail about two happy together paths to test semantic models in Microsoft Fabric feature workspaces.
Other Microsoft Fabric items
One key point I want to highlight is that you can test more than just Power BI reports and semantic models with this approach.
For instance, you can also test Microsoft Fabric Data Pipelines with the Data Factory Testing Framework.
You can find out more about the Data Factory Testing Framework on the Fabric Community blogs. Where I published a post that covers my initial tests of the Data Factory Testing Framework.
Plus, I previously published a post that provides options to perform unit tests on Fabric items.
Final words about shifting left when testing Microsoft Fabric deployments
I hope that by sharing the importance of shifting left when testing Microsoft Fabric deployments I am encourage more of you to think more about your testing strategies.
Because it is vital that you catch issues at an early stage for a variety of reasons. Including potential time savings and avoiding damaging your reputation. Plus, it shows stability and reliability in your Microsoft Fabric deployments.
Of course, if you have any comments or queries about this post feel free to reach out to me.
Be First to Comment