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 .

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.
  • Le compte Azure DevOps doit être inscrit auprès du même utilisateur qui utilise l’espace de travail Fabric.
  • Azure DevOps n’est pas pris en charge si Activer la validation de la stratégie d’accès conditionnel IP est activé.
  • L’admin client doit activer les exportations intergéographiques si l’espace de travail et le référentiel Git se trouvent dans deux régions géographiques différentes.
  • 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 taille d’un commit est limitée à 125 Mo.

Limites GitHub Enterprise

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

  • GitHub Enterprise Cloud avec résidence des données (ghe.com)
  • 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

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.

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 PowerBI 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