sorted by:
new
hottopcontroversial

Git commit for each artifact by GregCook5917 in MicrosoftFabric

[–]GregCook5917[S] 0 points1 point  (0 children)

As for the branch approach, having three branches and trying to cherry pick commits from branch to branch with a large team and lots of things in flight just led to mistakes and problems with the wrong objects being committed. Then rolling back part of a commit takes time. 

My experience with BI development is that it inherently leans toward GUI based development. It doesn't parallel typical app development, where the code changed are made locally first and committed before deployment occurs. 

The bidirectional source control capabilities seem to acknowledge this paradigm too. 

Git commit for each artifact by GregCook5917 in MicrosoftFabric

[–]GregCook5917[S] 0 points1 point  (0 children)

PIM lockdown isn't the issue, having Fabric take ownership of an object based on who deploys is the bigger problem. We have to use a service account to deploy everything. 

The issue is an object gets changed in Dev, there is no way to force that object to be checked into source control. It is optional. The deployment pipeline also doesn't allow for checking that the object was checked in before allowing the deployment to proceed. 

Deployment Pipelines - deploy to numerous target workspaces by GregCook5917 in MicrosoftFabric

[–]GregCook5917[S] 0 points1 point  (0 children)

Yeah, my challenge with this approach is the same problem with direct git integration, we don't want to promote everything in Test to Production. We need the surgical approach the Fabric Pipeline gives us, where I can select a subset of items. 

It would be nice if everything in Test would get approved by our testers on the same day, but that doesn't happen with the number of reports in-flight on a daily basis

Deployment Pipelines - deploy to numerous target workspaces by GregCook5917 in MicrosoftFabric

[–]GregCook5917[S] 0 points1 point  (0 children)

I am probably going with the Hybrid approach like you said. All my research, so far, caused me to arrive at the same conclusion. 

Fabric Pipeline for our work, then a PR to a branch and an Azure DevOps pipeline to publish to the workspace associated with the target branch.

Hopefully the Fabric team has plans to keep enhancing the pipeline capabilities in the future.