Partager via

Introduction à l’intégration Git (aperçu)

  • Article

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

Important

Cette fonctionnalité est en version préliminaire.

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. Actuellement, en préversion, seuls quelques éléments sont pris en charge, mais la liste des éléments pris en charge s’allonge.

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 sont pris en charge à l’heure actuelle :

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.
  • 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.
  • 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.
  • La taille d’un commit est limitée à 125 Mo.

Limites GitHub Enterprise

Certains paramètres GitHub Enterprise ne sont pas pris en charge. Par exemple :

  • Liste verte d’adresses IP
  • Réseau privé

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.
  • La structure de dossiers de l’espace de travail n’est pas reflétée dans le référentiel Git. Les éléments de l’espace de travail dans les dossiers sont exportés vers le répertoire racine.

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.
  • Vous ne pouvez pas télécharger un rapport/jeu de données en tant que .pbix à partir du service après leur déploiement avec Intégration Git.
  • Lors du nommage du dossier dans Git, ll’ID logique (GUID) est ajouté en tant que préfixe avant le type si le nom d’affichage de l’élément :
    • Comporte plus de 256 caractères
    • Se termine par . ou un espace
    • Contient l’un des caractères suivants : " / : < > \ * ? |

Limitations de branchement

  • Le branchement nécessite des autorisations répertorié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.
  • Lors de l’extraction de branche, un nouvel espace de travail est créé et les paramètres de l’espace de travail d’origine ne sont pas copiés. Ajustez les paramètres ou définitions pour vous assurer que le nouvel espace de travail répond aux stratégies de votre organisation.
  • 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.

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 les éléments qui ont des étiquettes de confidentialité sans étiquette de confidentialité, demandez de l’aide à votre 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 et que vous n’avez pas effectuées apportées à l’élément. 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 validez à partir du service, ces fichiers sont modifiés en LF. Par exemple, si vous ouvrez un rapport dans le bureau, enregistrez le projet .pbip et chargez-le sur Git avec 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