Microsoft Fabric Community Conference 2025, March 31 - April 2, Las Vegas, Nevada. Use code MSCUST for a $150 discount.
Register nowGet certified as a Fabric Data Engineer: Check your eligibility for a 50% exam voucher offer and join us for free live learning sessions to get prepared for Exam DP-700. Get started
Hi,
I don't really mind about the lakehouses themselves (the content is diffferent on every environment), but they are in a workspace together notebooks and semantic models. I need to pass the notebook and semantic models from DEV to TEST using deployment pipelines.
My most recent discovery is that even if the name of the lakehouse is absolutely the same in both stages, DEV and TEST, the comparison made by the deployment pipeline still considers it as different objects. I'm concerned about what kind of destruction will happen if I click the Deploy button.
The image illustrating what I'm talking about:
If I click Deploy, will this work, or will this destroy the lakehouse in TEST in some way ?
Kind Regards,
Dennes
Solved! Go to Solution.
Hi @DennesTorres
Deployment pipelines binds two items (it they are of the same item type and have the same name) only on events of first deployment (which creates the adjacent stage's workspace) or during workspace assignment to one of those stages. I assume one/both Lakehouses were added after Dev and Test stages were already existing with workspaces assigned to them, and so the binding process was not implemented for those Lakehouses so they are not bind and therefore Deployment pipeline's compare presents it this way.
In case you'll deploy the lakehouse on DEV, the deployment will fail since deployment pipeline will recognize this item is not bind to any item on the target stage (Test), will try to create a new one there, but then it will recognize there is already Lakehouse there with this name so the process will be aborted with Failure message.
The way to workaround it, as I understand the existing items are (and should be) different items, is to change the name of one of them and then deploy.
Hope this helps. Please let us know if you have any further questions.
Hi,
"I assume one/both Lakehouses were added after Dev and Test stages were already existing with workspaces assigned to them, and so the binding process was not implemented for those Lakehouses so they are not bind and therefore Deployment pipeline's compare presents it this way."
I'm absolutely sure this didn't happen. I created the deployment pipeline when the lakehouses were already created.
However, the theory makes sense. So, I end up making some tests and... bingo! Once I unassigned and assigned again both environments (dev and test), it worked. The lakehouses weren't being pointed as different objects anymore.
My guess: There was a bug, but Microsoft fixed the bug on the assignment process. So, once I unassigned and assigned the workspaces again, the problem was solved.
"The way to workaround it, as I understand the existing items are (and should be) different items, is to change the name of one of them and then deploy."
I believe it would be worse. If I change the name, they would be recognized as new objects, and I could end up with multiple lakehouses in the same workspace.
But luckly, it doesn't mind anymore. I believe it was a bug fix, but probably we will never have a confirmation of this.
The image below shows the lakehouses being identified as the same, no difference anymore.
Kind Regards,
Dennes
Hi @DennesTorres
Thanks for using Fabric Community.
In the above picture are the both lakehouses the same? Are you trying to deploy the pipeline between two same lakehouses? Do they belong to the same workspace or different ones?
Hi,
I end up clicking deploy to discover what would happen.
I got an error. The deployment don't start and the error message makes sense: It say the items with the same name are not linked to each other, so the deployment was not possible.
The checkbox to continue the deployment in case of failure was checked, however, it was not enough. It fails anyway.
Kind Regards,
Dennes
Hi @DennesTorres
This looks like a bug. Can you please create a support ticket and give me the ticket number, so that I can escalate to the higher team?
Please create a support ticket here: https://support.fabric.microsoft.com/support
Provide the ticket number here as we can keep an eye on it.
Hi @DennesTorres
Deployment pipelines binds two items (it they are of the same item type and have the same name) only on events of first deployment (which creates the adjacent stage's workspace) or during workspace assignment to one of those stages. I assume one/both Lakehouses were added after Dev and Test stages were already existing with workspaces assigned to them, and so the binding process was not implemented for those Lakehouses so they are not bind and therefore Deployment pipeline's compare presents it this way.
In case you'll deploy the lakehouse on DEV, the deployment will fail since deployment pipeline will recognize this item is not bind to any item on the target stage (Test), will try to create a new one there, but then it will recognize there is already Lakehouse there with this name so the process will be aborted with Failure message.
The way to workaround it, as I understand the existing items are (and should be) different items, is to change the name of one of them and then deploy.
Hope this helps. Please let us know if you have any further questions.
Hi,
"I assume one/both Lakehouses were added after Dev and Test stages were already existing with workspaces assigned to them, and so the binding process was not implemented for those Lakehouses so they are not bind and therefore Deployment pipeline's compare presents it this way."
I'm absolutely sure this didn't happen. I created the deployment pipeline when the lakehouses were already created.
However, the theory makes sense. So, I end up making some tests and... bingo! Once I unassigned and assigned again both environments (dev and test), it worked. The lakehouses weren't being pointed as different objects anymore.
My guess: There was a bug, but Microsoft fixed the bug on the assignment process. So, once I unassigned and assigned the workspaces again, the problem was solved.
"The way to workaround it, as I understand the existing items are (and should be) different items, is to change the name of one of them and then deploy."
I believe it would be worse. If I change the name, they would be recognized as new objects, and I could end up with multiple lakehouses in the same workspace.
But luckly, it doesn't mind anymore. I believe it was a bug fix, but probably we will never have a confirmation of this.
The image below shows the lakehouses being identified as the same, no difference anymore.
Kind Regards,
Dennes
Hi,
They are two lakehouses with the same name. One in Dev workspace and another in Test workspace.
The same as the notebooks: Each notebook is in Dev workspace and Test workspace, two notebooks with the same name, and the pipeline recognizes them as the same to make the update.
But not with the lakehouse. This is blocking me from make the deployment, I have no idea what will happen when I make the deploy.
Is this a bug? It seems so, because the deployment pipelines are intended to deploy across the environments, so they should recognize the lakehouse as the same and avoid any mess.... Am I missing something ?
Kind Regards,
Dennes
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Prices go up Feb. 11th.
User | Count |
---|---|
39 | |
7 | |
4 | |
3 | |
1 |
User | Count |
---|---|
56 | |
15 | |
11 | |
10 | |
8 |