Delen via

Wat is Microsoft Fabric Git-integratie?

In dit artikel worden ontwikkelaars uitgelegd hoe u Git-versiebeheer integreert met het hulpprogramma Microsoft Fabric Application Lifecycle Management (ALM).

Notitie

Sommige items voor Git-integratie zijn beschikbaar als preview-versie. Zie de lijst met ondersteunde items voor meer informatie.

Met Git-integratie in Microsoft Fabric kunnen ontwikkelaars hun ontwikkelprocessen, hulpprogramma's en best practices rechtstreeks integreren in het Fabric-platform. Hiermee kunnen ontwikkelaars die in Fabric ontwikkelen het volgende doen:

  • Een back-up maken en hun werk van een versie voorzien
  • Naar behoefte terugkeren naar vorige fasen
  • Samenwerken met anderen of alleen werken met Git branches
  • De mogelijkheden van vertrouwde hulpprogramma's voor broncodebeheer toepassen om Fabric-items te beheren

De integratie met broncodebeheer bevindt zich op werkruimteniveau. Ontwikkelaars kunnen in één proces versies van items beheren die ze ontwikkelen binnen een werkruimte, met volledige zichtbaarheid van hun items. De werkruimtestructuur, inclusief submappen, blijft behouden in de Git-opslagplaats.

Bekijk de lijst van ondersteunde items .

Netwerkbeveiliging voor Git-integratie

Beveiliging op werkruimteniveau in Microsoft Fabric biedt gedetailleerde controle over gegevenstoegang en netwerkconnectiviteit door beheerders in staat te stellen zowel binnenkomende als uitgaande beveiligingen voor afzonderlijke werkruimten te configureren. Deze besturingselementen zorgen ervoor dat gevoelige gegevens binnen de grenzen van vertrouwde netwerken blijven en kunnen worden geïntegreerd met CI/CD-hulpprogramma's zoals Git-integratie. Zie Netwerkbeveiliging voor continue integratie/continue implementatie voor meer informatie

Privacyinformatie

Voordat u Git-integratie inschakelt, moet u de volgende privacyverklaringen bekijken:

Ondersteunde Git-providers

De volgende Git-providers worden ondersteund:

Ondersteunde items

De volgende items ondersteunen momenteel Git-integratie:

Als de werkruimte of Git-map niet-ondersteunde items bevat, kan deze nog steeds worden verbonden, maar worden de niet-ondersteunde items genegeerd. Ze worden niet opgeslagen of gesynchroniseerd, maar ze worden ook niet verwijderd. Ze worden weergegeven in het configuratiescherm van de bron, maar u kunt ze niet doorvoeren of bijwerken.

Overwegingen en beperkingen

Algemene beperkingen voor Git-integratie

  • De verificatiemethode in Fabric moet ten minste zo sterk zijn als de verificatiemethode voor Git. Als Git bijvoorbeeld meervoudige verificatie vereist, moet Fabric ook meervoudige verificatie vereisen.
  • Power BI-gegevenssets die zijn verbonden met Analysis Services worden momenteel niet ondersteund.
  • Als u een werkruimte-id in één artefact gebruikt en deze doorvoert in Git, kan deze alleen worden bijgewerkt (terug naar een infrastructuurwerkruimte) in een werkruimte die is verbonden met dezelfde identiteit. Wees voorzichtig, omdat dit ook van invloed is op functies zoals vertakkingen.
  • Submodules worden niet ondersteund.
  • Onafhankelijke clouds worden niet ondersteund.
  • Als uw werkruimte honderden items bevat, kunt u overwegen deze op te splitsen in kleinere sets artefacten. Elke set moet in een afzonderlijke werkruimte worden geplaatst en gekoppeld aan een andere Git-vertakking, of worden verbonden met één vertakking die in verschillende mappen is ingedeeld.
  • Azure DevOps wordt niet ondersteund als validatie van IP-voorwaardelijke toegangsbeleid inschakelen is ingeschakeld.
  • Als de werkruimte en Git-opslagplaats zich in twee verschillende geografische regio's bevinden, moet de tenantbeheerder cross-geo-exports inschakelen.
  • Als uw organisatie voorwaardelijke toegang heeft geconfigureerd, moet u ervoor zorgen dat de Power BI-service dezelfde voorwaarden heeft ingesteld voor verificatie om te functioneren zoals verwacht.
  • De volgende limiet voor bevestigingsgrootte wordt toegepast:
    • 25 MB met behulp van de Azure DevOps-connector met Service Principal.
    • 125 MB met de standaardaccount voor eenmalige aanmelding (SSO) van Microsoft Entra ID en Azure DevOps-connector met User Principal.

Beperkingen voor GitHub Enterprise

Sommige Versies en instellingen van GitHub Enterprise worden niet ondersteund. Voorbeeld:

  • GitHub Enterprise Cloud met gegevensresidentie (ghe.com)
  • GitHub Enterprise Server met een aangepast domein wordt niet ondersteund, zelfs niet als het exemplaar openbaar toegankelijk is
  • Github Enterprise Server gehost op een privénetwerk
  • IP-acceptatielijst

Azure DevOps naar GitHub Enterprise-migratieoverweging

Als uw team Gebruikmaakt van Fabric Git Integration en een migratie van Azure DevOps naar GitHub Enterprise evalueert, is het raadzaam om validatietests uit te voeren om ervoor te zorgen dat de Functionaliteit van Git-integratie ongewijzigd blijft. Infrastructuur git-integratie is afhankelijk van de onderliggende Git-provider-API's, die verschillen in mogelijkheden en beperkingen tussen Azure DevOps en GitHub Enterprise, zoals hierboven beschreven.

Werkruimtebeperkingen

  • Alleen de werkruimtebeheerder kan de verbindingen met de Git-opslagplaats beheren, zoals verbinding maken, verbinding verbreken of een vertakking toevoegen.
    Zodra er verbinding is gemaakt, kan iedereen met machtigingen in de werkruimte werken.
  • Werkruimten waarop sjabloon-apps zijn geïnstalleerd, kunnen niet worden verbonden met Git.
  • MyWorkspace kan geen verbinding maken met een Git-provider.

Limiteiten van branches en mappen

  • De maximale lengte van de vertakkingsnaam is 244 tekens.
  • De maximale lengte van het volledige pad voor bestandsnamen is 250 tekens. Langere namen werken niet.
  • De maximale bestandsgrootte is 25 MB.
  • De mapstructuur wordt tot 10 niveaus diep behouden.
  • Het downloaden van een rapport/gegevensset als PBIX van de service nadat deze zijn geïmplementeerd met Git-integratie wordt niet aanbevolen, omdat de resultaten onbetrouwbaar zijn. U wordt aangeraden PowerBI Desktop te gebruiken om rapporten/gegevenssets als PBIX te downloaden.
  • Als de weergavenaam van het item een van deze kenmerken heeft, wordt de Git-map hernoemd naar de logische ID (Guid) en het type.
    • Heeft meer dan 256 tekens
    • Eindigt met een . of een spatie
    • Bevat verboden tekens zoals beschreven in beperkingen van mapnamen
  • Wanneer u een werkruimte met mappen verbindt met Git, moet u wijzigingen doorvoeren in de Git-opslagplaats als die mapstructuur anders is.

Beperkingen van mapnamen

  • De naam van de map die verbinding maakt met de Git-opslagplaats heeft de volgende naamgevingsbeperkingen:

    • De mapnaam kan niet beginnen of eindigen met een spatie of tabblad.
    • De mapnaam mag geen van de volgende tekens bevatten: '/:<>\*|

  • De itemmap (de map met de itembestanden) mag geen van de volgende tekens bevatten: ':<>\*?|. Als u de naam van de map wijzigt in iets dat een van deze tekens bevat, kan Git geen verbinding maken of synchroniseren met de werkruimte en treedt er een fout op.

Beperkingen bij het uittakken

  • Uitbreiden vereist machtigingen die worden vermeld in de permissietabel.
  • Er moet een beschikbare capaciteit zijn voor deze actie.
  • Alle beperkingen voor naamgeving van werkruimten en vertakkingen zijn van toepassing bij het vertakken naar een nieuwe werkruimte.
  • Alleen door Git ondersteunde items zijn beschikbaar in de nieuwe werkruimte.
  • In de lijst met gerelateerde vertakkingen worden alleen vertakkingen en werkruimten weergegeven die u mag bekijken.
  • Git-integratie moet zijn ingeschakeld.
  • Wanneer u vertakt, wordt er een nieuwe vertakking gemaakt en worden de instellingen van de oorspronkelijke vertakking niet gekopieerd. Pas instellingen of definities aan om ervoor te zorgen dat de nieuwe voldoet aan het beleid van uw organisatie.
  • Wanneer u zich uitbreidt naar een bestaande werkruimte:
    • De doelwerkruimte moet ondersteuning bieden voor een Git-verbinding.
    • De gebruiker moet een beheerder van de doelwerkruimte zijn.
    • De doelwerkruimte moet capaciteit hebben.
    • De werkruimte kan geen sjabloon-apps hebben.
  • Houd er rekening mee dat wanneer u overstapt naar een werkruimte, alle items die niet in Git zijn opgeslagen, verloren kunnen gaan. U wordt aangeraden om items die u wilt behouden vast te leggen voordat u een tak maakt.

Beperkingen bij het synchroniseren en vastleggen

  • U kunt slechts in één richting synchroniseren. U kunt niet tegelijkertijd doorvoeren en bijwerken.
  • Vertrouwelijkheidslabels worden niet ondersteund en het exporteren van items met vertrouwelijkheidslabels is mogelijk uitgeschakeld. Als u items met vertrouwelijkheidslabels zonder het vertrouwelijkheidslabel wilt doorvoeren, vraagt u de beheerder om hulp.
  • Werkt met beperkt aantal items. Niet-ondersteunde items in de map worden genegeerd.
  • Het dupliceren van namen is niet toegestaan. Zelfs als in Power BI duplicatie van namen is toegestaan, mislukt de update, doorvoer of ongedaan maken.
  • B2B wordt niet ondersteund.
  • Conflictoplossing wordt gedeeltelijk uitgevoerd in Git.
  • Tijdens het doorvoeren naar Git-proces verwijdert de Fabric-service bestanden in de itemmap die geen deel uitmaken van de itemdefinitie. Niet-gerelateerde bestanden die niet in een itemmap staan, worden niet verwijderd.
  • Nadat u wijzigingen hebt doorgevoerd, ziet u mogelijk enkele onverwachte wijzigingen in het item dat u niet hebt aangebracht. Deze wijzigingen zijn semantisch onbelangrijk en kunnen om verschillende redenen optreden. Bijvoorbeeld:
    • Het itemdefinitiebestand handmatig wijzigen. Deze wijzigingen zijn geldig, maar zijn mogelijk anders dan wanneer ze via de editors worden uitgevoerd. Als u bijvoorbeeld de naam van een kolom met een semantisch model in Git wijzigt en deze wijziging in de werkruimte importeert, wordt het bim-bestand geregistreerd als gewijzigd en wordt de gewijzigde kolom naar de achterkant van de columns matrix gepusht. Dit komt doordat de AS-engine, die de bim-bestanden genereert, de hernoemde kolommen naar het einde van de matrix verplaatst. Deze wijziging heeft geen invloed op de manier waarop het item werkt.
    • Een bestand doorvoeren dat CRLF-regeleinden gebruikt. De service maakt gebruik van LF (regelovergang) regeleinden. Als u itembestanden in de Git-opslagplaats met CRLF-regeleinden had, worden deze bestanden gewijzigd in LF wanneer u vanuit de service doorvoert. Als u bijvoorbeeld een rapport opent op het bureaublad, slaat u het projectbestand (.pbip) op en uploadt u het naar Git met behulp van CRLF.
  • Als u een semantisch model vernieuwt met behulp van de uitgebreide vernieuwings-API , wordt na elke vernieuwing een Git-diff veroorzaakt.

Gerelateerde inhoud

  • Last updated on