Intégration de Git pour le développement d’entrepôt Fabric

S’applique à : ✅ Entrepôt dans Microsoft Fabric

Cet article explique les avantages de développer et déployer Fabric Data Warehouse grâce à l'intégration Git intégrée de Fabric.

Important

Cette fonctionnalité est en version préliminaire.

En utilisant l’intégration Git dans Fabric, les équipes peuvent appliquer des pratiques modernes de contrôle de version au développement d’entrepôt. Les développeurs peuvent isoler les changements dans les branches, suivre l’évolution du schéma via des commits, collaborer via pull requests, et synchroniser les mises à jour entre les dépôts Git et les espaces de travail Fabric.

Les scénarios classiques sont les suivants :

  • Développement sécurisé des modifications de schéma dans les branches et les espaces de travail
  • Versionnement des objets d’entrepôt dans Git
  • Collaborer entre plusieurs branches et espaces de travail
  • Promouvoir des changements validés entre branches
  • Maintenir les éléments de l’espace de travail (entrepôt et autres) alignés avec la source de vérité Git

Pour maintenir la cohérence, la traçabilité et la fiabilité tout au long des cycles de vie du développement de l’entrepôt, il faut comprendre ces flux de travail.

Schéma du cycle de vie de développement de l’intégration Git de Fabric Warehouse.

Lorsque vous connectez un espace de travail Fabric Data Warehouse à Git, vous commencez les définitions d’entrepôt en tant que projet de base de données. Ce projet devient la représentation faisant autorité du schéma d’entrepôt dans le contrôle de version et sert de base aux activités de développement en cours. Dans l’explorateur de contrôle de version, le schéma apparaît sous forme de fichiers individuels .sql .

Capture d’écran du schéma d’un entrepôt dans l’explorateur de contrôle de version.

En utilisant Fabric’intégration Git et Fabric Data Warehouse, vous pouvez :

Comparison

Pendant ce processus de synchronisation, Fabric utilise un déploiement incrémental de schéma basé sur DacFx pour appliquer des changements. Cette approche applique uniquement les différences de schéma pertinentes à l’entrepôt, plutôt que de mettre à jour l’ensemble de la définition de l’entrepôt.

L’extraction incrémentale aide à réduire les churnes inutiles dans le contrôle de version, à maintenir des différences de schéma plus propres entre les branches et à soutenir des flux de travail efficaces de branchement et de fusion. Parce que le processus d’extraction est conscient du schéma, il permet également une comparaison et une validation fiables entre l’état de l’espace de travail et les définitions suivies par Git.

La standardisation de la manière dont les schémas d’entrepôt sont extraits et stockés améliore la cohérence entre les environnements de développement. Les définitions de schéma restent stables entre les branches, les différences reflètent plus fidèlement les changements intentionnels de développement, et le contrôle de version devient une base fiable pour le déploiement, la collaboration et la gestion du cycle de vie.

Le XMLA.json fichier lui-même est exclu lors des flux d’intégration Git. Fabric exclut ce fichier des commits et mises à jour afin que les métadonnées sémantiques model par défaut ne soient pas stockées involontairement dans Git. Lors de la synchronisation d’un espace de travail depuis Git, cela XMLA.json est ignoré, ce qui aide à éviter les conflits, les écrasements involontaires et le bruit lors du changement de branchement ou des mises à jour depuis Git.

Limitations dans le contrôle de code source

Les fonctionnalités de sécurité SQL telles que les permissions nécessitent une approche d’exportation et de migration distincte.

  • Les dépendances inter-items entre entrepôts et terminaux d’analytique SQL ne sont actuellement pas prises en charge dans les flux de travail de développement. En conséquence, les scénarios qui reposent sur des changements coordonnés entre ces éléments peuvent ne pas fonctionner de manière fiable.

  • Les commits sélectifs au niveau de l’entrepôt ne sont pas actuellement pris en charge. Les modifications sont engagées au niveau de l’article de l’entrepôt plutôt qu’à des niveaux plus fins.

  • Le support du contrôle de version pour les endpoints SQL Analytics n’est pas actuellement disponible. Cette limitation peut limiter la gestion du cycle de vie de bout en bout lorsque les solutions couvrent à la fois des entrepôts et des terminaux d’analyse SQL.

Limitations de l’intégration Git

  • Lorsque deux articles d’entrepôt ou plus se référencent, ils forment une dépendance cyclique. Le système détecte cette référence circulaire lors des opérations de branchement ou de synchronisation Git-à-workspace, ce qui provoque l’échec de ces opérations. Évitez les dépendances cycliques entre les éléments.
  • Actuellement, ne créez pas de dataflow Gen2 avec une destination de sortie vers l’entrepôt. Un nouvel élément nommé DataflowsStagingWarehouse apparaît dans le référentiel et bloque la validation et la mise à jour à partir de Git.
  • Les dépendances entre les éléments, le séquencement d’éléments et les lacunes de synchronisation entre le point de terminaison d’analytique SQL et l’entrepôt ont un impact sur la « branchement vers un espace de travail nouveau ou existant » et le « basculement vers une autre branche » pendant le développement et l’intégration continue.
  • Si un objet référence un autre objet dans le même entrepôt en utilisant un nommage en trois parties (database.schema.object), l’validation ou la mise à jour depuis Git peut échouer. Pour plus d’informations et une solution de contournement, voir Références aux objets propres de l’entrepôt en utilisant un nom en trois parties.
  • Si vous modifiez une colonne qui a défini IDENTITY , le commit ou la mise à jour depuis Git peut échouer tant que ce n’est IDENTITY_INSERT pas activé pour la table.
  • Si le dépôt contient un .sqlproj fichier qui épingle une ancienne Microsoft.Build.Sql version du SDK, le commit ou la mise à jour depuis Git peut échouer car l'ancien SDK ne reconnaît pas la syntaxe d'entrepôt plus récente comme IDENTITY les colonnes et CLUSTER BY. Pour plus d’informations et une solution de contournement, voir .sqlproj obsolète dans le dépôt Git.
  • Si un objet fait référence à deux tables ou plus dans un autre entrepôt sans qualifier chaque colonne par alias, l’validation ou la mise à jour depuis Git peut échouer. Pour plus d’informations et une solution de contournement, voir Colonnes non qualifiées dans les objets qui font référence à deux tables ou plus dans un autre entrepôt.
  • Si vos scripts font référence à deux objets différents ou plus dans le même schéma d’un autre entrepôt et épelent le nom du schéma avec une capitalisation incohérente, le commit ou la mise à jour depuis Git peut échouer. Pour plus d’informations et une solution de contournement, voir Capitalisation incohérente des noms de schéma.
  • Des erreurs de colonne ambiguës dont la liste de candidats contient un :: séparateur peuvent survenir lors d’un commit ou d’une mise à jour depuis Git, même lorsqu’il n’y a pas de véritable ambiguïté. Pour plus d’informations et de solutions de contournement, voir Erreurs de colonne ambiguës avec des objets candidats dupliqués.

Scénarios non pris en charge

Les flux de travail CI/CD suivants ne sont pas officiellement pris en charge lorsque les entrepôts dans différents espaces de travail ont des classements différents. Même si ces opérations peuvent réussir sans erreur, elles peuvent entraîner des erreurs de métadonnées.

Dans tous ces scénarios, si une incompatibilité de classement se produit, utilisez le script Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py dans la boîte à outils Fabric sur le référentiel GitHub pour mettre à jour le classement du jeu de données (TMSL) afin qu'il corresponde à celui de l'entrepôt.

Scénario Description Risque
Pipelines de déploiement La promotion du contenu de l’entrepôt via des étapes de pipeline (par exemple, Dev → Test → Prod) où l’entrepôt cible a été créé avec un classement différent de la source n’est pas pris en charge. Le déploiement peut réussir, mais le classement du jeu de données n’est pas mis à jour pour correspondre au classement de l’entrepôt cible.
Extension dans un espace de travail nouveau ou existant L'utilisation de l'intégration de Git pour créer une branche à partir d’un espace de travail existant vers un nouvel espace de travail ou un espace de travail existant où l’entrepôt a une collation différente n’est pas prise en charge. Le contenu de l’entrepôt est synchronisé, mais les métadonnées de classement ne sont pas rapprochées.
Changement de branches sur un espace de travail Le passage à une branche associée à un entrepôt d’un autre classement sur un espace de travail connecté à Git n’est pas pris en charge. Le contenu synchronisé pourrait comporter ses propres hypothèses de classement qui ne correspondent pas à l’entrepôt actuel.
Fusion des modifications entre les espaces de travail via des branches La fusion de branches Git entre les espaces de travail où les entrepôts ont des classements différents n’est pas prise en charge. La fusion peut réussir au niveau Git, mais le classement du jeu de données résultant ne reflète pas le classement de l’entrepôt cible.

Étape suivante

Utilisez l’intégration Git pour le développement et le déploiement d’entrepôt

Contenu connexe

  • Last updated on