Don't miss your chance to take the Fabric Data Engineer (DP-600) exam for FREE! Find out how by attending the DP-600 session on April 23rd (pacific time), live or on-demand.
Learn moreNext up in the FabCon + SQLCon recap series: The roadmap for Microsoft SQL and Maximizing Developer experiences in Fabric. All sessions are available on-demand after the live show. Register now
Hi everyone,
I’m deploying a Microsoft Fabric Warehouse from Dev to Prod using Azure DevOps BACPAC-based deployment and I've run into a behaviour I'd like to understand better.
As part of understanding how schema changes are handled, I tested the following scenario:
However, after the deployment:
This raised a few questions for me:
Any pointers or alternative approaches would be greatly appreciated!
Thanks in advance!
Solved! Go to Solution.
Hi @Aparnaa_MS ,
Thanks you reaching out to fabric community. Will happy to help with your issue. Here are the answers to your questions.
Question 1&2: Yes, this is expected behavior when using BACPAC deployment.
A BACPAC is essentially a snapshot of the database schema and data, and when you deploy/import it to the target (Prod), it focuses on:
However, it does NOT perform schema comparison and does NOT remove objects that exist in the target but are no longer present in the source (Dev). This is by design to avoid unintended data loss in the target environment.
Why your dropped table still exists in Prod:
Question 3: Here are the ways for the work around you can use for the deplyment.
How to handle deletions in CI/CD:
If you need Dev and Prod to stay fully in sync (including dropped objects), you should consider these approaches:
1. Use DACPAC (Recommended Solution)
You can enable:
2. Use Schema Compare / Deployment Scripts
3. Maintain Migration-Based Scripts
Hi @Aparnaa_MS ,
Thanks you reaching out to fabric community. Will happy to help with your issue. Here are the answers to your questions.
Question 1&2: Yes, this is expected behavior when using BACPAC deployment.
A BACPAC is essentially a snapshot of the database schema and data, and when you deploy/import it to the target (Prod), it focuses on:
However, it does NOT perform schema comparison and does NOT remove objects that exist in the target but are no longer present in the source (Dev). This is by design to avoid unintended data loss in the target environment.
Why your dropped table still exists in Prod:
Question 3: Here are the ways for the work around you can use for the deplyment.
How to handle deletions in CI/CD:
If you need Dev and Prod to stay fully in sync (including dropped objects), you should consider these approaches:
1. Use DACPAC (Recommended Solution)
You can enable:
2. Use Schema Compare / Deployment Scripts
3. Maintain Migration-Based Scripts
Experience the highlights from FabCon & SQLCon, available live and on-demand starting April 14th.
If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.
| User | Count |
|---|---|
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
| User | Count |
|---|---|
| 9 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |