In this post I want to encourage others to think about their Microsoft Fabric Continuous Integration maturity levels.
Like the potential Microsoft Fabric Continuous Integration (CI) maturity levels shown in the diagram below.
Because I want people to understand that there is more to implementing a good CI/CD strategy then simply configuring Microsoft Fabric Git integration and selecting a deployment method. You need to consider things like testing strategies as well.
Along the way I share plenty of links.
Microsoft Fabric Continuous Integration
Currently there are a lot of CI/CD options available for various Microsoft Fabric items. For example, Microsoft Fabric Deployment Pipelines, fabric-cicd and Fabric-CLI.
I feel that this has made people focus more on deciding the right deployment method instead of the main reasons as to why they need to implement CI/CD in the first place. Especially when it comes to making sure that the changes are in a workable state.
To highlight my point, the below is the direct quote from Wikipedia to describe Continuous Integration.
Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state.
You can achieve a basic level of good CI if you follow the recommended development process by Microsoft.
However, I feel that you can improve this by implementing a level of testing between your feature and development branches. Like in the below diagram that I shared in a previous post about semantic model testing.
In addition to this, you might want to consider setting up automated tests for other Fabric items as well. For example, you can configure testing Microsoft Fabric Data Pipelines with YAML Pipelines.
Of course, where you implement your testing can decide on various factors. Including your branch strategy and what data is contained in your different stages.
Potential Microsoft Fabric Continuous Integration maturity levels
After some thought about this topic, I came up with potential Microsoft Fabric Continuous Integration maturity levels.
Level two matches the recommended development process by Microsoft. Levels three and four build on it by adding automated tests. I came up with these levels as a starting point. You are more than welcome to customize them or suggest alternatives.
In addition, I must highlight the fact that the higher levels will not apply for all.
However, if you work in an environment with a large number of updates striving for the higher levels will reduce a lot of issues. Because you will be shifting-left more and identifying issues a lot earlier.
Which I highlighted in a previous post about shifting left when testing Microsoft Fabric deployments.
Final words
I hope that by sharing my potential Microsoft Fabric Continuous Integration maturity levels I am encouraging more of you to think more about your CI/CD strategies. Especially as far as implementing automated tests are concerned.
Because I feel that focusing on the integration stage can be just as important as your deployment method. Plus, it can bring many benefits. Including identifying issues at an early stage and avoiding damaging your reputation. It also 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