Vad är Microsoft Fabric Git-integrering?
I den här artikeln förklaras för utvecklare hur de integrerar Git-versionskontroll med Microsoft Fabric-livscykelhanteringsverktyget (ALM).
Anteckning
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 versionshantera sitt arbete
- Återgå till föregående steg efter behov
- Samarbeta med andra eller arbeta ensam med Git-grenar
- Använd funktionerna i välbekanta källkontrollverktyg för att hantera Fabric-objekt
Se listan över objekt som stöds.
Läs mer om grundläggande git- och versionskontroll begrepp.
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:
- Git i Azure Repos med samma tenant som Fabric-tenanten
- GitHub- (endast molnversioner)
- GitHub Enterprise (endast molnversioner)
Objekt som stöds
Följande objekt stöds för närvarande:
- Datapipelines(förhandsversion)
- Dataflöden gen2(förhandsversion)
- Eventhouse- och KQL-databas(förhandsversion)
- EventStream(förhandsversion)
- Lakehouse(förhandsversion)
- Speglad databas(förhandsversion)
- Anteckningsböcker
- Sidindelade rapporter(förhandsversion)
- Reflex (förhandsversion)
- Rapporter (förutom rapporter som är anslutna till semantiska modeller som finns i Azure Analysis Services, SQL Server Analysis Serviceseller rapporter som exporteras av Power BI Desktop som är beroende av semantiska modeller som finns i MyWorkspace) (förhandsversion)
- Semantiska modeller (förutom push-datauppsättningar, liveanslutningar till Analysis Services, modell v1) (förhandsversion)
- Spark-jobbdefinitioner(förhandsversion)
- Spark-miljö(förhandsversion)
- SQL-databas(förhandsversion)
- Lager(förhandsversion)
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 i versionshanteringspanelen, men du kan inte skicka 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.
- Undermoduler stöds inte.
- Nationella moln stöds inte.
- Azure DevOps-kontot måste vara registrerat för samma användare som använder Fabric-arbetsytan.
- Azure DevOps stöds inte om aktivering av IP-villkorsstyrd åtkomstprincipvalidering är aktiverad.
- Innehavaradministratören måste aktivera korsgeoexport om arbetsytan och Git-lagringsplatsen finns i två olika geografiska regioner.
- Om din organisation har konfigurerat villkorlig åtkomstkontrollerar du att Power BI-tjänsten har samma villkor som för att autentiseringen ska fungera som förväntat.
- Ändringsstorleken är begränsad till 125 MB.
Begränsningar för GitHub Enterprise
Vissa GitHub Enterprise-inställningar stöds inte. Till exempel:
- LISTA över TILLÅTNA IP-adresser
- Privata nätverk
- Anpassade domäner
Begränsningar för arbetsyta
- Endast arbetsytans administratör kan hantera anslutningarna till Git-repositoriet, såsom att ansluta, koppla från eller lägga till en gren.
När den är ansluten kan alla med behörighet arbeta på arbetsytan.
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 fungerar inte.
- Maximal filstorlek är 25 MB.
- Mappstrukturen behålls ner till 10 nivåers djup.
- Du kan inte ladda ned en rapport/datauppsättning som .pbix från tjänsten när du har distribuerat dem med Git-integrering.
- Om objektets visningsnamn har någon av dessa egenskaper byter Git-mappen namn till det logiska ID:t (Guid) och skriver:
- Har fler än 256 tecken
- Slutar med en . eller ett mellanslag
- Innehåller otillåtna tecken enligt beskrivningen i katalognamnsbegränsningar
- När du ansluter en arbetsyta som har mappar till Git måste du checka in ändringar på Git-lagringsplatsen om den mappstrukturen är annorlunda.
Begränsningar för katalognamn
Namnet på katalogen som ansluter till Git-lagringsplatsen har följande namngivningsbegränsningar:
- Katalognamnet kan inte börja eller sluta med ett mellanslag eller en flik.
- Katalognamnet får inte innehålla något av följande tecken: "/:<>\*?|
Objektmappen (mappen som innehåller objektfilerna) får inte innehålla något av följande tecken: ":<>\*?|. Om du byter namn på mappen till något som innehåller något av dessa tecken kan Git inte ansluta eller synkronisera med arbetsytan och ett fel uppstår.
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.
- 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.
- När du förgrenar ut skapas en ny gren och inställningarna från den ursprungliga grenen kopieras inte. Justera alla inställningar eller definitioner för att säkerställa att det nya uppfyller organisationens principer.
- När du utvidgar till en redan befintlig arbetsyta:
- Målarbetsytan måste ha stöd för en Git-anslutning.
- Användaren måste vara administratör för målarbetsytan.
- Målarbetsytan måste ha kapacitet.
- Arbetsytan kan inte innehålla mallappar.
- Observera att när du förgrenar dig till en arbetsyta kan alla objekt som inte sparas i Git gå förlorade. Vi rekommenderar att du kommitterar ändringar som du vill behålla innan du förgrenar dig.
Begränsningar för synkronisering och versionshantering
- 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. För att klarera objekt som har känslighetsetiketter utan dem, be 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 dubbletter av namn, misslyckas uppdaterings-, inchecknings- eller ångraåtgärderna.
- 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 sparat ä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. - Att skicka in en fil som använder CRLF-radbrytningar. Tjänsten använder LF (radmatning) för radbrytningar. 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 projektfilen (.pbip) och laddar upp den till Git med hjälp av CRLF-.
- Ä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
- 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.