Git-integraatio Fabric-varaston kehitykseen

Koskee:✅ Varasto Microsoft Fabricissa

Tässä artikkelissa selitetään, mitkä edut Fabric tietovarasto kehittämisestä ja käyttöönotosta Fabric:n sisäänrakennetun Git-integraation avulla.

Important

Tämä ominaisuus on esikatselutilassa.

Käyttämällä Git-integraatiota Fabric-ohjelmassa tiimit voivat soveltaa nykyaikaisia lähdekoodinhallintakäytäntöjä varastokehitykseen. Kehittäjät voivat eristää haaramuutoksia, seurata skeeman kehitystä committien avulla, tehdä yhteistyötä pull-pyyntöjen avulla ja synkronoida päivitykset Git-repositorioiden ja Fabric-työtilojen välillä.

Tyypillisiä skenaarioita ovat seuraavat:

  • Skeemamuutosten kehittäminen turvallisesti haaroissa ja työtiloissa
  • Varastoobjektien versiointi Gitissä
  • Yhteistyö useiden haarojen ja työtilojen välillä
  • Validoitujen muutosten edistäminen haarojen välillä
  • Työtilan esineiden (varasto ja muut) pitäminen linjassa Git-totuuden lähteen kanssa

Säilyttääksesi johdonmukaisuuden, jäljitettävyyden ja luotettavuuden varastokehityksen elinkaarien aikana, sinun täytyy ymmärtää nämä työnkulut.

Fabric Warehouse Git -integraation kehityksen elinkaaren kaavio.

Kun yhdistät Fabric tietovarasto-työtilan Gitiin, sitoudut varastomäärittelyihin tietokantaprojektina. Tämä projekti muodostaa varastoskeeman auktoritatiivisen edustuksen lähdekoodin hallinnassa ja toimii perustana jatkuville kehitystoimille. Lähdekoodin hallintaohjelmassa skeema näkyy yksittäisinä .sql tiedostoina.

Kuvakaappaus varaston skeemasta Source Control Explorerissa.

Käyttämällä Fabric Git Integration and Fabric tietovarasto voit:

Vertailu

Tämän synkronointiprosessin aikana Fabric käyttää DacFx-pohjaista inkrementaalista skeeman käyttöönottoa muutosten toteuttamiseen. Tämä lähestymistapa soveltaa varastoon vain olennaisia skeemaeroja, eikä koko varastomääritelmää päivitetä.

Inkrementaalinen poiminta auttaa vähentämään tarpeetonta häiriötä lähdekoodin hallinnassa, ylläpitää puhtaampia skeemaeroja haarojen välillä ja tukee tehokkaita haarautumis- ja yhdistämistyönkulkuja. Koska poimintaprosessi on skeematietoinen, se mahdollistaa myös luotettavan vertailun ja validoinnin työtilan tilan ja Git-seurattujen määritelmien välillä.

Varastoskeemojen poimimisen ja tallennuksen standardointi parantaa johdonmukaisuutta kehitysympäristöissä. Skeemamääritelmät pysyvät vakaina eri haaroilla, erot kuvaavat tarkemmin tarkoituksellisia kehitysmuutoksia, ja lähdekoodin hallinta toimii luotettavana lähtökohtana käyttöönoton, yhteistyön ja elinkaaren hallinnan kannalta.

Tiedosto XMLA.json itsessään suljetaan pois Git-integraatiotyönkuluista. Fabric sulkee tämän tiedoston pois commit-toiminnoista ja päivityksistä, jotta oletussemanttinen model metadata ei vahingossa tallennu Gitiin. Kun työtilaa synkronoidaan Gitistä, XMLA.json se jätetään huomiotta, mikä auttaa välttämään ristiriitoja, tahattomia ylikirjoituksia ja kohinaa haaravaihdon tai Gitin päivitysten aikana.

Lähteen hallinnan rajoitukset

SQL:n turvallisuusominaisuudet , kuten käyttöoikeudet, vaativat erillisen vienti- ja migraatiotavan.

  • Varastojen ja SQL-analytiikan päätepisteiden välinen ristiinkohtainen riippuvuus ei tällä hetkellä ole tuettu kehitystyönkuluissa. Tämän seurauksena skenaariot, jotka perustuvat koordinoituihin muutoksiin näiden tuotteiden välillä, eivät välttämättä toimi luotettavasti.

  • Valikoituja committeja varastotasolla ei tällä hetkellä tueta. Muutokset tehdään varaston esinetasolla, eivät tarkempien objektien tasoilla.

  • SQL-analytiikan päätelaitteille versionhallintatuki ei ole tällä hetkellä saatavilla. Tämä rajoitus voi rajoittaa kokonaisvaltaista elinkaaren hallintaa, kun ratkaisut kattavat sekä varastot että SQL-analytiikan päätepisteet.

Git-integroinnin rajoitukset

  • Kun kaksi tai useampi varastotuote viittaa toisiinsa, ne muodostavat syklisen riippuvuuden. Järjestelmä havaitsee tämän ympyräviittauksen haarautumis- tai Git-to-workspace-synkronointitoimintojen aikana, mikä aiheuttaa näiden toimintojen epäonnistumisen. Vältä syklisiä riippuvuuksia esineiden välillä.
  • Tällä hetkellä en luo Dataflow Gen2 -tiedostoa, jossa ulostulokohde olisi varastossa. Uusi nimikohde DataflowsStagingWarehouse ilmestyy arkistoon ja estää sitoutumisen ja päivityksen Gitistä.
  • Ristiinittäiset riippuvuudet, kohteiden sekvensointi ja synkronointiaukot SQL-analytiikan päätepisteen ja varaston välillä vaikuttavat "haarautumiseen uuteen tai olemassa olevaan työtilaan" ja "siirtymiseen toiseen haaraan" -työnkulkuihin kehityksen ja jatkuvan integraation aikana.
  • Jos objekti viittaa toiseen objektiin samassa varastossa käyttämällä kolmiosaista nimeämistä (database.schema.object), sitoutuminen tai päivittäminen Gitistä voi epäonnistua. Lisätietoja ja kiertotien löydät kohdasta Viittaukset varaston omiin objekteihin käyttämällä kolmiosaista nimeä.
  • Jos muutat määritellyn sarakkeen IDENTITY , sitoutuminen tai päivittäminen Gitistä voi epäonnistua, kunnes IDENTITY_INSERT se on käytössä taululle.
  • Jos repositoriossa on .sqlproj tiedosto, joka kiinnittää vanhemman Microsoft.Build.Sql SDK-version, commit tai päivitys Gitistä voi epäonnistua, koska vanhempi SDK ei tunnista uudempaa varastosyntaksia, kuten IDENTITY sarakkeita ja CLUSTER BY. Lisätietoja ja kiertotie löytyy osoitteesta Out-of-date .sqlproj Git-repositoryssa.
  • Jos objekti viittaa kahteen tai useampaan taulukkoon toisessa varastossa ilman, että jokainen sarake on alias-määritellyt, Gitin sitoumus tai päivittäminen voi epäonnistua. Lisätietoja ja kiertotie löytyy kohdasta Kvalifioitumattomat sarakkeet objekteissa, jotka viittaavat kahteen tai useampaan taulukkoon toisessa varastossa.
  • Jos skriptisi viittaavat kahteen tai useampaan eri objektiin samassa skeemassa toisessa varastossa ja kirjoittavat skeeman nimen epäjohdonmukaisella isoilla kirjaimilla, commit tai päivitys Gitistä voi epäonnistua. Lisätietoja ja kiertotie löytyy kohdasta Skeemanimien epäjohdonmukainen alkukirjaimet.
  • Epäselviä sarakkeiden virheitä, joiden ehdokaslistalla on erotin :: , voi ilmetä comcoming-tilanteissa tai päivitettäessä Gitistä, vaikka todellista epäselvyyttä ei olisikaan. Lisätietoja ja kiertoteitä löytyy kohdasta Epäselvät sarakkevirheet kaksoiskandidaattiobjekteilla.

Skenaariot, joita ei tueta

Seuraavat CI/CD-työnkulut eivät ole virallisesti tuettuja, kun eri työtilojen varastoilla on erilaiset kokoukset. Vaikka nämä operaatiot saattavat onnistua ilman virheitä, ne voivat johtaa metatietovirheisiin.

Kaikissa näissä tilanteissa, jos kolloinnin epäsuhta ilmenee, käytä Python-skriptiä scripts/dw-collation-error-update-tmsl/pbi_interactive.py Fabric toolboxissa GitHub päivittääksesi tietoaineiston (TMSL) kokoelman vastaamaan varaston kokoamista.

Skenaario kuvaus Riski
Käyttöönottoputket Varastosisällön edistäminen putkivaiheissa (esimerkiksi Dev → Test → Prod), joissa kohdevarasto on luotu eri kokoamalla kuin lähde, ei ole tuettua. Käyttöönotto saattaa onnistua, mutta tietoaineiston kokoamista ei päivitetä vastaamaan kohdevaraston kokoamista.
Laajentuminen uuteen tai olemassa olevaan työtilaan Git-integraation hyödyntäminen laajentumiseen olemassa olevasta työtilasta uuteen tai olemassa olevaan työtilaan, jossa varastolla on eri kokoaminen, ei ole tuettua. Varaston sisältö synkronoidaan, mutta kokoamismetatietoja ei soviteta yhteen.
Haarojen vaihtaminen työtilassa Siirtyminen konttoriin, joka on yhdistetty eri kokouksen varastoon Git-yhdistetyllä työtilalla, ei ole tuettua. Synkronoitu sisältö saattaa siirtää vertailuoletuksia, jotka eivät vastaa nykyistä varastoa.
Muutosten yhdistäminen työtilojen välillä haarojen kautta Git-haarojen yhdistäminen työtiloihin, joissa varastoilla on erilaisia yhdistelmiä, ei tueta. Yhdistäminen saattaa onnistua Git-tasolla, mutta tuloksena oleva tietoaineiston kokoaminen ei heijasta kohdevaraston kokoamista.

Seuraava vaihe

Käytä Git-integraatiota varastokehitykseen ja käyttöönottoon

Liittyvä sisältö

  • Last updated on