Diagram showing the flow of Git based deployment using deployment pipelines.
With this option, Git is connected only until the dev stage. From the dev stage, deployments happen directly between the workspaces of Dev/Test/Prod, using Fabric deployment pipelines. While the tool itself is internal to Fabric, developers can use the deployment pipelines APIs to orchestrate the deployment as part of their Azure release pipeline, or a GitHub workflow. These APIs enable the team to build a similar build and release process as in other options, by using automated tests (that can be done in the workspace itself, or before dev stage), approvals etc.
Once the PR to the main branch is approved and merged:
A build pipeline is triggered that uploads the changes to the dev stage using Fabric Git APIs. If necessary, the pipeline can trigger other APIs to start post-deployment operations/tests in the dev stage. After the dev deployment is completed, a release pipeline kicks in to deploy the changes from dev stage to test stage. Automated and manual tests should take place after the deployment, to ensure that the changes are well-tested before reaching production. After tests are completed and the release manager approves the deployment to Prod stage, the release to Prod kicks in and completes the deployment. When should you consider using option #3? When you're using source control only for development purposes, and prefer to deploy changes directly between stages of the release pipeline. When deployment rules, autobinding and other available APIs are sufficient to manage the configurations between the stages of the release pipeline. When you want to use other functionalities of Fabric deployment pipelines, such as viewing changes in Fabric, deployment history etc. Consider also that deployments in Fabric deployment pipelines have a linear structure, and require other permissions to create and manage the pipeline.
- Apply_Changes_To_Branch.yaml: Yaml file to update the dev workspace after a PR has been approved
- Deploy_Changes_From_Source_To_Target_Workspace.yaml: Yaml file to deploy changes from a source workspace to a target workspace
- trigger_deployment_pipeline.ps1: Powershell script called by Deploy_Changes_From_Source_To_Target_Workspace.yaml to call the Deployment Pipeline Fabric Rest API
- workspace_update.ps1: Powershell script called by Apply_Changes_To_Branch.yaml to call the GIT Fabric Rest API got
- Run_post_activity.py: A Python script is triggered for post-deployment activities, launching a post-activity notebook to rebind connections, among other tasks. For more information please visit Run post activiy details. Please note that the post-activity notebook must exist and can be found here
- You need all the workspaces required for your workflow (DEV, UAT, XXX, Prod)
- If you want to automate this part please visit this page for an example
- You need to have create a Fabric Deployment pipeline as you will need the deployment ID for the trigger_deployment_pipeline script
- The post-deployment notebook can be found at the following location. Ensure that this notebook exists in the workspace from which the execution will be run.
- You will need to create Azure Devops variables even if you can replace them with Azure Key Vault
- deployment_pipeline_id:The fabric deployment pipeline ID created (as for now, it is a manual action)
- dev_workspace_id: The DEV workspace ID
- dev_workspace_name: The DEV workspace name
- job_type_Notebook: The job type when triggering a post activity deployment
- post_deployment_notebook_id: The Notebook ID for the post activity deployment. In this case, it will be the id of the notebook Notebook_Post_Deployment
- uat_workspace_id: The UAT workspace ID
- uat_workspace_name: the UAT workspace name
Create workspaces manually Create workspace automatically
Create Fabric Deployment Pipeline
4 - Create the Azure Devops pipelines leveraging the Yaml files Apply_Changes_To_Branch.yaml and Deploy_Changes_From_Source_To_Target_Workspace.yaml
This approach will support only Fabric Items supported by the deployment pipeline .
Some fabric items require post deployment activities after the deployment pipeline has run.
For more information about what the current post activity is able to support please visit this page
Fabric Deployment Pipeline with swap connection demo: You can watch a quick recording here