Git integráció a Fabric raktárfejlesztéshez

A következőre vonatkozik: ✅ Warehouse a Microsoft Fabricben

Ez a cikk bemutatja az Fabric Data Warehouse fejlesztésének és bevezetésének előnyeit Fabric beépített Git integrációjával.

Important

Ez a funkció előzetes verzióban érhető el.

A Git integráció alkalmazásával a Fabric-ben a csapatok modern forráskódkezelő gyakorlatokat alkalmazhatnak raktárfejlesztésben. A fejlesztők izolálhatják az ágazások változásait, követhetik a séma fejlődését a commit-ek segítségével, együttműködhetnek pull-requestek révén, és szinkronizálhatják a frissítéseket a Git tárolók és a Fabric munkaterületek között.

A tipikus forgatókönyvek a következők:

  • Sémaváltozások biztonságos fejlesztése ágakban és munkaterületeken
  • Raktári objektumok verzióztatása a Git-ben
  • Együttműködés több ágon és munkaterületen keresztül
  • Támogatott változtatások előmozdítása az ágazatok között
  • A munkaterületi elemek (raktár és mások) összhangban tartása a Git igazságforrásával

A raktárfejlesztési életciklusok során fenntartva következetesség, nyomon követhetőség és megbízhatóság érdekében meg kell értened ezeket a munkafolyamatokat.

A Fabric Warehouse Git integrációs fejlesztési életciklusának ábra.

Amikor egy Fabric Data Warehouse munkaterületet csatlakoztatsz a Git-hez, a raktárdefiníciókat adatbázis-projektként kötelezed fel. Ez a projekt a raktár sémájának hiteles reprezentációja a forrásvezérlésben, és alapját képezi a folyamatos fejlesztési tevékenységeknek. A forrásvezérlő explorerben a séma egyedi .sql fájlként jelenik meg.

Képernyőkép egy raktár sémájáról a forrásvezérlő explorerben.

Fabric Git Integration and Fabric Data Warehouse használatával:

Comparison

A szinkronizációs folyamat során a Fabric DacFx-alapú inkrementális séma telepítést alkalmaz a változtatások alkalmazására. Ez a megközelítés csak a releváns sémakülönbségeket alkalmazza a raktárra, nem pedig frissítené az egész raktárdefiníciót.

A fokozatos kivonás segít csökkenteni a forrásvezérlés felesleges felesleges felvonulását, tisztább sémakülönbségeket fenntartani az ágak között, és támogatja a hatékony elágazási és összevonási munkafolyamatokat. Mivel a kinyerési folyamat séma-ismeretes, lehetővé teszi a munkaterület állapota és a Git-követésű definíciók megbízható összehasonlítását és validálását is.

A raktári sémák kinyerésének és tárolásának szabványosítása javítja a fejlesztési környezetek közötti konzisztenciát. A sémadefiníciók az ágazatokon belül stabilak maradnak, a különbségek pontosabban tükrözik a szándékos fejlesztési változásokat, és a forráskód kezelése megbízható alapvonal lesz a telepítéshez, az együttműködéshez és az életciklus-kezeléshez.

A XMLA.json fájl maga a Git integrációs munkafolyamatok során ki van zárva. A Fabric kizárja ezt a fájlt a commit-ek és frissítések közül, így az alapértelmezett szemantikai model metaadatok ne legyenek véletlenül tárolva a Git-ben. A Git-ből XMLA.json szinkronizációkor figyelmen kívül hagyják a munkaterületet, ami segít elkerülni az ütközéseket, a nem szándékos felülírásokat és a zajt az ágváltás vagy a Git frissítései során.

A forrásvezérlés korlátozásai

Az SQL biztonsági funkciók, mint például a jogosultságok, külön exportálási és migrációs megközelítést igényelnek.

  • A raktárak és SQL analitikai végpontok közötti cross-item függőségek jelenleg nem támogatottak a fejlesztési munkafolyamatokban. Ennek eredményeként azok a forgatókönyvek, amelyek összehangolt változásokra épülnek ezekben a elemekben, nem feltétlenül működnek megbízhatóan.

  • A raktári szintű szelektív commit-ek jelenleg nem támogatottak. A változtatásokat a raktártárgy szintjén kötik el, nem pedig részletesebb tárgyszinteken.

  • Az SQL analitikai végpontok verzióvezérlési támogatása jelenleg nem elérhető. Ez a korlátozás korlátozhatja az életciklus végpontig terjedő kezelését, amikor a megoldások mind raktárak, mind SQL analitikai végpontokon terjednek.

A Git-integráció korlátai

  • Ha két vagy több raktári tárgy hivatkozik egymásra, ciklikus függőséget képeznek. A rendszer ezt a körkörös hivatkozást észleli a fiók-out vagy Git-to-workspace szinkronizálási műveletek során, ami miatt ezek a műveletek sikertelenül működnek. Kerüld el a ciklikus függőségeket az elemek között.
  • Jelenleg ne hozzon létre adatfolyam Gen2-t a raktár kimeneti célhelyével. Megjelenik egy új DataflowsStagingWarehouse elem a repozitóriumban, és akadályozza meg a Git-beli véglegesítést és frissítést.
  • Az SQL Analytics-végpont és a raktár közötti elemek közötti függőségek, elemek szekvenálása és szinkronizálási hiányosságai hatással vannak az "új vagy meglévő munkaterületre való elágaztatásra" és a "váltás másik ágra" munkafolyamatokra a fejlesztés és a folyamatos integráció során.
  • Ha egy objektum ugyanabban a raktárban lévő másik objektumra hivatkozik háromrészes elnevezéssel (database.schema.object), a Git-ből történő kötelezés vagy frissítés meghibásodott. További információért és egy megoldásért lásd: Hivatkozások a raktár saját objektumaira háromrészes név használatával.
  • Ha megváltoztatsz egy olyan oszlopot, amely már IDENTITY definiált, a Git-ből történő commitálás vagy frissítés nem hibás, amíg IDENTITY_INSERT a tábla nem engedélyezi.
  • Ha a tárolóban van egy .sqlproj fájl, amely egy régebbi Microsoft.Build.Sql SDK verziót rögzít, a Git-ről történő comcomingolás vagy frissítés meghibásítható, mert a régebbi SDK nem ismeri fel az újabb raktárszintaxisokat, például IDENTITY oszlopokat és CLUSTER BY. További információért és egy megoldásért lásd: E-of-date .sqlproj a Git repozóriumban.
  • Ha egy objektum két vagy több táblára hivatkozik egy másik raktárban anélkül, hogy minden oszlopot alias-minősítsen, akkor a Git-ből történő kötelezés vagy frissítés meghibásodott. További információért és egy megoldásért lásd: Kvalifikáció nélküli oszlopok objektumokban, amelyek két vagy több táblára hivatkoznak egy másik raktárban.
  • Ha a szkriptek két vagy több különböző objektumra hivatkoznak ugyanabban a sémában egy másik raktárban, és a séma nevét következetlen nagybetűvel írják, akkor a Git-ből történő comcomingolás vagy frissítés meghibásodott. További információért és egy megoldásért lásd: A séma nevek inconsistent nagybetűs írása.
  • Kétértelmű oszlophibák, amelyek jelöltlistáján van elválasztó :: , előfordulhatnak a Git-ről történő kötelezés vagy frissítés során, még akkor is, ha valódi kétértelműség nincs. További információért és megoldásokért lásd: Kétértelmű oszlophibák duplikált jelölt objektumokkal.

Nem támogatott forgatókönyvek

A következő CI/CD-munkafolyamatok hivatalosan nem támogatottak, ha a különböző munkaterületeken lévő raktárak eltérő összeállításokkal rendelkeznek. Annak ellenére, hogy ezek a műveletek hibák nélkül is sikeresek lehetnek, metaadat-hibákat eredményezhetnek.

Az összes ilyen esetben, ha rendezési eltérés történik, használja a Python szkriptet scripts/dw-collation-error-update-tmsl/pbi_interactive.py a Fabric eszközkészletben a GitHub adattárban az adathalmaz (TMSL) rendezésének frissítéséhez, hogy megfeleljen a raktári rendezésnek.

Scenario Description Kockázat
Telepítési csővezetékek Nem támogatott a raktártartalom előmozdítása folyamatszakaszokon keresztül (például Dev → Test → Prod), ahol a célraktár más rendezéssel lett létrehozva, mint a forrás. Az üzembe helyezés sikeres lehet, de az adathalmaz-rendezés nem frissül a célraktár-rendezésnek megfelelően.
Ágazás egy új vagy meglévő munkaterületre A Git-integráció használata egy meglévő munkaterületről egy új vagy meglévő munkaterületre való elágaztatáshoz, ahol a raktár más rendezéssel rendelkezik, nem támogatott. A rendszer szinkronizálja a raktár tartalmát, de a rendezési metaadatok nincsenek egyeztetve.
Ágak váltása munkaterületen A Githez csatlakoztatott munkaterületen nem támogatott egy másik rendezésű raktárhoz társított ágra váltás. A szinkronizált tartalom olyan rendezési feltételezéseket tartalmazhat, amelyek nem felelnek meg az aktuális raktárnak.
Módosítások egyesítése a munkaterületek között ágakon keresztül A Git-ágak egyesítése olyan munkaterületeken, ahol a raktárak különböző rendezésekkel rendelkeznek, nem támogatott. Az egyesítés a Git szintjén sikeres lehet, de az eredményül kapott adathalmaz-rendezés nem tükrözi a célraktár rendezését.

Következő lépés

Használd a Git Integrációt raktárfejlesztéshez és telepítéshez

Kapcsolódó tartalom

  • Last updated on