Integrace Gitu pro vývoj v Fabric warehouse

Platí pro: ✅ Warehouse v Microsoft Fabric

Tento článek vysvětluje výhody vývoje a nasazení Fabric Data Warehouse s vestavěnou integrací Git Fabric.

Important

Tato funkce je ve verzi Preview.

Použitím integrace Git ve Fabric mohou týmy aplikovat moderní postupy správy zdrojových kódů při vývoji ve skladech. Vývojáři mohou izolovat změny v větvích, sledovat vývoj schématu pomocí commitů, spolupracovat prostřednictvím pull requestů a synchronizovat aktualizace mezi Git repozitáři a Fabric workspaces.

Mezi obvyklé scénáře patří:

  • Bezpečné vyvíjení změn schémat v větvích a pracovních prostorech
  • Verze objektů skladu v Gitu
  • Spolupráce napříč více pobočkami a pracovními prostory
  • Podpora validovaných změn mezi větvemi
  • Udržování položek v pracovním prostoru (sklad a další) v souladu se zdrojem pravdy v Gitu

Pro udržení konzistence, sledovatelnosti a spolehlivosti napříč životními cykly vývoje skladu je nutné tyto pracovní postupy pochopit.

Diagram vývojového cyklu vývoje integrace Git v Fabric Warehouse.

Když připojíte Fabric Data Warehouse pracovní prostor k Gitu, commitujete definice skladu jako databázový projekt. Tento projekt se stává autoritativním vyjádřením skladového schématu ve zdrojovém řízení a slouží jako základ pro pokračující vývojové aktivity. V průzkumníku správy zdrojového kódu se schéma zobrazuje jako jednotlivé .sql soubory.

Screenshot schématu skladu v průzkumníku správy zdrojů.

Použitím Fabric Git Integration a Fabric Data Warehouse můžete:

Porovnání

Během tohoto synchronizačního procesu Fabric používá inkrementální nasazování schématu založeného na DacFx k aplikaci změn. Tento přístup aplikuje pouze relevantní rozdíly ve schématu na sklad, místo aby aktualizoval celou definici skladu.

Inkrementální extrakce pomáhá snižovat zbytečnou fluktuaci ve zdrojovém řízení, udržovat čistší rozdíly ve schématech napříč větvemi a podporovat efektivní větvení a slučování pracovních postupů. Protože proces extrakce je schema-aware (schéma-aware), umožňuje také spolehlivé porovnání a validaci mezi stavem pracovního prostoru a Git-trackovanými definicemi.

Standardizace způsobu extrakce a ukládání skladových schémat zlepšuje konzistenci napříč vývojovými prostředími. Definice schémat zůstávají stabilní napříč větvemi, rozdíly přesněji odrážejí záměrné vývojové změny a správa zdrojových kódů se stává spolehlivým základem pro nasazení, spolupráci a řízení životního cyklu.

Soubor XMLA.json sám je během integračních pracovních postupů Git vyloučen. Fabric tento soubor vylučuje z commitů a aktualizací, takže výchozí sémantická model metadata nejsou nechtěně uložena v Gitu. Při synchronizaci pracovního prostoru z Gitu je ignorován, XMLA.json což pomáhá předcházet konfliktům, nechtěným přepsáním a šumu při přepínání větví nebo aktualizacích z Gitu.

Omezení správy zdrojového kódu

SQL bezpečnostní prvky, jako jsou oprávnění, vyžadují samostatný přístup k exportu a migraci.

  • Závislosti napříč položkami mezi sklady a SQL analytickými endpointy nejsou v současnosti ve vývojových pracovních postupech podporovány. V důsledku toho scénáře, které závisí na koordinovaných změnách těchto položek, nemusí spolehlivě fungovat.

  • Selektivní commity na úrovni skladu momentálně nejsou podporovány. Změny se provádějí na úrovni skladových položek, nikoli na jemnějších, detailních úrovních objektů.

  • Podpora správy verzí pro SQL analytické endpointy momentálně není dostupná. Toto omezení může omezit správu životního cyklu od začátku do konce, pokud řešení pokrývají jak sklady, tak SQL analytické koncové body.

Omezení integrace Gitu

  • Když se dvě nebo více skladových položek na sebe odkazují, tvoří cyklickou závislost. Systém detekuje tuto kruhovou referenci během synchronizačních operací typu branch-out nebo Git-to-workspace, což způsobuje jejich selhání. Vyhněte se cyklickým závislostem mezi položkami.
  • V současné době nevytvořte tok dat Gen2 s výstupním cílem do skladu. V úložišti se zobrazí nová položka s názvem DataflowsStagingWarehouse a zablokuje potvrzení a aktualizaci z Gitu.
  • Závislosti mezi položkami, pořadí položek a mezery synchronizace mezi koncovým bodem sql Analytics a skladem ovlivňují "větvení do nového nebo existujícího pracovního prostoru" a "přepnutí na jinou větev" během vývoje a průběžné integrace.
  • Pokud objekt odkazuje na jiný objekt ve stejném skladu pomocí třífázového pojmenovávání (),database.schema.object může být potvrzení nebo aktualizace z Gitu neúspěšná. Pro více informací a řešení viz Odkazy na objekty skladu pomocí třídílného názvu.
  • Pokud změníte sloupec, který je IDENTITY definován, commitování nebo aktualizace z Gitu může selhat, dokud IDENTITY_INSERT není pro tabulku povolena.
  • Pokud repozitář obsahuje soubor, .sqlproj který připíná starší Microsoft.Build.Sql verzi SDK, může commitování nebo aktualizace z Gitu selhat, protože starší SDK nerozpoznává novější skladovou syntaxi, jako IDENTITY jsou sloupce a CLUSTER BY. Pro více informací a řešení viz Out-of-date .sqlproj v Git repozitáři.
  • Pokud objekt odkazuje na dvě nebo více tabulek v jiném skladu bez alias-kvalifikace každého sloupce, může commit nebo aktualizace z Gitu selhat. Pro více informací a řešení viz Unqualified columns in objects (Nekvalifikované sloupce) v objektech, které odkazují na dvě nebo více tabulek v jiném skladu.
  • Pokud vaše skripty odkazují na dva nebo více různých objektů ve stejném schématu jiného skladu a název schématu píšou s nekonzistentním velkým písmenem, může commitování nebo aktualizace z Gitu selhat. Pro více informací a řešení viz Nekonzistentní velká písmena názvů schémat.
  • Nejasné chyby ve sloupcích, jejichž kandidátní seznam obsahuje oddělovač, :: se mohou objevit při commitování nebo aktualizaci z Gitu, i když není žádná skutečná nejednoznačnost. Pro více informací a obcházení viz Nejednoznačné chyby sloupců s duplicitními kandidátskými objekty.

Nepodporované scénáře

Následující pracovní postupy CI/CD nejsou oficiálně podporovány, pokud mají sklady v různých pracovních prostorech různé kolace. I když tyto operace můžou být úspěšné bez chyb, můžou vést k chybám metadat.

Ve všech těchto scénářích, pokud dojde k neshodě kolace, použijte skript Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py v úložišti GitHub Fabric toolbox k aktualizaci kolace datové sady (TMSL), aby odpovídala kolaci skladu.

Scenario Description Riziko
Nasazovací kanály Propagace obsahu skladu prostřednictvím fází potrubí (například Dev → Test → Prod), kde byl cílový sklad vytvořen s odlišným řazením než zdroj, není podporováno. Nasazení může proběhnout úspěšně, ale kolace datové sady se neaktualizuje tak, aby odpovídala kolaci cílového skladu.
Větvení do nového nebo existujícího pracovního prostoru Použití integrace Gitu k rozvětvení z existujícího pracovního prostoru do nového nebo existujícího pracovního prostoru, kde má sklad jinou kolaci, se nepodporuje. Obsah skladu se synchronizuje, ale metadata uspořádání dat nejsou sjednocována.
Přepínání větví v pracovním prostoru Přepnutí na větev přidruženou ke skladu jiné kolace v pracovním prostoru připojeném ke Git není podporováno. Synchronizovaný obsah může přenášet kolacační předpoklady, které neodpovídají aktuálnímu datovému skladu.
Sloučení změn mezi pracovními prostory prostřednictvím větví Sloučení větví Gitu mezi pracovními prostory, kde mají databázové sklady různé jazykové řazení, se nepodporuje. Sloučení může být úspěšné na úrovni Gitu, ale výsledné řazení datové sady neodráží řazení cílového skladu.

Další krok

Používejte Git Integration pro vývoj a nasazení skladu

Související obsah

  • Last updated on