Forum Discussion
Git Branch no syncing to new workspace
Hello LucasKramer, based on how you explain your goal to "set up a PR-based system" instead of making changes directly in the production workspace, below is my suggestion. A quick disclaimer: I won't be explaining the error messages you get, as the approach I suggestis different.
1. The workspace structure: you need a separate workspace for each of your environment: Dev, Test, Prod. Don't name them manually, come up with a uniformed naming convention, as in ws_solution1_dev, ws_solution1_test, etc.
2. Only connect the Dev workspace to a Git account and only to a main branch. Other workspaces should be deployed to from the same source of truth - that is a single main (or other name) branch in Git. Make sure that your main branch is protected from direct pushes and can only be updated via a PR merge.3. To implement PR-based process, all changes must be made in a Feature-specific workspace, not in any of the environment workspaces. You need to enforce a discipline and not allow your developers/engineers make direct changes in any of the shared environment workspaces (permissions).
4. In practice, this means the following Development Life Cycle (DLC):
Git main -> Dev workspace -> Feature workspace -> merge into main -> update Dev workspace.
5. In addition, you need a Release Cycle:
Dev workspace -> deployment -> Test workspace -> deployment -> Prod workspace.6. You have two way of implementing DLC:
Manual:a. branch out from Dev workspace into a Feature workspace that will create a new branch from main and connect to a Feature workspace.
b. Finish development and testing in Feature workspace, then merge feature branch into main branch via PR and update your Dev workspace voa Git integration from main. Run tests in the Dev workspace.
c. Use development pipeline and deploy to Test workspace from Dev workspace; run tests.
d. Deploy from Test workspace to Prod.
Automated:
Replace a) from the manual process with a Git automation that creates a new branch from main, creates a new Feature workspace in Fabric using API, populates Feature workspace from Feature Git branch. Then continue as above.
This is a proven approach but here I can only explain so much. So this is a sketch and there are always nuances in every organization. But I hope you get an idea. The errors you mentioned above are results of how you make and synchronize changes between Fabric and Git: it can get very messy, so instead of fighting those errors, use a clean straightforward one-way sync as I suggested above that will avoid such errors.
If you find this helpful consider giving kudos and mark as a solution.
Olá, boa tarde!
Parece mais uma limitação/conflito do Fabric Git Integration no branch out do que um problema do repositório em si.
Pelos sintomas que você descreveu, eu investigaria principalmente três pontos:
- conflito de logicalId ou de display name + type durante o Update from Git;
- conflito em itens que criam SQL analytics endpoint automaticamente, como lakehouses/warehouses;
- artefatos que usam workspace identity, porque a Microsoft informa que esses itens só atualizam corretamente para um workspace conectado à mesma identity, e isso também afeta branch out.
O fato de o novo workspace ficar com vários itens em estado parcialmente sincronizado também bate com o comportamento documentado de falha parcial no Update from Git: alguns itens entram, um falha, e o workspace fica preso nesse estado até a inconsistência ser resolvida.
O que eu testaria na prática:
- criar um workspace novo e totalmente vazio para o branch;
- usar branch-out seletivo com poucos itens para identificar qual item dispara a falha;
- revisar se existe item duplicado por nome/tipo ou conflito de logicalId;
- verificar especialmente lakehouses/warehouses e seus SQL endpoints;
- se houver uso de workspace identity, recriar/configurar isso manualmente no workspace de destino em vez de confiar só no sync;
- considerar dividir esse workspace em partes menores, porque a própria Microsoft recomenda isso quando há centenas de itens.
Se o objetivo final é promover mudanças com mais segurança, eu tenderia a usar workspaces isolados por dev/feature branch e deployment pipelines para dev/test/prod, em vez de depender do workspace de produção como base do fluxo.