Power BI deployment pipelines - reassign workspace

[Anonymous]

Hi Guys Just wondering if it is possible to reassign a workspace back into a deployment pipeline? I have a situation where the production workspace was unassigned accidentally, and I need to put it back into the last step of the deployment. Is this possible? if not, what options do I have? (manually deploy to prod, then backwards deploy and create new workspaces?) Thanks Ken

[v-xicai · Accepted solution]

Hi @Anonymous ,

In your scenario, you may click button "Deploy to production" , the deployment process creates a duplicate workspace in the target stage "Production". This workspace includes all the content existing in the current stage. So it is unnecessary to create another workspace for the Production stage.

For reference:

Get started with deployment pipelines (preview)

Best Regards,

Amy 

Community Support Team _ Amy

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[Nimrod_Shalit]

@dbeavon3,

Once you have access to the pipeline you can unassign them from the pipeline. It was there from day 1.

if you don't have access, it means that there's another admin to the WS who assigned them and can help you get access, or unassign it for you. if that person is not in the organizations anymore, there are Power BI Admin APis that can help you solve the problem.

[dbeavon3]

@Nimrod_Shalit Thanks for the reply

>> Once you have access to the pipeline you can ...

This still doesn't make sense.  No admin of a workspace should have lesser rights than another admin of a workspace.  If an admin has the right to create a pipeline, then an admin should have the right to detach the pipeline.  In the college class I'm taking (Power BI C-o-E ), this is relationship is known as the transitive property of PBI workspace administration.

Let me put it another way.  If the Power BI software is being used for mission critical purposes, it shouldn't be necessary for one admin to try to contact another admin to fix a given problem.  All the admins should have equal rights, and shouldn't be tied to an individual person's account.  (As you may know, people can get sick or go on vacation or whatever, and may become unavailable.  It is very silly if it is possible for a single admin to tie up a workspace, when they become unavailable.)

>>  if that person is not in the organizations anymore, there are Power BI Admin APis that can help you solve the problem.

I'm assuming the API is going to allow an authenticated workspace admin to detach a pipeline?  If so, I think this is probably the thing that I was missing.  Usually a programming API must be built in a way that makes more sense (more than the U/I).  Typically it is necessary to put more thought and effort into the creation of a cohesive API.  Also your target audience is probably another developer, who is likely to be a lot more demanding than the unfortunate users of your PBI web portal.

[p13tro]

I have accidentially unassigned a production workspace from a pipeline. This workspace had various permissions for different reports. I now have to allow the pipeline to recreate another production workspace and then input all the permissions in again! Not impressed.

[Nimrod_Shalit · Accepted solution]

Another option to consider,

in case Production WS is already used by many users and you don't want to reconfigure it,

is to create a new WS and assign the production WS to the new pipeline, and create dev and test WSs again.

If you wish to keep existing pipeline as well, then unassign the dev+test WSs, which will make the pipeline without content again.

then you can re-assign the Prod WS, and re-create dev and test WSs.

[v-xicai · Accepted solution]

Hi @Anonymous ,

In your scenario, you may click button "Deploy to production" , the deployment process creates a duplicate workspace in the target stage "Production". This workspace includes all the content existing in the current stage. So it is unnecessary to create another workspace for the Production stage.

For reference:

Get started with deployment pipelines (preview)

Best Regards,

Amy 

Community Support Team _ Amy

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[Anonymous]

I'm sorry but this is not a solution. This is just a ridiculous setup pushed by MS.

I've been doing software development for a long time now. I cannot understand how some of the decision, especially around Power BI integrations, are shocking. Why would a pipeline create a Workspace? And how can disassociating a Workspace from a pipeline stage forces the creation of a new Workspace? Is this in any universe a good design? Is MS aware that in an enterprise environment things are segregate and a developer cannot associate a Workspace with a premium capacity just like that? Once you cannot reassociate a Workspace with a pipeline the amount of work pushed on developers is unbelievable. I am sorry but this thing was not thought out or designed at all.

[Nimrod_Shalit]

@Anonymous,

Thank you for your honest feedback.

I'll try and be as honest as well- you are right. having the limitation of assigning only 1 workspace into a pipeline and not 3 workspaces to all stages, is an existing limitation that we don't like as well.

However, building this functionality required a lot of additional work that would have taken us long time to deliver, and delay the release of deployment pipelines. A reminder, pipelines are available for less than 6 months, relatively young feature in Power BI. As such, is still missing many important functionalities that many customers regard as 'critical'. If we had to build all of them before releasing pipelines, we would have a great full feature, that would have been available to customers within 2 years from now.

Instead, we decided to deliver a minimal valuable product that users can use, with its limitations, and we continously work to improve and add functionality.

The ability to assign WSs to all 3 stages is one of them, and we expect to deliver it during CY21.

Until then, you can decide not to use deployment pipelines and wait for this feature to be available.

[Anonymous]

This will sound stubborn, critiqueing a product without deep understanding of it, and basically doing arm chair design review.

Thanks for taking the time to answer and continue the conversation.

I can always accept that getting something in production, reducing the batch size, and having smooth flow of functionality into production is a fundamental piece of agility and of increasing delivered value.

This is not an excuse to create the wrong feature and on top put it into production with clear limitations.

I say wrong product because I do not understand how these pipelines are supporting automation efforts. On top this feature is not inline with the general improvements that a devops mentality have brought us in the past years. There is no really good reason to reinvent the wheel of CI/CD, of promoting an artifact throught different stages.

Now we are stuck with a new way of doing environment promotions, while still not supporting fundamental requirements for automation.

Instead of building such a system it would have been nice to provide concrete support for collaboration and versioning of the PBIX instead of creating more on top of the disastrous idea of having a single binary file as the artifact of PBI. It would have been nice to have clear separation of models and reports instead of documenting splitting the binary PBIX file into two. It just validates that it was a wrong decision to have data and reporting together in the same binary file.

Now we are stuck with "versioning via OneDrive" because with that we "will not get conflicts". Unless when one does get conflicts that cannot be solved.

I would strongly suggest reconsidering the path you started on.

If you cannot split the PBIX file, add some build step that separates the model into a bim file and the report into some other file (this won't make collaboration possible though). This separation would allow deployment of bim files with Invoke-AsCmd, a tool that seems to work and from an Azure DevOps Pipeline we would be able to deploy to whatever workspaces we want.

For the reporting side, you will have to come up with a different, non binary, file format and provide a similar system.

You started on the wrong path and you need to accept it and take the time to fix it. Otherwise you are steaming ahead while the rest of use we'll look at alternatives.

Again, I do appreciate you answering my points. I hope you will be able to ignore the frustration in my message. If not at least understand that it comes from trying to industrialize and create a professional process for PBI development and not seeing a path forward.

[Nimrod_Shalit]

Few more points i would like to raise:

1. We are planning on automating deployment pipelines, so that you can use familiar tools such as Azure Pipelines. in fact, we are working on this right now. 
2. I agree that open file format would have been ideal and open up much more options for a full CI/CD release process, but this is a very (very very) large project that we hope to accomplish some day. until then, you can get some ideas and best practices on how to manage content in this detailed blog post.
3. Having all that said, one should remember that Power BI is also a low-code/no-code analytics platform, and part of the Power Platform, which is targeted for low-code/no-code developers. As such, we see great importance to provide ALL types of developers the tools that will help them achieve more. In our case, its about enabling ANY BI creator or BI team to deliver content updates faster and in higher quality, even if they don't have the needed technical skills. DevOps methods should be a common practice that all can benefit from, and this is what we are trying to do with Power BI deployment pipelines.

[dbeavon3]

@Nimrod_Shalit Would be nice to get some improvements to pipelines; they are still extremely troublesome.

>> You said "can get some ideas and best practices on how to manage content".

Whenever I hear a product team pushing their "best practices" this much, it is because their product is unintuitive, inflexible, and extremely limited in its features.  It reminds me of the Apple iPhone 4 which has reception problems, and the company said that the "best practice" was to not hold the phone in a certain way.

>> You said "targeted for low-code/no-code developers"

That sounds like you are setting a very low bar for your work.  You are a developer.  In the very, very least you should build a product that you wouldn't mind using yourself.  These pipelines are pretty hard to use, even by Power BI standards.

At the moment I have pipelines that are tying up my workspaces.  I'm an admin in all of them, and have no way to detach the things.  How does this make any sense?