Dela via

Vad är Microsoft Fabric Git-integrering?

  • Artikel

I den här artikeln förklaras för utvecklare hur de integrerar Git-versionskontroll med verktyget För hantering av Livscykelhantering för Microsoft Fabric-program (ALM).

Kommentar

Några av objekten för Git-integrering finns i förhandsversion. Mer information finns i listan över objekt som stöds.

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

  • Säkerhetskopiera och versionshanterade sitt arbete
  • Återgå till föregående steg efter behov
  • Samarbeta med andra eller arbeta ensam med Git-grenar
  • Använda funktionerna i välbekanta källkontrollverktyg för att hantera infrastrukturobjekt

Integreringen med källkontrollen är på arbetsytenivå. Utvecklare kan versionsobjekt som de utvecklar inom en arbetsyta i en enda process, med fullständig insyn i alla deras objekt. Endast ett fåtal objekt stöds för närvarande, men listan över objekt som stöds växer.

  • Läs upp versionskontroll och Git för att se till att du är bekant med grundläggande Git-begrepp.

  • Läs mer om Git-integreringsprocessen.

  • Läs om det bästa sättet att hantera dina Git-grenar.

Sekretessinformation

Innan du aktiverar Git-integrering bör du granska följande sekretesspolicyer:

Git-providers som stöds

Följande Git-leverantörer stöds:

Objekt som stöds

Följande objekt stöds för närvarande:

Om arbetsytan eller Git-katalogen har objekt som inte stöds kan den fortfarande anslutas, men objekt som inte stöds ignoreras. De sparas eller synkroniseras inte, men de tas inte heller bort. De visas på källkontrollpanelen, men du kan inte checka in eller uppdatera dem.

Beaktanden och begränsningar

Allmänna begränsningar för Git-integrering

  • Autentiseringsmetoden i Infrastrukturresurser måste vara minst lika stark som autentiseringsmetoden för Git. Om Git till exempel kräver multifaktorautentisering måste Fabric också kräva multifaktorautentisering.
  • Power BI-datauppsättningar som är anslutna till Analysis Services stöds inte just nu.
  • Arbetsytor med mallappar installerade kan inte anslutas till Git.
  • Nationella moln stöds inte.
  • Azure DevOps-kontot måste vara registrerat för samma användare som använder arbetsytan Infrastruktur.
  • Innehavaradministratören måste aktivera korsgeoexport om arbetsytan och Git-lagringsplatsen finns i två olika geografiska regioner.
  • Incheckningsstorleken är begränsad till 125 MB.

Begränsningar för GitHub Enterprise

Vissa GitHub Enterprise-inställningar stöds inte. Till exempel:

Begränsningar för arbetsyta

  • Endast arbetsytans administratör kan hantera anslutningarna till Git-lagringsplatsen, till exempel ansluta, koppla från eller lägga till en gren.
    När den är ansluten kan alla med behörighet arbeta på arbetsytan.
  • Arbetsytans mappstruktur återspeglas inte i Git-lagringsplatsen. Arbetsyteobjekt i mappar exporteras till rotkatalogen.

Begränsningar för gren och mapp

  • Maximal längd på grennamnet är 244 tecken.
  • Maximal längd på fullständig sökväg för filnamn är 250 tecken. Längre namn misslyckas.
  • Maximal filstorlek är 25 MB.
  • Du kan inte ladda ned en rapport/datauppsättning som .pbix från tjänsten när du har distribuerat dem med Git-integrering.
  • När du namnger en mapp i Git läggs det logiska ID:t (Guid) till som ett prefix före typen om objektets visningsnamn:
    • Har fler än 256 tecken
    • Slutar med . eller ett blanksteg
    • Innehåller något av följande tecken: " / : ? < > \ * |

Förgrena begränsningar

  • Förgrening kräver behörigheter som anges i behörighetstabellen.
  • Det måste finnas en tillgänglig kapacitet för den här åtgärden.
  • Alla begränsningar för namngivning av arbetsyta och gren gäller när du förgrenar till en ny arbetsyta.
  • När du förgrenar ut skapas en ny arbetsyta och inställningarna från den ursprungliga arbetsytan kopieras inte. Justera eventuella inställningar eller definitioner för att säkerställa att den nya arbetsytan uppfyller organisationens principer.
  • Endast Git-objekt som stöds är tillgängliga på den nya arbetsytan.
  • Listan med relaterade grenar visar bara grenar och arbetsytor som du har behörighet att visa.
  • Git-integrering måste vara aktiverat.

Begränsningar för synkronisering och incheckning

  • Du kan bara synkronisera i en riktning i taget. Du kan inte checka in och uppdatera samtidigt.
  • Känslighetsetiketter stöds inte och export av objekt med känslighetsetiketter kan inaktiveras. Om du vill checka in objekt som har känslighetsetiketter utan känslighetsetiketten ber du administratören om hjälp.
  • Fungerar med begränsade objekt. Objekt som inte stöds i mappen ignoreras.
  • Duplicering av namn tillåts inte. Även om Power BI tillåter namnduplicering misslyckas åtgärden uppdatera, checka in eller ångra.
  • B2B stöds inte.
  • Konfliktlösningen görs delvis i Git.
  • Under incheckningen till Git-processen tar Fabric-tjänsten bort filer i objektmappen som inte ingår i objektdefinitionen. Orelaterade filer som inte finns i en objektmapp tas inte bort.
  • När du har checkat in ändringar kan du märka några oväntade ändringar i objektet som du inte gjorde. Dessa ändringar är semantiskt obetydliga och kan inträffa av flera skäl. Till exempel:
    • Ändra objektdefinitionsfilen manuellt. Dessa ändringar är giltiga, men kan vara annorlunda än om de görs via redigeringsprogram. Om du till exempel byter namn på en semantisk modellkolumn i Git och importerar den här ändringen till arbetsytan, nästa gång du checkar in ändringar i den semantiska modellen, registreras bim-filen som ändrad och den ändrade kolumnen skickas till baksidan av matrisen columns . Det beror på att AS-motorn som genererar bim-filerna skickar omdöpta kolumner till slutet av matrisen. Den här ändringen påverkar inte hur objektet fungerar.
    • Checka in en fil som använder CRLF-radbrytningar . Tjänsten använder radbrytningar för LF (radmatning). Om du hade objektfiler på Git-lagringsplatsen med CRLF-radbrytningar ändras filerna till LF när du checkar in från tjänsten. Om du till exempel öppnar en rapport på skrivbordet sparar du .pbip-projektet och laddar upp det till Git med hjälp av CRLF.
  • Om du uppdaterar en semantisk modell med hjälp av API:et för förbättrad uppdatering orsakas en Git-diff efter varje uppdatering.

Relaterat innehåll