Dela via

Hantera grenar i arbetsytor i Microsoft Fabric

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.

Förutsättningar för nätverksstruktur

För att få åtkomst till Git-integreringsfunktionen behöver du en Fabric-kapacitet. En Fabric-kapacitet krävs för att använda alla stödda Fabric-objekt. Om du inte har någon ännu kan du registrera dig för en kostnadsfri utvärderingsversion. Kunder som redan har en Power BI Premium-kapacitetkan använda den kapaciteten, men tänk på att vissa Power BI-SKU:er endast stöder Power BI-objekt.

Dessutom måste följande klientväxlar aktiveras från administratörsportalen:

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 DevOps-konto som har registrerats för samma användare och klientorganisation som använder Fabric-arbetsytan (stöd för flera klientorganisationer finns för närvarande i förhandsversion). Skapa ett kostnadsfritt konto.
  • Åtkomst till en befintlig lagringsplats.

Utvecklingsprocess

Arbetsytan Fabric är en delad miljö som har åtkomst till aktuella objekt. Ä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.

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:

  1. Klona repot på en lokal dator. (Du behöver bara göra det här steget en gång.)

  2. Öppna projektet i Power BI Desktop med hjälp av den lokala kopian av PBIProj.

  3. Gör ändringar och spara de uppdaterade filerna lokalt. Commit till det lokala repo.

  4. När du är klar skickar du grenen och checkar in på fjärrplatsen.

  5. Testa ändringarna mot andra objekt eller mot mer data. Om du vill testa ändringarna ansluter du den nya grenen till en separat arbetsyta och laddar upp semantikmodellen och rapporterna med hjälp av 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.

  6. När ändringarna har sammanfogats, uppmanas det delade teamets arbetsyta att acceptera den nya commit. Ändringarna uppdateras till den delade arbetsytan och alla kan se ändringarna i dessa semantiska modeller och rapporter.

Diagram som visar arbetsflödet för överföring av ändringar från en fjärransluten Git-lagringsplats till arbetsytan Fabric.

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:

  1. På fliken Grenar i menyn Källkontroll väljer du Förgrena ut till en annan arbetsyta.

    Skärmbild av alternativet för utgrening av källkontroll.

  2. Ange om du vill skapa en ny arbetsyta eller växla till en befintlig. Ange namnen på den nya grenen och arbetsytan eller välj den befintliga arbetsytan i listrutan. Följande skärmbild visas när du skapar en ny arbetsyta.

Anmärkning

När du förgrenar dig till en arbetsyta kan alla objekt som inte sparas i Git gå förlorade. Vi rekommenderar att du skickar in alla föremål som du vill behålla innan du förgrenar dig.

Skärmbild av utgrening som anger namnet på den nya grenen och arbetsytan.

Viktigt!

När du förgrenar till en befintlig arbetsyta kan vissa objekt tas bort.

För en befintlig arbetsyta visas skärmbilden nedan som varnar för att anslutning till en befintlig arbetsyta kan leda till att vissa objekt tas bort.

Skärmbild av utgrening som anger befintlig gren och arbetsyta.

  1. Välj Förgrena ut.

    Fabric 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 att förgrena ut finns i felsökningstips.

    Diagram som visar arbetsflödet för commits.

  2. Spara ändringarna och kommittera dem i funktionsgren.

  3. När du är klar, skapa 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 commit 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örgrena begränsningar.

Släppningsprocess

Lanseringsprocessen börjar när nya uppdateringar slutför en pull-begäran och sammanfogas till teamets delade gren (till exempel Main, Devosv.). Från denna punkt finns det olika alternativ för att bygga en lanseringsprocess i Fabric. Mer information om olika alternativ att tänka på när du utformar arbetsflödet finns i versionsprocess.

Byt gren

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 blir arbetsytan synkroniserad med den nya grenen och alla objekt på arbetsytan åsidosätts. 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.

Viktigt!

När du växlar grenar tas objektet bort om arbetsytan innehåller ett objekt i den gamla grenen men inte den nya.

Följ dessa steg om du vill växla mellan grenar:

  1. Från fliken Grenar i menyn Källkontroll väljer du Växla gren.

    Skärmbild av källkontroll, kolla in ett nytt grenalternativ.

  2. 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.

  3. Gör en kontroll i Jag förstår att arbetsyteobjekt kan tas bort och inte kan återställas. Välj Växla gren.

    Skärmbild av hur du byter grenar.

Du kan inte växla brancher om du har några okommitterade ä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.

Relaterat innehåll