Questions fréquemment posées sur les outils de gestion du cycle de vie Fabric

La gestion du cycle de vie comporte deux parties, l'intégration et le déploiement. Pour comprendre ce qu’est l’intégration dans Fabric, reportez-vous à la vue d’ensemble de l’intégration Git. Pour comprendre ce que sont les pipelines de déploiement dans Fabric, reportez-vous à la vue d’ensemble des pipelines de déploiement .

Pour obtenir une brève explication de l’intégration Git, consultez la vue d’ensemble de l’intégration Git. Une réponse multiligne ou mise en forme à la question. Utilisez le formatage Markdown de votre choix, à condition de maintenir l’indentation des lignes après les caractères « | ».

Pour obtenir une brève explication des pipelines de déploiement, consultez la vue d’ensemble des pipelines de déploiement.

Pour plus d’informations sur les licences, consultez Fabric licences.

Tous les espaces de travail doivent être affectés à une licence Fabric. Cependant, vous pouvez utiliser différents types de capacité pour différents espaces de travail.

Pour plus d'informations sur les types de capacité, voir Capacité et SKU.

Le modèle d’autorisations de pipelines de déploiement est décrit dans la section Autorisations.

Pour configurer des règles de déploiement dans des pipelines de déploiement, vous devez être le propriétaire du modèle sémantique.

Si la capacité de l’espace de travail se trouve dans un emplacement géographique alors que le dépôt Azure DevOps se trouve dans un autre emplacement, l’administrateur Fabric peut décider s’il faut activer les exportations intergéographiques. Pour plus d’informations, consultez Les utilisateurs peuvent exporter des éléments vers des référentiels Git dans d’autres emplacements géographiques.

Démarrez avec l’intégration Git en utilisant les instructions de démarrage.

Il peut y avoir plusieurs raisons pour lesquelles un élément a été supprimé de l'espace de travail.

• Si l'élément n'a pas été validé et que vous l'avez sélectionné dans une action d'annulation, l'élément est supprimé de l'espace de travail.
• Si l'élément a été validé, il peut être supprimé si vous changez de branche et que l'élément n'existe pas dans la nouvelle branche.

Les considérations suivantes sont importantes à garder à l’esprit :

• Limitations des règles de déploiement
• Sources de données prises en charge pour les règles de flux de données et de modèles sémantiques
• Actualisation incrémentielle
• Automatisation

Vous pouvez soit attribuer un espace de travail à votre pipeline et le déployer sur l'ensemble du pipeline, soit attribuer un espace de travail différent à chaque étape du pipeline. Pour plus d’informations, consultez Attribuer un espace de travail à un pipeline de déploiement.

Les jeux de données qui utilisent le mode de connectivité DirectQuery ou Composite et qui ont des tables de variation ou de date/heure automatiques ne sont pas pris en charge dans les pipelines de déploiement. Si votre déploiement échoue et que vous pensez que c’est parce que vous avez un jeu de données avec une table de variation, vous pouvez rechercher la propriété variations dans les colonnes de votre table. Vous pouvez utiliser l’une des méthodes suivantes pour modifier votre modèle sémantique afin qu’il fonctionne dans les pipelines de déploiement.

• Dans votre jeu de données, au lieu d’utiliser le mode DirectQuery ou Composite, utilisez le mode importation.

• Supprimez les tables date/heure automatique de votre modèle sémantique. Si nécessaire, supprimez toutes les variantes restantes de toutes les colonnes de vos tables. La suppression d’une variante peut invalider les mesures créées par l’utilisateur, les colonnes calculées et les tables calculées. Utilisez cette méthode uniquement si vous comprenez comment fonctionne votre modèle de modèle sémantique, car cela peut entraîner une altération des données dans vos visuels.

Lorsque vous épinglez une vignette à un tableau de bord, si la vignette s’appuie sur un élément non pris en charge (aucun élément de cette liste n’est non pris en charge) ou sur un élément que vous n’avez pas les autorisations de déploiement, après le déploiement du tableau de bord, la vignette ne s’affiche pas. Par exemple, si vous créez une mosaïque à partir d'un rapport qui s'appuie sur un modèle sémantique dont vous n'êtes pas administrateur, vous recevez un avertissement d’erreur lors du déploiement du rapport. Cependant, lors du déploiement du tableau de bord avec le mosaïque, vous n'avez pas de message d'erreur, le déploiement réussira, mais le mosaïque n'affichera aucune information.

Pour une brève explication des plans de déploiement, voir l’aperçu du plan de déploiement.

Le type d’élément du plan de déploiement n’apparaît qu’après qu’un administrateur Fabric active le paramètre du locataire. Dans le portail d’administration, sous Paramètres du locataire>Microsoft Fabric, activez Les utilisateurs peuvent créer des éléments de plan de déploiement (préversion), définissez Appliquer à sur l’ensemble de l’organisation ou sur un groupe de sécurité, puis sélectionnez Appliquer.

Tant que ce paramètre n’est pas activé, le type d’objet reste caché dans chaque espace de travail.

Le déploiement revient à son comportement par défaut. Les éléments sont déployés sans ordre déclaré et sans actions pré-déploiement ou post-déploiement. Toute dépendance que le plan protégeait, comme une vue d’entrepôt de données qui lit une table de lakehouse alimentée par un notebook, échoue de nouveau.

Un plan correctement ordonné déploie les métadonnées des items dans l’ordre que vous déclarez, mais déployer un lakehouse ne met pas de lignes dans ses tableaux. Une vue d’entrepôt qui lit une table d’un lakehouse ne peut pas être liée, à moins qu’un notebook ou un pipeline de données n’ait créé cette table au préalable. Ajoutez une action post-déploiement entre la maison du lac et l’entrepôt qui produit la table. Une action signale sa fin lorsqu’elle se termine, et non lorsque les services qu’elle alimente ont rattrapé leur retard, donc placez toute vérification de préparation dans la dernière cellule du carnet, ou la dernière activité du pipeline de données. Pour un exemple, voir exemples de plans de déploiement.

Le champ lakehouse par défaut d’un notebook contient des ID qui pointent vers un lakehouse spécifique d’un espace de travail spécifique. Après que le notebook arrive dans un nouvel espace de travail via Git, ces identifiants peuvent toujours pointer vers l’espace de travail d’origine. Soit définissez le lakehouse par défaut pour l’environnement cible dans les paramètres du notebook avant l’exécution, soit laissez le notebook déterminer son lakehouse au moment de l’exécution. Pour plus d’informations, consultez Le contrôle de code source et le déploiement de Notebook.

La sortie de la run est visible depuis le déploiement dans le portail. Les exécutions d’actions renvoient vers l’historique d’exécution de l’élément concerné pour consulter les journaux ainsi que les détails des étapes.

Un déploiement raté ne revient pas en arrière sur les déploiements d’éléments terminés ni sur les modifications apportées par des actions. Pour obtenir des instructions de récupération, voir Le déploiement s’est arrêté en cours de route.

Pas directement. Déclenche Update depuis Git depuis un planificateur externe tel qu’Azure Pipelines ou GitHub Actions, et le plan joint s’exécute dans le cadre de ce déploiement.

Oui, si le pipeline pilote le déploiement via une API Fabric qui supporte l’attachement d’un plan, comme l’API Git Sync, l’API de déploiement des pipelines de déploiement ou l’API d’importation par lots. Un déploiement piloté par la CLI Fabric, le fournisseur Terraform pour Fabric, ou la bibliothèque Python fabric-cicd ne peut pas joindre un plan.

Non. Un plan régit les éléments d’un déploiement et les actions qui les entourent. La configuration au niveau de l’espace de travail ne fait pas partie d’un déploiement, donc des paramètres comme l’identité de l’espace de travail, les paramètres Spark et la connexion Git ne sont ni créés ni mis à jour par un plan.

Configurez-les dans l’espace de travail cible avant de déployer. Un élément qui dépend de la configuration au niveau de l’espace de travail, comme un notebook qui s’authentifie via l’identité de l’espace de travail, échoue à l’exécution si l’espace de travail cible n’est pas configuré de la même manière que la source.

Non. Un plan de déploiement suit le modèle standard de l’espace de travail Fabric. Pour plus d’informations, consultez les autorisations du plan de déploiement.

Le propriétaire d’un rapport paginé déployé est l’utilisateur qui a déployé le rapport. Lorsque vous déployez un rapport paginé pour la première fois, vous devenez le propriétaire du rapport.

Si vous déployez un rapport paginé dans une étape qui contient déjà une copie de ce rapport paginé, vous écrasez le rapport précédent et devenez son propriétaire, au lieu du propriétaire précédent. Dans de tels cas, vous avez besoin d'informations d'identification pour la source de données sous-jacente, afin que les données puissent être utilisées dans le rapport paginé.

Les sous-rapports des rapports paginés sont conservés dans le même dossier que celui qui contient votre rapport paginé. Pour éviter les problèmes de rendu, lorsque vous utilisez la copie sélective pour copier un rapport paginé avec des sous-rapports, sélectionnez le rapport parent et les sous-rapports.

Vous pouvez créer des règles de rapport paginé si vous souhaitez orienter le rapport paginé vers le modèle sémantique à la même étape. Lorsque vous créez une règle de déploiement pour un rapport paginé, vous devez sélectionner une base de données et un serveur.

Si vous définissez une règle de déploiement pour un rapport paginé qui n'a pas de modèle sémantique Fabric, car la source de données cible est externe, vous devez spécifier le serveur et la base de données.

Toutefois, les rapports paginés qui utilisent un modèle sémantique Fabric utilisent un modèle sémantique interne. Dans ce cas, vous ne pouvez pas vous appuyer sur le nom de la source de données pour identifier le modèle sémantique Fabric auquel vous vous connectez. Le nom de la source de données ne change pas lorsque vous le mettez à jour à la phase cible, en créant une règle de source de données ou en appelant l’API de mise à jour de la source de données. Lorsque vous définissez une règle de déploiement, vous devez conserver le format de la base de données et remplacer l’ID d’objet du modèle sémantique dans le champ de base de données. Comme le modèle sémantique est interne, le serveur reste le même.

• Database - Le format de la base de données pour un rapport paginé avec le modèle sémantique Fabric est sobe_wowvirtualserver-<dataset ID>. Par exemple : sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Remplace le <dataset ID> par l’ID de votre jeu de données. Vous pouvez récupérer l’ID de jeu de données à partir de l’URL, en sélectionnant le GUID qui vient après datasets/ et avant la barre oblique suivante.

  Une capture d'écran de l'ID du jeu de données tel qu’il apparaît dans une URL Fabric.

• Serveur : serveur qui héberge votre base de données. Conservez le serveur existant tel quel.

Après un déploiement, si vous téléchargez le RDL du rapport paginé, il se peut qu’il ne soit pas mis à jour avec la dernière version que vous pouvez voir dans service Power BI.

Lorsque vous disposez d’un flux de données qui contient des modèles sémantiques configurés avec une actualisation incrémentielle, la stratégie d’actualisation n’est pas copiée ou écrasée pendant le déploiement. Après avoir déployé un flux de données qui inclut un modèle sémantique avec une actualisation incrémentielle sur une étape qui n’inclut pas ce flux de données, et si vous avez une stratégie d’actualisation, vous devez la reconfigurer à l’étape cible. Si vous déployez un flux de données avec actualisation incrémentielle vers un environnement où il réside déjà, la stratégie d'actualisation incrémentielle n'est pas copiée. Dans de tels cas, si vous souhaitez mettre à jour la stratégie d'actualisation à l'étape cible, vous devez le faire manuellement.

Contenu connexe

• Démarrer avec l’intégration Git
• Commencez avec les pipelines de déploiement