Partager via

Qu’est-ce que l’intégration de Microsoft Fabric Git ?

Cet article explique aux développeurs comment intégrer le contrôle de version Git à l’outil Microsoft Fabric Application Lifecycle Management (ALM).

Remarque

Certains éléments de l’intégration Git sont en préversion. Pour plus d’informations, consultez la liste des éléments pris en charge.

L’intégration de git dans Microsoft Fabric permet aux développeurs d’intégrer leurs processus de développement, leurs outils et leurs meilleures pratiques directement dans la plateforme Fabric. Elle permet aux développeurs qui développent dans Fabric de :

  • Sauvegarder et versionner leur travail
  • Revenir aux étapes précédentes si nécessaire
  • Collaborer avec d’autres personnes ou travailler seul à l’aide de branches Git
  • Appliquer les capacités des outils de contrôle de code source familiers pour gérer les éléments Fabric

L’intégration avec le contrôle de code source se fait au niveau de l’espace de travail. Les développeurs peuvent versionner les éléments qu’ils développent au sein d’un espace de travail dans un seul processus, avec une visibilité totale sur l’ensemble de leurs éléments. La structure de l’espace de travail, y compris sous-dossiers, est conservée dans le référentiel Git.

Consultez la liste des éléments pris en charge .

Sécurité réseau pour l’intégration de Git

La sécurité au niveau de l’espace de travail dans Microsoft Fabric offre un contrôle granulaire sur l’accès aux données et la connectivité réseau en permettant aux administrateurs de configurer des protections entrantes et sortantes pour des espaces de travail individuels. Ces contrôles garantissent que les données sensibles restent dans des limites de réseau approuvées et qu’elles s’intègrent à des outils CI/CD tels que l’intégration Git. Pour plus d’informations, consultez Sécurité réseau pour l’intégration continue/le déploiement continu

Informations de confidentialité

Avant d’activer l’intégration Git, assurez-vous de bien prendre connaissance des questions de confidentialité suivantes :

Fournisseurs Git pris en charge

Les fournisseurs Git suivants sont pris en charge :

Éléments pris en charge

Les éléments suivants prennent actuellement en charge l’intégration Git :

Si l’espace de travail ou le répertoire Git contient des éléments non pris en charge, il peut toujours être connecté, mais les éléments non pris en charge sont ignorés. Ils ne sont pas enregistrés ni synchronisés, mais ils ne sont pas supprimés non plus. Ils s’affichent dans le volet de contrôle de code source, mais vous ne pouvez pas les valider ni les mettre à jour.

Observations et limitations

Limitations générales de l’intégration Git

  • La méthode d’authentification dans Fabric doit être au moins aussi forte que la méthode d’authentification pour Git. Par exemple, si Git nécessite une authentification multifacteur, Fabric doit également exiger l’authentification multifacteur.
  • Les jeux de données Power BI connectés à Analysis Services ne sont pas pris en charge pour l’instant.
  • Si vous utilisez une identité d’espace de travail dans un artefact et que vous la validez sur Git, elle peut être mise à jour (retour à un espace de travail fabric) uniquement dans un espace de travail connecté à la même identité. Soyez prudent, car cela affecte également les fonctionnalités telles que les ramifications.
  • Les sous-modules ne sont pas pris en charge.
  • Les clouds souverains ne sont pas pris en charge.
  • Si votre espace de travail contient des centaines d’éléments, envisagez de le fractionner en jeux d’artefacts plus petits. Chaque ensemble doit être placé dans un espace de travail distinct et lié à une autre branche Git, ou connecté à une branche unique organisée dans différents dossiers.
  • Azure DevOps n’est pas pris en charge si Activer la validation de la stratégie d’accès conditionnel IP est activé.
  • Si l’espace de travail et le référentiel Git se trouvent dans deux régions géographiques différentes, l’administrateur du locataire doit activer les exportations intergéographiques.
  • Si votre organisation a configuré l’accès conditionnel , vérifiez que le service Power BI a les mêmes conditions définies pour que l’authentification fonctionne comme prévu.
  • La limite de taille de « commit » suivante est appliquée :
    • 25 Mo en utilisant le connecteur Azure DevOps avec le Service Principal.
    • 125 Mo à l’aide du compte d’ID Microsoft Entra (SSO) par défaut et du connecteur Azure DevOps avec User Principal.

Limites GitHub Enterprise

Certaines versions et paramètres gitHub Enterprise ne sont pas pris en charge. Par exemple :

  • GitHub Enterprise Server avec un domaine personnalisé n’est pas pris en charge, même si l’instance est accessible publiquement
  • GitHub Enterprise Server hébergé sur un réseau privé
  • Liste verte d’adresses IP

Considérations relatives à la migration d’Azure DevOps vers GitHub Enterprise

Si votre équipe utilise Fabric Git Integration et évalue une migration d’Azure DevOps vers GitHub Enterprise, il est recommandé d’exécuter des tests de validation pour vous assurer que la fonctionnalité d’intégration Git reste inchangée. Fabric Git Integration s’appuie sur les API de fournisseur Git sous-jacentes, qui diffèrent dans les fonctionnalités et les limitations entre Azure DevOps et GitHub Enterprise, comme décrit ci-dessus.

Limitations de l’espace de travail

  • Seul l’administrateur de l’espace de travail peut gérer les connexions au référentiel Git, telles que la connexion, la déconnexion ou l’ajout d’une branche.
    Une fois connecté, toute personne autorisée peut travailler dans l’espace de travail.
  • Les espaces de travail avec des applications modèles installées ne peuvent pas être connectés à Git.
  • MyWorkspace ne peut pas se connecter à un fournisseur Git.
  • Les espaces de travail peuvent contenir au maximum 1 000 éléments. Si la branche Git contient plus de 1 000 éléments, la synchronisation du contenu avec l’espace de travail échoue. Pour éviter cette limitation, envisagez de fractionner vos artefacts en jeux plus petits. Chaque ensemble doit être placé dans un espace de travail distinct et lié à une autre branche Git, ou organisé dans différents dossiers au sein d’une seule branche.

Limitations des branches et des dossiers

  • La longueur maximale du nom de la branche est de 244 caractères.
  • La longueur maximale du chemin d’accès complet pour les noms de fichiers est de 250 caractères. Les noms plus longs échouent.
  • La taille maximale du fichier est de 25 Mo.
  • La structure des dossiers est conservée jusqu’à 10 niveaux de profondeur.
  • Le téléchargement d’un rapport/jeu de données en tant que .pbix à partir du service après leur déploiement avec l’intégration Git n’est pas recommandé, car les résultats ne sont pas fiables. Nous vous recommandons d’utiliser Power BI Desktop pour télécharger des rapports/jeux de données en tant que .pbix.
  • Si le nom d’affichage de l’élément présente l’une de ces caractéristiques, le dossier Git est renommé en fonction de l’ID logique (Guid) et du type :
  • Lorsque vous connectez un espace de travail contenant des dossiers à Git, vous devez valider les modifications apportées au dépôt Git si cette structure de dossiers est différente.

Limitations du nom de répertoire

  • Le nom du répertoire qui se connecte au référentiel Git a les restrictions d’affectation de noms suivantes :

    • Le nom du répertoire ne peut pas commencer ou se terminer par un espace ou un onglet.
    • Le nom du répertoire ne peut contenir aucun des caractères suivants : "/:<>\*?|

  • Le dossier d’éléments (le dossier qui contient les fichiers d’éléments) ne peut contenir aucun des caractères suivants : «:<>\*?|. Si vous renommez le dossier en un de ces caractères, Git ne peut pas se connecter ou se synchroniser avec l’espace de travail et une erreur se produit.

Limitations à l'expansion

  • Les embranchements nécessitent des autorisations listées dans la table d’autorisations.
  • Il doit y avoir une capacité disponible pour cette action.
  • Toutes les limitations d’affectation de noms d’espace de travail et de branche s’appliquent lors du branchement à un nouvel espace de travail.
  • Seuls les éléments pris en charge par Git sont disponibles dans le nouvel espace de travail.
  • La liste des branches associées affiche uniquement les branches et les espaces de travail que vous avez l’autorisation d’afficher.
  • L’intégration Git doit être activée.
  • Lors de la création d’une branche, une nouvelle branche est créée et les paramètres de la branche d’origine ne sont pas copiés. Ajustez les paramètres ou définitions pour vous assurer que le nouveau répond aux stratégies de votre organisation.
  • Lorsque vous créez un embranchement vers un espace de travail existant :
    • L’espace de travail cible doit prendre en charge une connexion Git.
    • L’utilisateur doit être administrateur de l’espace de travail cible.
    • L’espace de travail cible doit avoir une capacité.
    • L’espace de travail ne peut pas avoir d’applications modèles.
  • Notez que lorsque vous créez un embranchement vers un espace de travail, tous les éléments qui ne sont pas enregistrés dans Git peuvent être perdus. Nous vous recommandons de valider tous les éléments que vous souhaitez conserver avant de créer l’embranchement.

Limitations de synchronisation et de validation

  • Vous ne pouvez synchroniser que dans une seule direction à la fois. Vous ne pouvez pas valider et mettre à jour en même temps.
  • Les étiquettes de confidentialité ne sont pas prises en charge et l’exportation d’éléments avec des étiquettes de confidentialité peut être désactivée. Pour valider des éléments qui ont des étiquettes de confidentialité sans étiquette de confidentialité, demandez de l’aide à l’administrateur.
  • Fonctionne avec des éléments limités. Des éléments non pris en charge dans le dossier sont ignorés.
  • La duplication des noms n’est pas autorisée. Même si Power BI autorise la duplication de noms, l’action de mise à jour, de validation ou d’annulation échoue.
  • B2B n’est pas pris en charge.
  • La résolution des conflits est partiellement effectuée dans Git.
  • Pendant le processus de Validation vers Git, le service Fabric supprime tous les fichiers à l’intérieur du dossier d’élément qui ne font pas partie de la définition d’élément. Les fichiers non liés qui ne se trouvent pas dans un dossier d’élément ne sont pas supprimés.
  • Une fois les modifications validées, il est possible que vous remarquiez des modifications inattendues à l'élément que vous n'avez pas effectuées. Ces modifications sont sémantiquement insignifiantes et peuvent se produire pour plusieurs raisons. Par exemple :
    • Modification manuelle du fichier de définition d’élément. Ces modifications sont valides, mais peuvent être différentes de celles effectuées par le biais des éditeurs. Par exemple, si vous renommez une colonne de modèle sémantique dans Git et que vous importez ce changement dans l’espace de travail, la prochaine fois que vous validerez les changements apportés au modèle sémantique, le fichier bim sera inscrit comme modifié et la colonne modifiée sera envoyée à l’arrière du groupe columns. Cela est dû au fait que le moteur AS qui génère les fichiers bim envoie (push) les colonnes renommées à la fin du tableau. Cette modification n’affecte pas le fonctionnement de l’élément.
    • Validation d’un fichier qui utilise des sauts de ligne CRLF. Le service utilise des sauts de ligne LF. Si vous aviez des fichiers d’élément dans le référentiel Git avec des sauts de ligne CRLF, lorsque vous commitez à partir du service, ces fichiers sont modifiés pour utiliser LF. Par exemple, si vous ouvrez un rapport dans le bureau, enregistrez le fichier projet (.pbip) et chargez-le sur Git à l’aide de CRLF.
  • L’actualisation d’un modèle sémantique en utilisant l’API Actualisation améliorée provoque une différence Git après chaque actualisation.

Contenu connexe

  • Last updated on