Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Grow your Fabric skills and prepare for the DP-600 certification exam by completing the latest Microsoft Fabric challenge.

Reply
DennesTorres
Impactful Individual
Impactful Individual

Lakehouses in deployment pipelines

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:

 

DennesTorres_0-1702493868416.png

 

 

If I click Deploy, will this work, or will this destroy the lakehouse in TEST in some way ?

Kind Regards,

 

Dennes

2 ACCEPTED SOLUTIONS

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.

View solution in original post

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.

DennesTorres_0-1702995667194.png


Kind Regards,

 

Dennes

 

View solution in original post

6 REPLIES 6
v-nikhilan-msft
Community Support
Community Support

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.


DennesTorres_0-1702559718242.png

 

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.

DennesTorres_0-1702995667194.png


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

Helpful resources

Announcements
Europe Fabric Conference

Europe’s largest Microsoft Fabric Community Conference

Join the community in Stockholm for expert Microsoft Fabric learning including a very exciting keynote from Arun Ulag, Corporate Vice President, Azure Data.

Expanding the Synapse Forums

New forum boards available in Synapse

Ask questions in Data Engineering, Data Science, Data Warehouse and General Discussion.

RTI Forums Carousel3

New forum boards available in Real-Time Intelligence.

Ask questions in Eventhouse and KQL, Eventstream, and Reflex.

MayFBCUpdateCarousel

Fabric Monthly Update - May 2024

Check out the May 2024 Fabric update to learn about new features.