Källkontroll (förhandsversion)

Applies to:✅ Warehouse i Microsoft Fabric

Den här artikeln förklarar hur Git-integrerings- och distributionspipelines fungerar för lager i Microsoft Fabric. Lär dig hur du konfigurerar en anslutning till din lagringsplats, hanterar dina lager och distribuerar dem i olika miljöer. Källkontroll för Fabric Warehouse är för närvarande en förhandsversionsfunktion.

Du kan använda både Git-integrerings - och distributionspipelines för olika scenarier:

• Använd Git- och SQL-databasprojekt för att hantera inkrementell förändring, teamsamarbete och incheckningshistorik i enskilda databasobjekt.
• Använd distributionspipelines för att främja kodändringar till olika förproduktions- och produktionsmiljöer.

Git-integrering

Git-integrering i Microsoft Fabric gör det möjligt för utvecklare att integrera sina utvecklingsprocesser, verktyg och bästa praxis direkt i Fabric-plattformen. Det gör det möjligt för utvecklare som utvecklar i Fabric att:

• Säkerhetskopierar och versionshanterar sitt arbete
• Återgå till föregående steg efter behov
• Samarbeta med andra eller arbeta ensam med hjälp av Git-grenar
• Använd funktionerna i välbekanta källkontrollverktyg för att hantera Fabric objekt

Mer information om Git-integreringsprocessen finns i:

• Vad är Microsoft Fabric Git-integrering?
• Grundläggande begrepp i Git-integrering
• Kom igång med Git-integrering

Konfigurera en anslutning till källkontrollen

På sidan Inställningar för arbetsyta kan du enkelt konfigurera en anslutning till lagringsplatsen för att checka in och synkronisera ändringar.

1. Information om hur du konfigurerar anslutningen finns i Kom igång med Git-integrering. Följ anvisningarna för att Anslut till en Git-lagringsplats till antingen Azure DevOps eller GitHub som Git-provider.
2. När du är ansluten visas dina objekt, inklusive lager, på kontrollpanelen Källa.
3. När du har anslutit lagerinstanserna till Git-lagringsplatsen visas lagermappsstrukturen på lagringsplatsen. Nu kan du köra framtida åtgärder, till exempel skapa en pull-begäran.

Databasprojekt för ett lager i Git

Följande bild är ett exempel på filstrukturen för varje lagerobjekt på lagringsplatsen:

När du checkar in lagerartikeln på Git-lagringsplatsen konverteras lagret till ett källkodsformat som ett SQL-databasprojekt. Ett SQL-projekt är en lokal representation av SQL-objekt som utgör schemat för en enskild databas, till exempel tabeller, lagrade procedurer eller funktioner. Mappstrukturen för databasobjekten ordnas efter schema/objekttyp. Varje objekt i lagret representeras med en .sql fil som innehåller dess definition av datadefinitionsspråk (DDL). Informationslagertabelldata och SQL-säkerhetsfunktioner ingår inte i SQL-databasprojektet.

Delade frågor kommer också att lagras i arkivet och ärver det namn under vilket de sparas.

Utrullningspipelines

Du kan också använda distributionspipelines för att distribuera din lagerkod i olika miljöer, till exempel utveckling, test och produktion. Distributionspipelines exponerar inte ett databasprojekt.

Använd följande steg för att slutföra distributionen av ditt lager med hjälp av distributionspipelinen.

1. Skapa en ny distributionspipeline eller öppna en befintlig distributionspipeline. Mer information finns i Kom igång med distributionspipelines.
2. Tilldela arbetsytor till olika faser enligt dina distributionsmål.
3. Välj, visa och jämför objekt, inklusive lager, mellan olika faser, som du ser i följande exempel.
4. Välj Distribuera för att distribuera dina lager i utvecklings-, test- och produktionsfaserna.

För mer information om distributionspipelines-processen för Fabric, se Introduction to deployment pipelines.

Begränsningar i källkontroll

• Du måste exportera eller migrera SQL-säkerhetsfunktioner med hjälp av en skriptbaserad metod. Överväg att använda ett skript efter distributionen i ett SQL-databasprojekt. Du kan konfigurera det här skriptet genom att öppna projektet med tillägget SQL Database Projects i Visual Studio Code.

Begränsningar i Git-integrering

• För närvarande, om du använder ALTER TABLE för att lägga till en begränsning eller kolumn i databasprojektet, släpper distributionsprocessen och återskapar tabellen, vilket resulterar i dataförlust. Tänk på följande lösning för att bevara tabelldefinitionen och data:
  • Skapa en ny kopia av tabellen i lagret genom att använda CREATE TABLE, INSERT, CREATE TABLE AS SELECT eller Klona tabell.
  • Ändra den nya tabelldefinitionen med nya begränsningar eller kolumner efter behov med hjälp ALTER TABLEav .
  • Ta bort den gamla tabellen.
  • Byt namn på den nya tabellen till namnet på den gamla tabellen med hjälp av sp_rename.
  • Ändra definitionen av den gamla tabellen i SQL-databasprojektet på exakt samma sätt. SQL-databasprojektet för lagret i källkontrollen och det aktiva lagret bör nu matcha.
• Skapa för närvarande inte ett Dataflöde Gen2 med ett utdatamål till lagret. Ett nytt objekt med namnet DataflowsStagingWarehouse visas på lagringsplatsen och blockerar incheckning och uppdatering från Git.
• Fabric Git-integrering stöder inte SQL-analysslutpunktsobjektet.
• Beroenden mellan objekt, sekvensering av objekt och synkroniseringsluckor mellan SQL-analysslutpunkten och datavarulagret påverkar "grena ut till en ny eller befintlig arbetsyta" och "växla till en annan gren" under utveckling och kontinuerlig integration.

Begränsningar för distributionsflöden

• För närvarande, om du använder ALTER TABLE för att lägga till en begränsning eller kolumn i databasprojektet, släpper distributionsprocessen och återskapar tabellen, vilket resulterar i dataförlust.
• Skapa för närvarande inte ett Dataflöde Gen2 med ett utdatamål till lagret. Ett nytt objekt med namnet DataflowsStagingWarehouse visas i distributionspipelinen och blockerar distributionen.
• Fabric Distributionspipelines stöder inte SQL-analysslutpunktsobjektet.
• Beroenden mellan objekt, objektsekvensering och synkroniseringsluckor mellan SQL-analysslutpunkten och informationslagret påverkar Fabric arbetsflöden för distributionspipelines.

Scenarier som inte stöds

Följande CI/CD-arbetsflöden stöds inte officiellt när datalager i olika arbetsytor har olika sorteringsordning. Även om dessa åtgärder kan lyckas utan fel kan de resultera i metadatafel.

I alla dessa scenarier, om ett sorteringskonflikt inträffar, använd Python-skriptet scripts/dw-collation-error-update-tmsl/pbi_interactive.py i Fabric toolbox GitHub-förråd för att uppdatera datamängdens (TMSL) sorteringsordning till att matcha lagersorteringen.

Relaterat innehåll

• Utveckling och distribution
• Kom igång med Git-integrering