Hantera grenar i Microsoft Fabric-arbetsytor
Målet med den här artikeln är att presentera infrastrukturutvecklare med olika alternativ för att skapa CI/CD-processer i Fabric, baserat på vanliga kundscenarier. Den här artikeln fokuserar mer på den kontinuerliga integreringen (CI) i CI/CD-processen. En diskussion om den kontinuerliga leveransdelen (CD) finns i Hantera distributionspipelines.
Den här artikeln beskriver några olika integreringsalternativ, men många organisationer använder en kombination av dem.
Förutsättningar
För att integrera Git med din Microsoft Fabric-arbetsyta måste du konfigurera följande krav för både Fabric och Git.
Krav för infrastrukturresurser
För att få åtkomst till Git-integreringsfunktionen behöver du något av följande:
- Power BI Premium-licens. En Power BI Premium-licens stöder endast alla Power BI-objekt.
- Infrastrukturkapacitet. En infrastrukturresurskapacitet krävs för att använda alla infrastrukturresurser som stöds. Om du inte har någon ännu kan du registrera dig för en kostnadsfri utvärderingsversion.
Dessutom måste följande klientväxlar aktiveras från administratörsportalen:
- Användare kan skapa infrastrukturobjekt
- Användare kan synkronisera arbetsyteobjekt med sina Git-lagringsplatser
- Endast för GitHub-användare: Användare kan synkronisera arbetsyteobjekt med GitHub-lagringsplatser
Dessa växlar kan aktiveras av klientorganisationens administratör, kapacitetsadministratör eller arbetsyteadministratör, beroende på organisationens inställningar.
Git-krav
Git-integrering stöds för närvarande för Azure DevOps och GitHub. Om du vill använda Git-integrering med din Infrastruktur-arbetsyta behöver du följande i Antingen Azure DevOps eller GitHub:
- Ett aktivt Azure-konto som har registrerats för samma användare som använder arbetsytan Infrastruktur. Skapa ett kostnadsfritt konto.
- Åtkomst till en befintlig lagringsplats.
Utvecklingsprocess
Arbetsytan Infrastrukturresurser är en delad miljö som har åtkomst till liveobjekt. Ändringar som görs direkt i arbetsytan åsidosätter och påverkar alla andra arbetsyteanvändare. Därför är bästa praxis för Git att utvecklare arbetar isolerat utanför de delade arbetsytorna. Det finns två sätt för en utvecklare att arbeta på sin egen skyddade arbetsyta.
- Utveckla med hjälp av klientverktyg, till exempel Power BI Desktop för rapporter och semantiska modeller eller VS Code för notebook-filer.
- Utveckla i en separat infrastrukturarbetsyta. Varje utvecklare har en egen arbetsyta där de ansluter sin egen separata gren, synkroniserar innehållet till den arbetsytan och sedan checkar tillbaka till grenen.
Om du vill arbeta med grenar med Git-integrering ansluter du först arbetsytan för det delade utvecklingsteamet till en enda delad gren. Om ditt team till exempel använder en delad arbetsyta ansluter du den till huvudgrenen på teamets lagringsplats och synkroniserar mellan arbetsytan och lagringsplatsen. Om teamets arbetsflöde har flera delade grenar som Dev/Test/Prod-grenar kan varje gren anslutas till en annan arbetsyta.
Sedan kan varje utvecklare välja den isolerade miljö där de ska arbeta.
Scenario 1 – Utveckla med klientverktyg
Om de objekt som du utvecklar är tillgängliga i andra verktyg kan du arbeta med dessa objekt direkt i klientverktyget. Alla objekt är inte tillgängliga i alla verktyg. Objekt som endast är tillgängliga i Fabric behöver utvecklas i Fabric.
Arbetsflödet för utvecklare som använder ett klientverktyg som Power BI Desktop bör se ut ungefär så här:
Klona lagringsplatsen till en lokal dator. (Du behöver bara göra det här steget en gång.)
Öppna projektet i Power BI Desktop med hjälp av den lokala kopian av PBIProj.
Gör ändringar och spara de uppdaterade filerna lokalt. Checka in på den lokala lagringsplatsen.
När du är klar skickar du grenen och checkar in på fjärrplatsen.
Testa ändringarna mot andra objekt eller mer data genom att ansluta den nya grenen till en separat arbetsyta och ladda upp semantikmodellen och rapporterna med knappen Uppdatera alla på källkontrollpanelen. Gör några tester eller konfigurationsändringar där innan du sammanfogar till huvudgrenen.
Om inga tester krävs på arbetsytan kan utvecklaren sammanfoga ändringar direkt till huvudgrenen, utan att behöva någon annan arbetsyta.
När ändringarna har sammanfogats uppmanas det delade teamets arbetsyta att acceptera den nya incheckningen. Ändringarna uppdateras till den delade arbetsytan och alla kan se ändringarna i dessa semantiska modeller och rapporter.
En specifik vägledning om hur du använder det nya Power BI Desktop-filformatet i git finns i Källkodsformat.
Scenario 2 – Utveckla med hjälp av en annan arbetsyta
För en utvecklare som arbetar på webben skulle flödet vara följande:
På fliken Grenar på menyn Källkontroll väljer du Förgrena ut till ny arbetsyta.
Ange namnen på grenen och arbetsytan. Den nya grenen som skapats baserat på grenen som är ansluten till den aktuella arbetsytan.
Välj Förgrena ut.
Infrastrukturresurser skapar den nya arbetsytan och grenen. Du tas automatiskt till den nya arbetsytan.
Arbetsytan synkroniseras med din funktionsgren och blir en isolerad miljö att arbeta i, enligt bilden. Nu kan du arbeta i den här nya isolerade miljön. Synkroniseringen kan ta några minuter. Mer information om utgrening finns i felsökningstips.
Spara ändringarna och checka in dem i funktionsgrenen.
När du är klar skapar du en PR till huvudgrenen . Gransknings- och sammanslagningsprocesserna görs via Azure Repos baserat på den konfiguration som ditt team har definierat för lagringsplatsen.
När granskningen och sammanfogningen är klar skapas en ny incheckning till huvudgrenen. Den här incheckningen uppmanar användaren att uppdatera innehållet på Dev-teamets arbetsyta med de sammanfogade ändringarna.
Mer information finns i förgrening av begränsningar .
Släppningsprocess
Lanseringsprocessen börjar när nya uppdateringar har slutfört en pull-begäran och sammanfogats till teamets delade gren (till exempel Main, Dev osv.). Från och med nu beskriver vi de olika alternativen för att skapa en lanseringsprocess i Infrastrukturresurser. Du hittar de olika övervägandena för lanseringsprocessen i hantera distributionspipelines.
Växla grenar
Om din arbetsyta är ansluten till en Git-gren och du vill växla till en annan gren kan du göra det snabbt från fönstret Källkontroll utan att koppla från och återansluta.
När du växlar grenar synkroniseras arbetsytan med den nya grenen och alla objekt på arbetsytan åsidosättas. Om det finns olika versioner av samma objekt i varje gren ersätts objektet. Om ett objekt finns i den gamla grenen, men inte det nya, tas det bort.
Följ dessa steg om du vill växla mellan grenar:
På fliken Grenar på menyn Källkontroll väljer du Växla gren.
Ange den gren som du vill ansluta till eller skapa en ny gren. Den här grenen måste innehålla samma katalog som den aktuella grenen.
Välj Växla gren.
Du kan inte växla grenar om du har några icke-bakåtkompatibla ändringar på arbetsytan. Välj Avbryt för att gå tillbaka och checka in ändringarna innan du byter grenar.
Om du vill ansluta den aktuella arbetsytan till en ny gren samtidigt som den befintliga arbetsytans status behålls väljer du Checka ut ny gren. Läs mer om att checka ut en ny gren i Lösa konflikter i Git.