Planification de la mise en œuvre de Power BI : Développer le contenu et gérer les changements

Notes

Cet article fait partie de la série d’articles sur la planification de l’implémentation de Power BI. Cette série se concentre principalement sur l’expérience Power BI au sein de Microsoft Fabric. Pour une introduction à la série, consultez Planification de la mise en œuvre de Power BI.

Cet article vous aide à développer du contenu et à gérer les modifications dans le cadre de la gestion de cycle de vie du contenu. Il est principalement destiné à :

• Centre d’excellence (COE) et équipes BI : les équipes qui sont également responsables de la supervision de Power BI au sein de l’organisation. Ces équipes comprennent des décideurs qui décident de la manière de gérer le cycle de vie du contenu de Power BI. Ces équipes peuvent également inclure des rôles tels que les gestionnaires de versions, qui gèrent le cycle de vie des versions de contenu, ou le s ingénieurs qui créent et gèrent les composants nécessaires pour utiliser et soutenir efficacement la gestion de cycle de vie.
• Créateurs de contenu et propriétaires de contenu : Utilisateurs qui créent du contenu, qu’ils souhaitent publier sur le portail Fabric pour partager avec d’autres personnes. Ces personnes sont responsables de la gestion de cycle de vie du contenu Power BI qu’elles créent.

La gestion de cycle de vie est l’ensemble des processus et des pratiques que vous utilisez pour gérer le contenu depuis sa création jusqu’à son retrait éventuel. Dans la première étape de la gestion de cycle de vie, vous planifiez et concevez du contenu, qui implique planification de la solution et prendre des décisions clés qui affectent votre approche de la gestion de cycle de vie. Dans la deuxième étape, vous développez du contenu et gérez les modifications.

Il est important de gérer les changements de contenu au cours de son cycle de vie pour garantir une collaboration efficace entre les créateurs de contenu et une diffusion stable et cohérente du contenu aux consommateurs.

L’image suivante illustre le cycle de vie du contenu Power BI, en mettant l’accent sur la deuxième étape, au cours de laquelle vous développez le contenu et gérez les modifications.

Notes

Pour obtenir une vue d’ensemble de la gestion de cycle de vie du contenu, consultez le premier article de cette série.

Conseil

Cet article se concentre sur les décisions et considérations clés qui vous aideront à développer le contenu et à gérer les changements tout au long de son cycle de vie. Pour plus d’informations sur la manière de développer le contenu et de gérer les modifications, voir :

• Qu’est-ce que la gestion de cycle de vie dans Microsoft Fabric ? : Cet article fournit une introduction technique et un didacticiel aux pipelines d’intégration et de déploiement Git Fabric.
• bonnes pratiques de gestion de cycle de vie : Cet article contient des conseils pratiques et des conseils sur l’utilisation des caractéristiques de gestion de cycle de vie de Fabric et de Power BI pour développer du contenu et gérer les modifications.
• l’intégration de OneDrive et SharePoint Power BI Desktop : Cet article contient une vue d’ensemble des options permettant d’utiliser et de stocker des fichiers enregistrés dans OneDrive Entreprise et Scolaire ou SharePoint lorsque vous effectuez un contrôle de version avec des fichiers .pbix.
• Bien démarrer avec Git dans Azure Repos : Cette série d’articles contient des conseils pratiques, des didacticiels et des conseils pour effectuer le contrôle de code source à l’aide d’un référentiel Git dans Azure Repos.

Les créateurs et propriétaires de contenu doivent gérer les modifications de contenu à l’aide de contrôle de version. Le contrôle de version consiste à gérer les modifications apportées aux fichiers ou au code dans un référentiel central. Cette pratique facilite la collaboration et la gestion du contenu plus efficaces.

Les autres avantages du contrôle de version incluent la possibilité de :

• Fusionnez les modifications de plusieurs créateurs de contenu et gérez les conflits de fusion.
• Identifiez le contenu modifié et ce qui a changé dans ce contenu.
• Lier des modifications de contenu à des éléments de travail spécifiques.
• Regroupez les modifications apportées aux versions distinctes avec l’historique des versions.
• Restaurez les modifications ou les versions entières du contenu.

Conseil

Nous vous recommandons d’utiliser le contrôle des versions pour tous les contenus que vous créez, dans la mesure du possible. L’utilisation du contrôle des versions présente des avantages considérables tant pour les créateurs de contenu que pour les consommateurs et réduit le risque d’interruption due à la perte de fichiers ou à l’impossibilité de restaurer des modifications.

La première étape de la mise en place du contrôle des versions consiste à décider de la manière dont vous développerez le contenu.

Décider comment développer du contenu

Selon la façon dont vous créez du contenu, vous prendrez différentes décisions sur la façon de la gérer. Par exemple, pour les rapports Power BI et les modèles sémantiques, un fichier Power BI Desktop (.pbix) a moins d’options de contrôle de version que le format de projet Power BI Desktop (.pbip). En effet, un fichier .pbix est un format binaire, alors que le format .pbip contient un contenu textuel lisible par l’homme et des métadonnées. Le fait d’avoir du contenu et des métadonnées lisibles par l’homme permet un suivi plus facile des modifications de modèle et de rapport à l’aide de contrôle de code source. Le contrôle de code source est lorsque vous affichez et gérez les modifications dans contenu de son code et de ses métadonnées.

Conseil

Lorsque vous développez des modèles sémantiques et des rapports à l’aide de Power BI Desktop, nous vous recommandons d’utiliser des fichiers .pbip plutôt que des fichiers .pbix. Lorsque vous développez des modèles sémantiques à l’aide d’outils XMLA, nous vous recommandons d’utiliser le format Tabular Model Definition Language (TMDL) au lieu des fichiers .bim.

Les formats .pbip et TMDL facilitent le suivi et la fusion des modifications au niveau des objets. Cela signifie que vous pouvez visualiser et gérer les modifications apportées à des objets individuels, tels que des mesures DAX ou des tableaux.

Power BI Desktop

Vous pouvez utiliser Power BI Desktop pour créer des modèles sémantiques ou des rapports, que vous pouvez enregistrer sous forme de fichiers .pbix ou .pbip. Il existe d’autres fichiers de contenu personnalisés que vous pouvez également utiliser lorsque vous utilisez Power BI Desktop.Lorsque vous utilisez Power BI Desktop pour créer du contenu, vous devez prendre certaines décisions clés :

• Format de fichier à utiliser : Vous pouvez enregistrer du contenu sous forme de fichiers .pbix ou .pbip. Par exemple, l’intégration Git nécessite l’utilisation de fichiers .pbip, les créateurs en libre-service peuvent trouver les fichiers .pbix plus simples à gérer et à maintenir dans Teams, SharePoint ou OneDrive.
• Comment gérer du contenu personnalisé : Vous pouvez ajouter des thèmes, des visuels personnalisés ou des images aux fichiers Power BI Desktop, ce qui peut nécessiter des considérations distinctes pour la gestion de cycle de vie. Par exemple, lorsque les créateurs de contenu créent leurs propres visuels personnalisés, ils doivent enregistrer et gérer la définition du visuel dans un fichier distinct.
• Comment gérer les fonctionnalités en préversion : Vous pouvez choisir d’afficher une préversion des fonctionnalités ou des paramètres dans Power BI Desktop, ce qui modifie le contenu et la façon dont vous l’utiliserez. Par exemple, vous pouvez prendre des mesures supplémentaires pour valider le contenu qui utilise des fonctionnalités en préversion.

Création web

Certains contenus, tels que les flux de données, les tableaux de bord et les cartes de performance, ne peuvent être créés que dans le portail Fabric. Vous pouvez également créer ou modifier certains contenus, tels que les modèles sémantiques, les rapports et les rapports paginés, dans le portail Fabric ou à l’aide d’outils locaux. Lorsque vous créez du contenu à l’aide de la création Web, vous devez prendre certaines décisions clés :

• Comment gérer les modifications : Vous pouvez apporter des modifications à de nombreux types d’éléments à l’aide de la création web, mais ces modifications peuvent être enregistrées instantanément, en remplaçant les versions précédentes. Par exemple, si vous collaborez avec d’autres personnes, vous pouvez éviter la création web des articles partagés et travailler plutôt sur votre propre copie.
• Comment récupérer des sauvegardes de contenu : Vous pouvez créer du contenu comme des rapports ou des modèles sémantiques à l’aide de la création web, mais ces éléments ne peuvent pas être téléchargés dans des fichiers .pbix locaux. Par exemple, vous pouvez choisir de sauvegarder ce contenu en récupérant et en stockant ses métadonnées.

Conseil

Lorsque vous développez des flux de données et des cartes de performance, nous vous recommandons de récupérer les définitions des éléments afin de gérer les modifications et de conserver une copie de sauvegarde. Vous pouvez automatiser la récupération de flux de données et de carte de performance à l’aide des API REST Fabric. Plus précisément, vous pouvez utiliser les Obtenir des de flux de données et obtenir des cartes de performance points de terminaison, respectivement.

Attention

Certains contenus—comme les—tableaux de bord n’ont pas la possibilité de récupérer une définition. Pour ce contenu, vous ne pouvez pas facilement suivre les modifications ou récupérer une sauvegarde.

Autres outils

Vous pouvez utiliser d’autres outils pour créer ou gérer certains types de contenu. Ces outils peuvent apporter des avantages supplémentaires, mieux s’adapter à votre flux de travail ou être nécessaires pour gérer des caractéristiques ou des types de contenu spécifiques. Vous pouvez utiliser d’autres outils Microsoft ou des outils tiers pour créer et gérer du contenu. D’autres outils que vous pouvez utiliser pour créer ou gérer du contenu sont les suivants.

• Visual Studio ou Visual Studio Code : un environnement de développement intégré pour les développeurs afin de créer et de gérer des modèles sémantiques ou des notebooks Fabric. Avec Visual Studio et Visual Studio Code, les développeurs peuvent également effectuer une gestion du contrôle de code source (SCM) en commitant et en transmettant des modifications locales à un référentiel distant.
• Éditeur tabulaire : un outil tiers pour développer et gérer des modèles sémantiques.
• Excel : outil client pour les tableaux croisés dynamiques et les tables connectées actives qui fonctionnent avec un modèle sémantique.
• Power BI Report Builder : Une application de bureau pour créer des fichiers de rapports paginés (.rdl).

Lorsque vous créez du contenu à l’aide d’autres outils, vous devez prendre certaines décisions importantes :

• Comment gérer les licences : Autres outils peuvent nécessiter des licences supplémentaires que vous devez gérer.
• Comment publier du contenu : Autres outils peuvent nécessiter des étapes supplémentaires pour publier du contenu, par exemple à l’aide de points de terminaison XMLA ou des API REST Power BI.

Une fois que vous avez décidé de la manière dont vous allez créer le contenu, vous devez choisir l’endroit où vous allez le publier et le tester pendant que vous le développez.

Décidez de la manière dont vous allez configurer et utiliser les espaces de travail

Lorsque vous développez du contenu, vous devez utiliser plusieurs espaces de travail (ou étapes) pour séparer le contenu de production utilisé par l’organisation du contenu en cours de développement ou de validation. L’utilisation d’espaces de travail distincts pour votre contenu présente plusieurs avantages :

• Vous pouvez développer et tester du contenu sans affecter le contenu en cours d’utilisation. Cela permet d’éviter les changements susceptibles de perturber involontairement le contenu en cours de production.
• Vous pouvez utiliser des ressources distinctes pour développer et tester du contenu, comme l’utilisation de passerelles de données distinctes ou capacités Fabric. Cela permet d’éviter que les ressources utilisées pour le développement et les tests ne perturbent les charges de travail de la production, entraînant une lenteur dans l’actualisation des données ou des rapports.
• Vous pouvez créer un processus plus structuré pour développer, tester et publier du contenu en disposant d’environnements distincts pour chacune de ces étapes. Cela vous aide à améliorer la productivité.

Dans Fabric et Power BI, nous vous recommandons d’utiliser des espaces de travail Fabric distincts, comme décrit dans le au niveau du locataire et articles de planification au niveau de l’espace de travail.

Important

L’utilisation d’environnements distincts est une étape essentielle pour garantir le succès de votre approche de la gestion de cycle de vie du contenu.

Il existe plusieurs façons d’utiliser les espaces de travail Fabric pour séparer les environnements. En général, en plus de votre environnement local, vous utilisez deux espaces de travail ou plus pour gérer le contenu pendant son cycle de vie.

Répondez aux questions suivantes en planifiant l’utilisation d’espaces de travail distincts tout au long du cycle de vie de ce contenu :

• De combien d’espaces de travail avez-vous besoin ?
• Allez-vous séparer des espaces de travail par type d’élément ?
• Qui aura accès à chaque espace de travail ?
• Les espaces de travail appartiennent-ils à un pipeline de déploiement Fabric, ou orchestrez-vous le déploiement à l’aide d’autres approches, telles que l’utilisation d’ Azure Pipelines ?
• Comment allez-vous gérer publication inter-espaces de travail ? Par exemple, devez-vous vous assurer que les rapports d’un espace de travail de test pour les rapports se connectent aux modèles sémantiques d’un espace de travail de test distinct pour les éléments de données ?
• Devez-vous également utiliser des ressources de support distinctes pour les éléments dans les espaces de travail de production, comme un cluster distinct de passerelle de données locale ?

Les sections suivantes fournissent une vue d’ensemble des différentes approches que vous pouvez adopter pour séparer les espaces de travail afin de faciliter la gestion de cycle de vie.

Notes

Les sections suivantes expliquent comment configurer et utiliser des espaces de travail distincts. Vous pouvez déployer du contenu dans ces espaces de travail en utilisant l’une des quatre approches suivantes :

• Publier à partir de Power BI Desktop.
• Déployer du contenu à partir d’un autre espace de travail en utilisant les pipelines de déploiement Fabric.
• Synchronisation du contenu à partir d’un référentiel Git distant à l’aide de l’intégration Git.
• Déployer du contenu de manière programmatique en utilisant les API REST Fabric, les API REST Power BI ou les points de terminaison XMLA.

Pour plus d’informations sur ces approches de déploiement de contenu, consultez Étape 4 : Déployer du contenu plus loin dans cette série.

Tester et produire des espaces de travail

Lorsque vous diffusez un contenu plus simple qui n’est pas essentiel pour l’organisation, deux espaces de travail peuvent souvent suffire. Dans ce scénario, les créateurs de contenu ont généralement une collaboration limitée sur les mêmes éléments et développent le contenu localement.

Le diagramme suivant illustre un exemple de haut niveau de l’utilisation d’environnements distincts avec un espace de travail de test et un espace de travail de production.

Le diagramme décrit les processus et composants suivants pour séparer les espaces de travail dans le cadre de cette approche.

Article	Description
	Les créateurs de contenu développent le contenu dans leur environnement local.
	Lorsqu’ils sont prêts, les créateurs de contenu publient le contenu dans un espace de travail test. Les créateurs de contenu peuvent développer du contenu qui ne peut être produit qu’avec la création web et effectuer la validation du contenu dans l’espace de travail de test.
	Lorsqu’ils sont prêts, les créateurs de contenu déploient le contenu dans un espace de travail de production. Dans l’espace de travail de production, les créateurs de contenu distribuent le contenu en publiant une application Power BI ou en partageant le contenu de l’espace de travail.

Notes

Il existe de nombreuses façons de configurer et d’utiliser des espaces de travail distincts et de déployer du contenu entre ces espaces de travail. Toutefois, nous vous recommandons de ne pas effectuer de développement local, puis de publier le contenu directement dans un espace de travail de production. Cela peut entraîner des interruptions et des erreurs évitables.

Espaces de travail de développement, de test et de production

Lorsque vous diffusez du contenu vital pour l’entreprise, vous utilisez généralement trois espaces de travail distincts ou plus. Dans ce scénario, les créateurs de contenu collaborent souvent dans un espace de travail de développement supplémentaire qui contient la dernière version de la solution.

Le diagramme suivant présente un exemple de haut niveau de l’utilisation d’environnements distincts avec un espace de travail de développement, de test et de production.

Le diagramme décrit les processus et composants suivants pour séparer les espaces de travail dans le cadre de cette approche.

Article	Description
	Les créateurs de contenu développent le contenu dans leur environnement local.
	Lorsqu’ils sont prêts, les créateurs de contenu publient le contenu dans un espace de travail de développement. Dans l’espace de travail de développement, les créateurs de contenu peuvent développer du contenu qui ne peut être produit qu’avec la création web. Les créateurs de contenu peuvent également valider le contenu dans l’espace de travail de développement.
	Lorsqu’ils sont prêts, les créateurs de contenu déploient le contenu dans un espace de travail de test. Dans l’espace de travail de test, les utilisateurs valident le contenu, soit dans l’espace de travail, soit dans une application.
	Lorsqu’ils sont prêts, les créateurs de contenu déploient le contenu dans un espace de travail de production. Dans l’espace de travail de production, les créateurs de contenu distribuent le contenu en publiant une application Power BI ou en partageant le contenu de l’espace de travail.

Notes

Vous pouvez utiliser jusqu’à dix environnements différents avec les pipelines de déploiement. Par exemple, vous pouvez souhaiter disposer d’un environnement de pré-production entre le test et la production, spécifiquement destiné à des types de validation particuliers, tels que les tests de performances.

Espace de travail privé avec intégration Git

Lorsque vous fournissez du contenu vital pour l’entreprise, chaque développeur peut également utiliser son propre espace de travail privé pour le développement. Dans ce scénario, un espace de travail privé permet aux créateurs de contenu de tester le contenu dans le portail Fabric ou d’utiliser des caractéristiques telles que l’actualisation programmée sans risquer de perturber les autres membres de l’équipe de développement. Les créateurs de contenu peuvent également développer du contenu dans le portail Fabric, tel que des flux de données. Les espaces de travail privés peuvent être un bon choix lorsque vous gérez des modifications de contenu en utilisant l’intégration Git avec Azure DevOps.

Notes

Azure DevOps est une suite de services qui s’intègrent à Power BI et Fabric pour vous aider à planifier et à orchestrer la gestion de cycle de vie du contenu. Lorsque vous utilisez Azure DevOps de cette façon, vous tirez généralement parti des services suivants :

• Azure Repos : vous permet de créer et d’utiliser un dépôt Git distant, un emplacement de stockage distant que vous utilisez pour assurer le suivi et la gestion des modifications de contenu.
• Azure Pipelines : vous permet de créer et d’utiliser un ensemble de tâches automatisées pour gérer, tester et déployer du contenu à partir d’un dépôt distant vers un espace de travail.
• Azure Test Plans : vous permet de concevoir des tests pour valider la solution et automatiser le contrôle de qualité avec Azure Pipelines.
• Azure Boards : vous permet d’utiliser des tableaux pour suivre les tâches et les plans en tant qu’éléments de travail, et de lier ou de faire référence à des éléments de travail à partir d’autres services Azure DevOps.
• Wiki Azure : les créateurs de contenu partagent des informations avec leur équipe pour comprendre la solution et y contribuer.

Le diagramme suivant présente un exemple de haut niveau de la façon dont vous pouvez utiliser des environnements séparés en utilisant un espace de travail privé avec l’intégration de Git.

Notes

Le diagramme montre des développeurs travaillant sur des branches distinctes d’une solution (branche 1 et branche 2) avant de fusionner leurs modifications dans une branche principale. Il s’agit d’une représentation simplifiée d’une stratégie de branchement git pour illustrer comment les développeurs peuvent intégrer leurs modifications à un référentiel Git distant et tirer parti de l’intégration de Git dans Fabric.

Le diagramme décrit les processus et composants suivants pour séparer les espaces de travail dans le cadre de cette approche.

Article	Description
	Chaque créateur de contenu développe du contenu dans son propre environnement local.
	Lorsqu’ils sont prêts, les créateurs de contenu engagent et poussent leurs modifications vers un référentiel distant, tel qu’un référentiel Azure Repos Git.
	Dans le référentiel Git distant, les créateurs de contenu suivent et gèrent les modifications de contenu en utilisant le contrôle de la source, et ils ramifient et fusionnent le contenu pour faciliter la collaboration.
	Les créateurs de contenu synchronisent une branche du référentiel distant avec un espace de travail privé. Après la synchronisation, les dernières modifications apportées par un créateur à la branche sont visibles dans cet espace de travail privé. Les différents créateurs de contenu travaillent sur leurs propres branches, séparées, au fur et à mesure qu’ils apportent des modifications.
	Dans les espaces de travail privés, les créateurs de contenu peuvent développer du contenu à l’aide de la création web et valider leurs propres modifications. Les modifications apportées au contenu par la création web peuvent être synchronisées avec la branche du référentiel Git lorsque le créateur de contenu valide et transfère ces modifications à partir de l’espace de travail. Les différents créateurs de contenu travaillent dans leurs propres espaces de travail privés.
	Lorsqu’ils sont prêts, les créateurs de contenu effectuent une demande de tirage (pull request) pour fusionner leurs modifications dans la branche principale de la solution.
	Après la fusion des modifications, la branche principale est synchronisée avec l’espace de travail de développement.
	Dans l’espace de travail de développement, les créateurs de contenu peuvent développer du contenu qui n’est pas pris en charge par l’intégration Fabric Git, comme les tableaux de bord. Les créateurs de contenu valident également la solution intégrée qui contient toutes les dernières modifications.
	Lorsqu’ils sont prêts, les créateurs de contenu déploient le contenu dans un espace de travail de test. Dans l’espace de travail de test, les utilisateurs effectuent des tests d’acceptation du contenu.
	Lorsqu’ils sont prêts, les créateurs de contenu déploient le contenu dans un espace de travail de production. Dans l’espace de travail de production, les créateurs de contenu distribuent le contenu en publiant une application Power BI ou en partageant le contenu de l’espace de travail.

Ressources de prise en charge pour les espaces de travail

Lorsque vous utilisez des environnements distincts, vous devez également tenir compte de l’impact sur les diverses ressources de soutien que vous utilisez dans ces environnements. En ce qui concerne ces ressources d’appui, réfléchissez à la nécessité de les répartir sur le même nombre d’étapes ou à la manière dont vous coordonnerez leur utilisation dans ces environnements.

• Passerelles : envisagez d’utiliser des clusters de passerelle de données locales distinctes et passerelles de réseau virtuel pour les charges de travail de production. Cela permet d’éviter les interruptions, mais aussi de garantir le temps de fonctionnement lorsque vous devez mettre à jour ces passerelles.
• Applications : envisagez d’avoir des applications distinctes pour les espaces de travail de test et de production. Il n’est pas possible de déployer ou de copier des applications entre les étapes. Les applications de l’espace de travail de test sont destinées à vous aider à tester le contenu et l’expérience de l’application avant de déployer les changements dans l’espace de travail de production. Les applications de l’espace de travail de production sont destinées à fournir du contenu aux utilisateurs finaux dans le cadre d’une expérience structurée.
• Azure DevOps : Si vous avez l’intention d’utiliser Azure DevOps pour collaborer et orchestrer le contrôle et le déploiement des sources, réfléchissez à la manière dont vous utiliserez les branches et Azure Pipelines pour déployer du contenu entre ces environnements. Pour plus d’informations sur l’utilisation d’Azure Pipelines pour déployer du contenu, voir Étape 4 : Déployer du contenu.

Une fois que vous avez décidé de la manière dont vous allez configurer et utiliser les espaces de travail, l’étape suivante consiste à décider de la manière dont vous allez effectuer le contrôle de version pour suivre et gérer les modifications de contenu.

Décider de la façon dont vous allez utiliser le contrôle de version

Dans Power BI, vous pouvez effectuer le contrôle de version à l’aide de SharePoint/OneDrive ou à l’aide d’un référentiel Git distant, tel que Azure Repos, qui est un composant de Azure DevOps. Dans les deux approches, vous ajoutez des fichiers de contenu locaux à un emplacement de stockage distant pour faciliter le suivi et la gestion des modifications. Nous vous recommandons d’utiliser SharePoint ou OneDrive uniquement pour des projets plus petits et plus simples, car il manque les caractéristiques et la robustesse pour prendre en charge des scénarios plus volumineux ou plus complexes.

Voici quelques considérations générales pour vous aider à configurer et à utiliser le contrôle des versions.

• Alertes : vous devez configurer des alertes lorsque d’autres utilisateurs ajoutent, suppriment ou modifient des fichiers critiques.
• Portée : Définir clairement le champ d’application de l’emplacement de stockage à distance. Idéalement, la portée de l’emplacement de stockage distant est identique à celle des espaces de travail et des applications en aval que vous utilisez pour fournir du contenu aux consommateurs.
• Accès : Vous devez configurer l’accès à l’emplacement de stockage distant en utilisant un modèle de permissions similaire à celui que vous avez configuré pour les permissions du pipeline de déploiement et les rôles de l’espace de travail. Les créateurs de contenu doivent avoir accès à l’emplacement de stockage à distance.
• Documentation : Ajouter des fichiers texte à l’emplacement de stockage distant pour décrire l’emplacement de stockage distant et son objectif, sa propriété, son accès et ses processus définis.

Les sections suivantes décrivent chaque approche et les éléments clés à prendre en compte pour choisir celle que vous devez utiliser.

Contrôle des versions à l’aide de SharePoint ou OneDrive pour le travail et l’école

SharePoint dispose d’un contrôle de version intégré pour les fichiers. Les créateurs de contenu peuvent développer des modèles sémantiques ou des rapports localement, et leurs modifications sont synchronisées avec une bibliothèque de documents SharePoint ou OneDrive for Work and School.

Conseil

Utilisez SharePoint ou OneDrive uniquement pour le contrôle de version dans des scénarios plus simples et plus petits, comme publication de contenu en libre-service. Pour les scénarios plus volumineux ou plus complexes, vous devez envisager d’effectuer contrôle de code source à l’aide d’un référentiel Git distant.

Le diagramme suivant présente une vue d’ensemble de la manière dont vous effectuez le contrôle des versions en utilisant SharePoint ou OneDrive.

Le diagramme décrit les processus et composants suivants.

Article	Description
	Les créateurs de contenu développent des modèles sémantiques et des rapports dans leur environnement local et les enregistrent sous forme de fichiers .pbix.
	Lorsqu’ils sont prêts, les créateurs de contenu enregistrent leurs modifications, qu’ils synchronisent avec une bibliothèque SharePoint ou OneDrive for Work and School distante.
	Dans la bibliothèque distante, les créateurs de contenu suivent les modifications apportées aux fichiers, ce qui facilite le contrôle des versions.
	Les créateurs de contenu peuvent lier un modèle sémantique ou un rapport publié à un fichier .pbix pour faciliter l’actualisation de OneDrive. L’actualisation OneDrive publie automatiquement les modifications de contenu toutes les heures.
	Dans l’espace de travail Fabric, les créateurs de contenu voient les modifications apportées au contenu Power BI une fois l’actualisation OneDrive terminée.

Important

Vous pouvez uniquement effectuer un contrôle de version en utilisant SharePoint ou OneDrive pour les fichiers Power BI Desktop qui contiennent des modèles sémantiques ou des rapports. Vous ne pouvez pas facilement effectuer un contrôle de version en utilisant SharePoint ou OneDrive pour d’autres types d’éléments Power BI tels que les flux de données, ou pour les types d’éléments Fabric tels que les notebooks. Pour ces autres types d’éléments, vous devez effectuer le contrôle de version en utilisant un référentiel Git distant, comme Azure Repos.

Pour résumer, les créateurs de contenu peuvent lier un modèle sémantique ou un rapport publié à un fichier .pbix stocké dans une bibliothèque SharePoint ou OneDrive For Work et School. Avec cette approche, les créateurs de contenu n’ont plus besoin de publier le modèle sémantique pour voir les changements. Au lieu de cela, les modifications sont visibles après une actualisation automatique OneDrive, qui se produit toutes les heures. Bien que pratique, cette approche est fournie avec certaines considérations, et elle ne peut pas être facilement inversée.

Bien qu’il soit facile à mettre en place et à gérer, le contrôle des versions avec SharePoint ou OneDrive a plus de limites. Par exemple, il n’est pas possible d’afficher les modifications dans le contenu, et il n’est pas également possible de comparer les versions. En outre, il n’est pas possible de configurer des processus plus sophistiqués pour gérer ces modifications (comme les demandes de branchement ou de tirage, décrites plus loin dans cet article).

Envisagez d’utiliser SharePoint ou OneDrive pour suivre et gérer les modifications dans les scénarios suivants :

• Le contenu consiste uniquement en des modèles sémantiques ou des rapports enregistrés sous forme de fichiers .pbix.
• Les utilisateurs en libre-service créent et gèrent le contenu.
• Les créateurs de contenu collaborent à l’aide de Microsoft Teams.
• Les créateurs de contenu sont inexpérimentés avec la gestion du contrôle de code source et Git.
• Les créateurs de contenu gèrent un seul élément avec une complexité et une collaboration limitées.
• Les fichiers .pbix ont une étiquette de confidentialité appliquée qui chiffre leur contenu.

Notes

OneDrive et SharePoint prennent en charge le contenu avec des étiquettes de confidentialité appliquées, à l’exception de certains scénarios limités. En revanche, l’intégration Git de Fabric ne prend pas en charge les étiquettes de confidentialité.

Évitez d’utiliser SharePoint ou OneDrive pour suivre et gérer les modifications dans les scénarios suivants :

• Le contenu consiste en des types d’éléments autres que les modèles sémantiques et les rapports.
• Le contenu est complexe ou volumineux dans l’étendue.
• Les créateurs de contenu doivent travailler en collaboration sur le même élément en même temps.

Les sections suivantes décrivent des considérations supplémentaires pour utiliser efficacement le contrôle de version en utilisant SharePoint ou OneDrive avec Power BI.

Intégration de Microsoft Teams

Vous pouvez utiliser les bibliothèques de documents de Microsoft Teams si les créateurs de contenu l’utilisent pour leur collaboration. Les bibliothèques de documents sont des sites SharePoint, et l’utilisation des bibliothèques de documents (au lieu d’un site SharePoint ou d’un dossier OneDrive séparé) garantit la centralisation du contenu, des fichiers et de la collaboration.

Fichiers d’entrée et de sortie

Vous devez extraire des fichiers que vous travaillez pour éviter les conflits de modifications possibles. Une fois les modifications terminées, vérifiez les fichiers avec des commentaires décrivant les modifications. L’entrée et la sortie de fichiers vous aident à améliorer la collaboration entre les créateurs de contenu lorsque vous utilisez SharePoint ou OneDrive for Work and School pour le contrôle des versions. Si vous enregistrez et retirez des fichiers avec plusieurs créateurs de contenu, vous pouvez modifier la bibliothèque de site SharePoint pour afficher la dernière mise à jour et les commentaires de la dernière entrée.

Historique des versions

Veillez à sauvegarder le contenu à un autre endroit en cas de perturbations inattendues de la bibliothèque de documents de votre site SharePoint. Il convient également de limiter le nombre de versions conservées dans le site SharePoint et de supprimer les anciennes versions. Cela garantit que l’historique des versions reste significatif et n’occupe pas trop d’espace.

Pour un contrôle de version plus sophistiqué, vous pouvez stocker des fichiers dans un référentiel distant comme Azure Repos et gérer les modifications en utilisant le contrôle de code source.

Contrôle de code source à l’aide d’un référentiel Git distant

Un référentiel Git distant facilite le contrôle de code source des fichiers, ce qui offre aux créateurs de contenu davantage d’options pour suivre et gérer les modifications. En bref, les créateurs de contenu peuvent développer du contenu localement ou dans le service Power BI, puis valider et pousser ces changements vers un référentiel Git distant comme Azure Repos

Notes

Vous pouvez également effectuer un contrôle de code source de votre contenu sans utiliser l’intégration Git. Dans ce scénario, vous continuez à suivre et à gérer les modifications de contenu dans un référentiel Git distant, mais vous déployez le contenu à l’aide des API REST ou des points de terminaison XMLA en lecture/écriture. Pour plus d’informations sur ces méthodes de déploiement de contenu, voir Étape 4 : Déployer le contenu.

Le diagramme suivant présente une vue d’ensemble de la manière dont vous effectuez le contrôle de code source en

Le diagramme décrit les processus et composants suivants.

Article	Description
	Les créateurs de contenu développent des modèles sémantiques et des rapports dans leur environnement local et les enregistrent sous forme de fichiers .pbip. Les créateurs de contenu peuvent également développer des modèles sémantiques et enregistrer les métadonnées des modèles.
	Lorsqu’ils sont prêts, les créateurs de contenu enregistrent leurs modifications, qui sont ensuite validées et transférées à intervalles réguliers vers un référentiel Git distant.
	Dans le référentiel Git distant, les créateurs de contenu suivent les modifications au niveau de l’objet, ce qui facilite le contrôle des versions. Les créateurs de contenu peuvent également créer des branches pour travailler sur le contenu et fusionner leurs modifications dans une branche unique à l’aide de demandes demande de tirage (pull request).
	Les créateurs de contenu peuvent synchroniser le contenu du référentiel distant en utilisant l’intégration Git. Ils peuvent également déployer du contenu en utilisant d’autres approches, telles que Azure Pipelines et les API REST.
	Dans l’espace de travail Fabric, les créateurs de contenu voient les modifications apportées au contenu Power BI une fois la synchronisation ou le déploiement terminé. Les créateurs de contenu peuvent créer du contenu comme des flux de données ou des notebooks dans l’espace de travail. S’ils utilisent l’intégration Git, les créateurs de contenu relient cet espace de travail à une branche spécifique du référentiel distant.
	Les créateurs de contenu peuvent valider et pousser les modifications d’un espace de travail vers le référentiel distant en utilisant l’intégration Git. Ces modifications peuvent importer des définitions d’éléments pour le contenu pris en charge rédigé dans l’espace de travail, comme les flux de données et les notebooks.

En résumé, les créateurs de contenu stockent les fichiers .pbip, les fichiers de métadonnées et la documentation dans un référentiel central Azure Repos. Ces fichiers sont organisés par un propriétaire technique. Alors qu’un créateur de contenu développe une solution, un propriétaire technique est responsable de la gestion de la solution, de l’examen des modifications et de leur fusion en une seule solution. Azure Repos offre des options plus sophistiquées de suivi et de gestion des modifications que SharePoint et OneDrive. Il est essentiel de maintenir un référentiel documenté et bien organisé, car il constitue la base de tout le contenu et de la collaboration.

Envisagez d’utiliser le contrôle de code source pour suivre et gérer les modifications dans les scénarios suivants :

• Équipes centralisées ou décentralisées créent et gèrent le contenu.
• Les créateurs de contenu collaborent en utilisant Azure DevOps.
• Les créateurs de contenu sont familiers avec Git, la gestion du contrôle de code source, ou les principes de DataOps.
• Les créateurs de contenu gèrent des contenus complexes ou importants, ou s’attendent à ce que le contenu évolue et devienne plus complexe et important.

Voici quelques prérequis et considérations pour vous aider à utiliser efficacement le contrôle de code source avec Azure DevOps.

• Git : Pour valider et envoyer (push) les modifications apportées à un référentiel distant, les créateurs de contenu doivent télécharger et installer Git. Git est un système de contrôle de version distribué qui effectue le suivi des modifications apportées à vos fichiers. Pour en savoir plus sur les principes de base de Git, consultez Qu’est-ce que Git ?.
• Outils : Pour utiliser Git, les créateurs de contenu doivent utiliser une interface de ligne de commande (CLI) ou un client d’interface utilisateur graphique pour SCM, comme Visual Studio ou Visual Studio Code.
• Licences et autorisations : Pour créer et utiliser un référentiel Git Azure Repos, les créateurs de contenu doivent disposer des éléments suivants :
  • Niveau d’accès défini sur De base (par opposition aux parties prenantes).
  • Appartient à une organisation et à un projet.
  • Autorisation de référentiel appropriée.
• Intégration Fabric Git : Pour synchroniser du contenu dans un référentiel distant avec un espace de travail Microsoft Fabric, les créateurs de contenu utilisent l’intégration Git Fabric. Il est important de suivre et de gérer les modifications apportées au contenu créé dans le portail Fabric, telles que les flux de données.

Conseil

Pour faciliter le contrôle de code source avec le développement local, nous vous recommandons d’utiliser une application cliente comme Visual Studio Code. Vous utilisez Power BI Desktop pour développer du contenu, puis vous pouvez utiliser Visual Studio Code pour effectuer la gestion du contrôle de code source de ce contenu, en mettant en scène, en validant et en poussant les modifications vers votre référentiel distant.

Avertissement

L’intégration Git Fabric a certaines limitations avec les éléments et scénarios pris en charge. Assurez-vous d’abord de valider si l’intégration Git de Fabric convient le mieux à votre scénario spécifique, ou si vous devriez adopter une approche différente pour implémenter le contrôle de code source.

En outre, étiquettes de confidentialité ne sont pas prises en charge avec l’intégration Git Fabric, et l’exportation d’éléments avec des étiquettes de confidentialité peut être désactivée. Si votre contenu comporte des étiquettes de confidentialité, vous devriez planifier comment vous pouvez réaliser le contrôle de version tout en respectant vos politiques de prévention de perte de données.

Un avantage clé de l’utilisation du contrôle de code source avec Azure Repos est une collaboration améliorée entre les créateurs de contenu ainsi qu’une personnalisation et une supervision accrues concernant les modifications et le déploiement de contenu.

Le diagramme suivant représente un aperçu général de la façon dont Azure DevOps permet la collaboration avec le contrôle de code source.

Notes

Le diagramme précédent illustre un exemple de collaboration à l’aide d’Azure DevOps. Choisissez une approche qui correspond le mieux aux besoins et au mode de travail de votre équipe.

Le diagramme décrit les actions utilisateur, processus et fonctionnalités qui suivent.

Item	Description
	Un créateur de contenu crée une nouvelle branche éphémère en clonant la branche principale, qui contient la dernière version du contenu. La nouvelle branche est souvent appelée branche de fonctionnalité, car elle est utilisée pour développer une fonctionnalité spécifique ou résoudre un problème spécifique.
	Le créateur de contenu valide ses modifications dans un référentiel local pendant le développement.
	Le créateur de contenu lie ses modifications aux éléments de travail gérés dans Azure Boards. Les éléments de travail décrivent des développements, des améliorations ou des correctifs de bogues spécifiques qui s’étendent à leur branche.
	Le créateur de contenu valide régulièrement ses modifications. Quand il est prêt, le créateur de contenu publie sa branche dans le référentiel distant.
	Pour tester ses modifications, le créateur de contenu déploie sa solution dans un espace de travail isolé pour son développement (non illustré dans ce diagramme). Le créateur de contenu peut également synchroniser la branche de la fonctionnalité avec l'espace de travail en utilisant l'intégration Fabric Git.
	Les créateurs de contenu et les propriétaires de contenu documentent la solution et ses processus dans un Wiki Azure, disponible pour toute l’équipe de développement.
	Lorsqu'il est prêt, le créateur de contenu ouvre une demande d'extraction pour fusionner la branche de fonctionnalité avec la branche principale.
	Un propriétaire technique est responsable de l’examen de la demande de tirage et de la fusion des modifications. Lorsqu’ils approuvent la demande de tirage, ils fusionnent les branche de fonctionnalité dans la branche principale.
	Une fusion réussie déclenche le déploiement de la solution dans un espace de travail de développement à l’aide d’un pipeline Azure (non illustré dans ce diagramme). Lors de l'utilisation de l'intégration Fabric Git, la branche principale est synchronisée avec l'espace de travail de développement.
	Le gestionnaire de versions effectue une révision et une approbation finales de la solution. Cette approbation de version empêche que la solution ne soit publiée avant d’être prête. Dans la publication de contenu d’entreprise, un gestionnaire de versions planifie et coordonne généralement la publication du contenu dans les espaces de travail de test et de production. Il coordonne et communique avec les créateurs de contenu, les parties prenantes et les utilisateurs.
	Lorsque le gestionnaire de versions approuve la version, Azure Pipelines prépare automatiquement la solution pour le déploiement. Un Azure Pipeline peut également déclencher un pipeline de déploiement pour promouvoir le contenu entre les espaces de travail.
	Les utilisateurs testent et valident le contenu dans l'espace de travail de test. Lors de l'utilisation de l'intégration Git avec Azure Pipelines pour le déploiement, l'espace de travail de test n'est synchronisé avec aucune branche.
	Une fois que les utilisateurs ont accepté et validé les modifications, le responsable de la mise en production procède à un examen final et approuve la solution à déployer dans l'espace de travail de production.
	Les utilisateurs visualisent le contenu publié dans l'espace de travail de production. Lors de l'utilisation de l'intégration Git avec Azure Pipelines pour le déploiement, l'espace de travail de production n'est synchronisé avec aucune branche.

Les sections suivantes décrivent d’autres considérations pour utiliser efficacement le contrôle de code source en utilisant Azure DevOps et Power BI.

Important

L’utilisation efficace des branches, des validations, des demandes de tirage et des fusions est essentielle pour tirer le meilleur parti du contrôle de code source lorsque vous gérez le cycle de vie de votre contenu Power BI.

Utiliser les branches

Les créateurs de contenu collaborent à l’aide d’une stratégie en branche. Une stratégie en branche permet aux créateurs de contenu individuels de travailler isolément dans leur référentiel local. Lorsqu’ils sont prêts, ils combinent leurs modifications en tant que solution unique dans le référentiel distant. Les créateurs de contenu doivent étendre leur travail à des branches en les liant à des éléments de travail pour des développements, des améliorations ou des correctifs de bogues spécifiques. Chaque créateur de contenu crée sa propre branche du référentiel distant pour son étendue de travail. Le travail effectué sur sa solution locale est validé et envoyé à une version de la branche dans le référentiel distant avec un message de validation descriptif. Un message de validation décrit les modifications apportées à cette validation.

Lorsque vous utilisez une stratégie de branching pour gérer le contenu Fabric, prenez en compte les facteurs suivants.

• Quels créateurs de contenu de branche doivent cloner pour leur propre travail. Par exemple, si ces branches sont un clone de la branche principale (appelée développement basé sur les jonctions) ou s’ils sont d’autres branches, comme les branches de mise en production pour des versions spécifiques et planifiées du contenu.
• Indique si vous allez étendre des tâches spécifiques aux versions de contenu distinctes à l’aide de branches de mise en production.
• Quelles branches se connectent à quel espace de travail lorsque vous utilisez l’intégration de Fabric Git.

Conseil

Consultez Adopter une stratégie de branchement Git pour obtenir des conseils et des recommandations spécifiques sur l’utilisation optimale d’une stratégie de branchement pour faciliter efficacement la collaboration.

Modifications par lots dans les validations

Lors du développement de contenu, les créateurs doivent régulièrement mettre en scène des modifications en lots (ou groupes). Ces modifications doivent traiter un élément de travail spécifique pour la solution (par exemple, une caractéristique ou un problème). Lorsque vous êtes prêt, les créateurs de contenu valident ces modifications intermédiaires.

Les modifications par lot de cette façon offrent plusieurs avantages.

• Elle permet de structurer le développement et de donner aux créateurs de contenu une chance de passer en revue et de documenter les modifications qu’ils ont regroupées.
• Elle améliore l’alignement entre la planification et le développement, ce qui facilite la liaison des caractéristiques et des problèmes et la transparence sur la façon dont le travail se poursuit.
• Les propriétaires techniques peuvent consulter plus facilement les demandes de tirage des créateurs de contenu si les modifications sont traitées par lots de manière appropriée et ont des messages de validation clairs.

Lorsque vous mettez en scène et validez les modifications apportées au contenu Power BI, tenez compte des facteurs suivants.

• Que vous ayez l’étape et la validation des modifications à partir d’un référentiel local ou de l’espace de travail Fabric.
• Placez des fichiers .pbip dans des dossiers de niveau supérieur lorsque vous stockez plusieurs modèles ou rapports dans un seul référentiel. Cela facilite l’identification et le groupe des modifications que vous apportez.
• Ignorez les modifications de métadonnées innocues ou inutiles à l’aide d’un fichier gitignore ou d’un fichier .gitattributes. Cela garantit que toutes les modifications que vous validez sont significatives.

Conseil

Consultez Enregistrer votre travail avec des validations pour obtenir des conseils et des recommandations spécifiques sur l’étape et la validation de votre travail dans un référentiel Git.

Créer des demandes de tirage pour fusionner les modifications

Pour fusionner les modifications, un créateur de contenu ouvre une demande de tirage. Une demande de tirage est une soumission pour examen par les pairs qui peut entraîner la fusion du travail effectué en une seule solution. La fusion peut entraîner des conflits, qui doivent être résolus avant que la branche puisse être fusionnée. Les révisions des demandes de tirage sont importantes pour s’assurer que les créateurs respectent les normes et pratiques organisationnelles en matière de développement, de qualité et de conformité.

Lorsque vous utilisez des demandes de tirage pour fusionner des modifications dans le contenu Power BI, prenez en compte les facteurs suivants.

• Quelles sont les normes et les pratiques que vous utiliserez pour effectuer votre évaluation, le cas échéant. Par exemple, vous pouvez utiliser des règles à partir de l’analyseur de meilleures pratiques pour les modèles sémantiques.
• Comment évaluer les modifications apportées aux métadonnées de rapport, ce qui n’est pas facile à lire et à comprendre sans utiliser d’outils tiers.
• Comment résoudre les conflits de fusion.

Conseil

Consultez À propos des demandes de tirage et stratégies de fusion et de fusion de courge pour obtenir des conseils et des recommandations spécifiques sur la meilleure utilisation des demandes de tirage pour faciliter la collaboration en fusionnant les modifications apportées au contenu.

Liste de vérifiation – Lors de la planification de l’endroit où vous stockerez les fichiers, les décisions et actions clés incluent :

• Choisir vos outils de développement : Assurez-vous que votre approche pour développer du contenu s’aligne sur la façon dont vous allez collaborer avec d’autres créateurs de contenu et utiliser le contrôle de version.
• Choisir entre les formats .pbip et .pbix pour les modèles et les rapports : Généralement, le format .pbip est plus avantageux pour le contrôle de code source, mais les utilisateurs en libre-service peuvent trouver des fichiers .pbix plus faciles à utiliser.
• Développement de modèles sémantiques et de rapports distincts : contrôle de version est le plus efficace lorsque vous gérez les modifications pour différents types d’éléments, séparément. Modèle de séparation et développement de rapports est considéré comme une bonne pratique.
• Déterminer le nombre d’espaces de travail dont vous avez besoin : L’utilisation d’environnements distincts est essentielle pour la réussite de la gestion de cycle de vie du contenu. Vérifiez que vous avez précisé le nombre d’espaces de travail dont vous avez besoin et que vous effectuez la planification appropriée au niveau de l’espace de travail.
• Décider de la façon dont vous allez implémenter le contrôle de version : choisir entre une approche plus simple à l’aide de SharePoint ou OneDrive Entreprise, ou à l’aide d’Azure DevOps pour faciliter le contrôle de code source.
• Configurer votre référentiel distant : Créer un espace structuré dans le dossier OneDrive ou le référentiel Git où vous allez stocker du contenu pour suivre et gérer les modifications.
• Si vous utilisez le contrôle de code source, configurez les fichiers .gitignore et .gitattributes : Vérifiez que vous configurez votre référentiel afin de suivre uniquement les modifications significatives.
• Si vous utilisez le contrôle de code source, définissez des stratégies de branchement et de fusion : Veillez à définir des processus clairs pour configurer et utiliser le contrôle de code source pour mieux prendre en charge le développement. Évitez de surcompliquer votre processus. Au lieu de cela, essayez de compléter la façon actuelle de travailler dans vos équipes de développement.

Contenu connexe

Dans l’article suivant de cette série, découvrez comment valider le contenu dans le cadre de la gestion de cycle de vie du contenu.