Forum Discussion
Resolver Ihow to manage reporting lifecycle and avoid cross-workspace sourcing
Hello mr_wizard
have you tried deployment pipelines
Deployment Pipelines allow you to manage content across Development, Test, and Production environments systematically. With deployment pipelines:
• Semantic models and reports can be deployed together across stages.
• Thin reports (live-connected to datasets) will automatically connect to the appropriate dataset as they move through pipeline stages, ensuring consistency without cross-workspace sourcing
Super UserHello mr_wizard
have you tried deployment pipelines
Deployment Pipelines allow you to manage content across Development, Test, and Production environments systematically. With deployment pipelines:
• Semantic models and reports can be deployed together across stages.
• Thin reports (live-connected to datasets) will automatically connect to the appropriate dataset as they move through pipeline stages, ensuring consistency without cross-workspace sourcing
Resolver IYes. However, I don't understand how deployment pipelines resolve the problem. Both the semantic models and the reports need to follow a lifecycle (Development, Test, Production). As a thin report moves through each stage (workspace) of the lifecycle, to not encounter cross-workspace sourcing, its semantic model needs to be "local" (i.e., in the same workspace as the report). But, because of our rule that we always point downstream layers to the Production "environment" of previous layers, that forces the semantic model in each stage (workspace) of the report layer to be the Production version. Whether we deploy manually or in a pseudo-automated way (with deployment pipelines), I don't see any way to avoid cross-workspace sourcing, unless we do something like deploy the Production version of each semantic model four times (first to the Production workspace of the semantic model, then again to the Development workspace of the report, then again to the Test workspace of the report, and lastly to the Production workspace of the report). What am I missing?
- Tutu_in_YYC
It sounds like you do not have lifecycle for semantic model, only for report, since all dev/test/prod report will be connecting to the final version of the semantic model.
In this case, as you mentioned, you may have to have the same final version of the semantic model in 3 different workspace within the pipeline. You can still use the deployment pipeline to manage the lifecycle of the report, ie only deploy report through dev > test > prod. The semantic model remain static. As the report is being deployed, it will automatically rebind to the next semantic model in the next environment.
If any changes is made to the semantic model, it has to be published separately to all 3 workspaces dev/test/prod ; or published the final version to dev, and deploy to test and prod right away.
This way you still have 3 versions of report, and same semantic model in all environment with no cross-workspace- Tutu_in_YYC
If you use deployment pipeline, you will be able to have a proper promotion management, with tracking, ie who did it, when and even add notes of the additional features have been added to the prod version. And also you will be able to do some comparisons between versions of different environment.
If all above is not needed, you can just work in 1 workspace, create folders for the different "environments". Not a proper solution, but it works.. You will always publish into the same workspace for "dev/prod/test"- mr_wizard
We definitely need (and use) deployment pipelines for both the semantic models and the reports (for many of the reasons that you listed). In order to enforce the no-cross-workspace-sourcing rule while also enforcing the rule that every report in every stage point to Production, I think it's unavoidable to have 6 workspaces and 2 deployment pipelines: 3 workspaces and 1 pipeline for the semantic model lifecycle, and another 3 workspaces and 1 pipeline for the report lifecycle (where the "semantic model" pipeline deploys to the 3 "report" workspaces after it deploys into the Production "semantic model" workspace).
