Scénarios d’utilisation de Power BI : publication de contenu d’entreprise

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 l’implémentation de Power BI.

Lorsque les créateurs de contenu collaborent pour fournir des solutions analytiques qui sont importantes pour l’organisation, ils doivent garantir une livraison rapide et fiable du contenu aux consommateurs. Les équipes techniques répondent à ce défi à l’aide d’un processus appelé DevOps. DevOps permet aux équipes d’automatiser et de mettre à l’échelle les processus en adoptant des pratiques qui améliorent et accélèrent la livraison.

Notes

Les équipes de données qui répondent aux mêmes défis pourraient également pratiquer la méthodologie DataOps. DataOps s’appuie sur les principes DevOps, mais inclut des pratiques supplémentaires spécifiques à la gestion des données, telles que l’assurance de la qualité des données et la gouvernance. Nous faisons référence à DevOps dans cet article, mais sachez que les principes sous-jacents peuvent également s’appliquer à DataOps.

Les créateurs de contenu et les consommateurs bénéficient de plusieurs avantages lors de l’adoption de pratiques DevOps pour publier du contenu Power BI. Les points suivants sont une vue d’ensemble générale du fonctionnement de ce processus.

1. Développer du contenu et valider le travail dans un référentiel distant: les créateurs de contenu développent leur solution sur leur propre ordinateur. Ils valident et enregistrent leur travail dans un référentiel distant à intervalles réguliers pendant le développement. Un référentiel distant contient la dernière version de la solution. Il est accessible à l’ensemble de l’équipe de développement.
2. Collaborer et gérer les modifications de contenu à l’aide du contrôle de version: d’autres créateurs de contenu peuvent apporter des révisions à la solution en créant une branche. Une branche est une copie d’un référentiel distant. Lorsque ces révisions sont prêtes et approuvées, la branche est fusionnée avec la dernière version de la solution. Toutes les révisions de la solution sont suivies. Ce processus est appelé contrôle de version (ou contrôle de code source).
3. Déployer et promouvoir du contenu à l’aide de pipelines: dans le scénario d’utilisation de la publication de contenu en libre-service , le contenu est promu (ou déployé) via des espaces de travail de développement, de test et de production à l’aide de pipelines de déploiement Power BI. Les pipelines de déploiement Power BI peuvent promouvoir du contenu dans des espaces de travail Power BI Premium manuellement à l’aide de l’interface utilisateur, ou par programmation à l’aide des API REST. En revanche, la publication de contenu d’entreprise (au cœur de ce scénario d’utilisation) promeut le contenu à l’aide d’Azure Pipelines. Azure Pipelines est un service Azure DevOps qui automatise le test, la gestion et le déploiement du contenu à l’aide d’une série d’étapes programmatiques personnalisées. Dans le scénario d’utilisation de la publication de contenu d’entreprise, ces pipelines peuvent également être appelés pipelines d’intégration et de déploiement continus (ou pipelines CI/CD). Ces pipelines intègrent fréquemment et automatiquement les modifications et simplifient la publication de contenu.

Important

Cet article fait parfois référence à Power BI Premium ou à ses abonnements de capacité (SKU P). Sachez que Microsoft regroupe actuellement des options d’achat et met hors service les SKU Power BI Premium par capacité. Les clients nouveaux et existants doivent plutôt envisager l’achat d’abonnements de capacité Fabric (SKU F).

Pour plus d’informations, consultez Importante mise à jour à venir des licences Power BI Premium et FAQ sur Power BI Premium.

DevOps prend en charge une approche mature et systématique de la gestion et de la publication de contenu. Il permet aux créateurs de contenu de collaborer sur des solutions et garantit une livraison rapide et fiable de contenu aux consommateurs. Lorsque vous respectez les pratiques DevOps, vous bénéficiez de workflows rationalisés, vous rencontrez moins d’erreurs et vous profitez d’expériences améliorées pour les créateurs de contenu et les consommateurs de contenu.

Vous configurez et gérez les pratiques DevOps pour votre solution Power BI à l’aide d’Azure DevOps. Dans les scénarios d’entreprise, vous pouvez automatiser la publication de contenu avec Azure DevOps et les API REST Power BI de trois manières différentes.

• API REST Power BI avec des pipelines de déploiement Power BI : vous pouvez importer du contenu dans des espaces de travail de développement et utiliser des pipelines de déploiement pour déployer du contenu via des espaces de travail de test et de production. Vous contrôlez toujours le déploiement à partir d’Azure DevOps et utilisez les API REST Power BI pour gérer les pipelines de déploiement au lieu d’éléments de contenu individuels. En outre, vous utilisez le point de terminaison XMLA pour déployer des métadonnées de modèle de données au lieu d’un fichier Power BI Desktop (.pbix) avec Azure DevOps. Ces métadonnées vous permettent de suivre les modifications au niveau de l’objet à l’aide du contrôle de version. Bien que plus robuste et plus facile à gérer, cette approche nécessite une licence Premium et un effort de script modéré pour configurer l’importation et le déploiement de contenu avec les API REST Power BI. Utilisez cette approche lorsque vous souhaitez simplifier la gestion du cycle de vie du contenu avec des pipelines de déploiement et que vous disposez d’une licence Premium. Le point de terminaison XMLA et les pipelines de déploiement Power BI sont des fonctionnalités Premium.
• API REST Power BI: vous pouvez également importer du contenu dans des espaces de travail de développement, de test et de production à l’aide d’Azure DevOps et uniquement des API REST Power BI. Cette approche ne nécessite pas de licence Premium, mais elle implique un effort de script et une configuration élevés, car le déploiement est géré en dehors de Power BI. Utilisez cette approche lorsque vous souhaitez déployer du contenu Power BI de manière centralisée à partir d’Azure DevOps, ou lorsque vous ne disposez pas d’une licence Premium. Pour une comparaison visuelle entre les deux premières approches, consultez le diagramme de flux des approches de pipeline de mise en production.
• outils d’automatisation Power BI avec des pipelines de déploiement Power BI: vous pouvez utiliser les outils d’automatisation Power BI extension Azure DevOps pour gérer les pipelines de déploiement au lieu des API REST Power BI. Cette approche est une alternative à la première option, qui utilise les API REST Power BI avec des pipelines de déploiement Power BI. L’extension des outils d’automatisation Power BI est un outil open source. Elle vous aide à gérer et à publier du contenu à partir d’Azure DevOps sans avoir besoin d’écrire des scripts PowerShell. Utilisez cette approche lorsque vous souhaitez gérer les pipelines de déploiement à partir d’Azure DevOps avec un effort minimal de script et que vous disposez d’une capacité Premium.

Cet article se concentre sur la première option, qui utilise les API REST Power BI avec des pipelines de déploiement Power BI. Il décrit comment utiliser Azure DevOps pour configurer des pratiques DevOps. Il décrit également comment utiliser Azure Repos pour vos référentiels distants et automatiser le test de contenu, l’intégration et la livraison avec Azure Pipelines. Azure DevOps n’est pas le seul moyen de configurer la publication de contenu d’entreprise, mais une intégration simple à Power BI en fait un bon choix.

Notes

Ce scénario d’utilisation est l’un des scénarios de gestion et de déploiement de contenu. Par souci de concision, certains aspects décrits dans la rubrique Scénarios de collaboration et de distribution de contenu ne sont pas abordés dans cet article. Pour une couverture complète, lisez d’abord ces articles.

Conseil

Microsoft Fabric fournit d’autres options pour la publication de contenu d’entreprise à l’aide de l'intégration Git Fabric. L’intégration Git vous permet de lier un espace de travail Fabric à une branche dans votre référentiel distant Azure Repos. Le contenu enregistré dans cette branche se synchronise automatiquement avec l’espace de travail, comme si ce contenu a été publié dans l’espace de travail. À l’inverse, les créateurs de contenu peuvent valider et envoyer (push) les modifications de l’espace de travail Fabric vers le référentiel distant.

L’intégration Git peut simplifier la collaboration et la publication de contenu, mais elle nécessite davantage de planification pour utiliser les espaces de travail Fabric et votre stratégie de branchement. Pour plus d’informations sur la configuration et l’utilisation de l’intégration Git Fabric, consultez Prise en main de l’intégration Git ou Tutoriel : Gestion du cycle de vie de bout en bout.

Schéma du scénario

Le schéma suivant présente une vue d’ensemble des actions utilisateur les plus courantes et des composants Power BI qui prennent en charge la publication de contenu d’entreprise. L’accent est mis sur l’utilisation d’Azure DevOps pour gérer et publier du contenu par programmation à grande échelle via des espaces de travail de développement, de test et de production dans le service Power BI.

Conseil

Nous vous encourageons à télécharger le diagramme de scénario si vous souhaitez l’incorporer dans votre présentation, documentation ou billet de blog ou encore l’imprimer en tant qu’affiche murale. Étant donné qu’il s’agit d’une image SVG (Scalable Vector Graphics), vous pouvez la mettre à l’échelle vers le haut ou vers le bas sans aucune perte de qualité.

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

Item	Description
	Les créateurs de contenu développent des modèles de données à l’aide de Power BI Desktop ou Éditeur tabulaire, et ils développent des rapports à l’aide de Power BI Desktop. Les créateurs de contenu enregistrent leur travail dans un référentiel local pendant le développement.
	Les créateurs de contenu peuvent cloner un référentiel distant pour obtenir une copie locale de ce contenu.
	Certaines sources de données peuvent nécessiter une passerelle de données locale ou une passerelle de réseau virtuel pour l’actualisation des données, comme celles qui résident dans un réseau d’organisation privé.
	Les créateurs de contenu valident et poussent régulièrement leurs modifications vers un référentiel distant pendant le développement à l’aide d’un client Git tel que Visual Studio Code. Dans le diagramme, le référentiel distant est Azure Repos.
	D’autres créateurs de contenu utilisent Azure Repos pour suivre les modifications avec le contrôle de version. Ils collaborent en validant les modifications dans des branches distinctes.
	Les modifications apportées au contenu dans le référentiel distant déclenchent Azure Pipelines. Un pipeline de validation est le premier pipeline déclenché. Le pipeline de validation effectue des tests automatisés pour valider le contenu avant sa publication.
	Le contenu qui réussit le pipeline de validation déclenche un pipeline de build suivant. Le pipeline de build prépare le contenu pour la publication sur le service Power BI. Jusqu’à ce stade, le processus est généralement appelé intégration continue (CI).
	Le contenu est publié et déployé à l’aide de pipelines de mise en production. Les pipelines de mise en production utilisent les API REST Power BI ou le point de terminaison XMLA de l’espace de travail pour importer par programmation du contenu dans le service Power BI. Le déploiement à l’aide de pipelines de mise en production est généralement appelé déploiement continu (CD).
	Un gestionnaire de versions contrôle le déploiement sur les espaces de travail de test et de production à l’aide d’une approbation de mise en production d’Azure Pipelines. Dans la publication de contenu d’entreprise, un gestionnaire de versions planifie et coordonne généralement la publication du contenu dans les environnements de test et de production. Il coordonne et communique avec les créateurs de contenu, les parties prenantes et les utilisateurs.
	Un pipeline de mise en production publie du contenu dans l’espace de travail de développement ou promeut du contenu du développement aux espaces de travail de test ou des espaces de travail de production.
	Les créateurs de contenu travaillant dans un espace de travail qui a capacité Fabric mode de licence peuvent utiliser l’intégration Git. Avec l’intégration de Git, les créateurs de contenu peuvent travailler dans un espace de travail privé pendant le développement. Le créateur de contenu synchronise une branche distante (généralement une branche de fonctionnalité spécifique ou une branche de bogue) à partir d’Azure Repos vers leur espace de travail privé. Les modifications de contenu sont synchronisées entre la branche distante dans Azure Repos et l’espace de travail. Dans ce scénario, les créateurs de contenu n’ont pas besoin d’utiliser Azure Pipelines pour publier du contenu. Les créateurs de contenu peuvent également valider et envoyer régulièrement des modifications à partir de l’espace de travail après la publication. Lorsque vous êtes prêt, les créateurs de contenu peuvent effectuer une demande de tirage (PULL) pour fusionner leurs modifications apportées à la branche principale.
	Lorsque vous utilisez l’intégration Git, l’espace de travail de développement se synchronise avec la branche principale pour obtenir les dernières versions du contenu. Ce contenu inclut toutes les modifications apportées aux demandes de tirage qu’un gestionnaire de versions passe en revue, approuve et fusionne.
	Les espaces de travail sont définis sur la capacité Fabric, la capacité Premium, les Premium par utilisateur ou le mode de licence Incorporépour autoriser l’utilisation de pipelines de déploiement Power BI et du point de terminaison de lecture/écriture XMLA.
	Un administrateur de pipeline de déploiement configure le pipeline de déploiement Power BI avec trois étapes : développement, test et production. Chaque étape s’aligne sur un espace de travail distinct dans le service Power BI. Les paramètres de déploiement et l’accès sont définis pour le pipeline de déploiement.
	L’espace de travail de développement contient les dernières versions du contenu, y compris toutes les modifications approuvées et fusionnées. Une fois approuvé, un pipeline de mise en production déploie du contenu du développement vers l’espace de travail de test.
	Les réviseurs au sein de l’espace de travail de test effectuent des tests et une assurance qualité sur le contenu. Une fois approuvé, un pipeline de mise en production déploie du contenu du test vers l’espace de travail de production. Lors de l'utilisation de l'intégration Git avec les pipelines de déploiement, l'espace de travail de test n'est synchronisé avec aucune branche.
	Une fois le déploiement pipeline terminé, les créateurs de contenu effectuent manuellement des activités post-déploiement. Les activités peuvent inclure la configuration de l’actualisation planifiée des données ou la mise à jour d’une application Power BI pour l’espace de travail de production. Lors de l'utilisation de l'intégration Git avec les pipelines de déploiement, l'espace de travail de production n'est synchronisé avec aucune branche.
	Les lecteurs du contenu accèdent à celui-ci à l’aide de l’espace de travail de production ou d’une application Power BI.

Conseil

Nous vous recommandons également de passer en revue les scénarios d’utilisation de la publication de contenu en libre-service et de gestion avancée des modèles de données. Le scénario d’utilisation de la publication de contenu d’entreprise s’appuie sur les concepts que ces scénarios introduisent.

Points clés

Voici quelques points clés à signaler concernant le scénario de publication de contenu d’entreprise.

Gestion de versions

Le suivi des modifications pendant le cycle de vie du contenu est important pour garantir une livraison stable et cohérente du contenu aux consommateurs. Dans ce scénario d’utilisation, les créateurs et propriétaires de contenu gèrent les modifications de contenu dans un référentiel distant à l’aide du 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 permet une meilleure collaboration et une gestion efficace de l’historique des versions. Le contrôle de version présente des avantages pour les créateurs de contenu, notamment la possibilité de restaurer ou de fusionner les modifications.

Les créateurs de contenu développent généralement des modèles de données dans l’éditeur tabulaire pour prendre en charge un meilleur contrôle de version. Au contraire d’un modèle de données que vous développez dans Power BI Desktop, un modèle de données développé dans Tabular Editor est enregistré dans un format de métadonnées lisible par l’humain. Ce format active le contrôle de version au niveau de l’objet du modèle de données. Vous devez utiliser le contrôle de version au niveau de l’objet lorsque vous collaborez avec plusieurs personnes sur le même modèle de données. Pour plus d’informations, consultez le scénario d’utilisation Gestion avancée du modèle de données. Il n’est pas possible de voir les modifications que vous avez apportées dans un fichier Power BI Desktop (.pbix), tel que le rapport de définition ou le modèle de données. Par exemple, vous ne pouvez pas suivre les modifications apportées à une page de rapport, telles que les visuels utilisés, leurs positions et leurs mappages de champs ou leur mise en forme.

Les créateurs de contenu stockent des fichiers de métadonnées de modèle de données et des fichiers .pbix dans un référentiel distant central, comme 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 fournit des options sophistiquées pour le suivi et la gestion des modifications. Cette approche diffère de l’approche décrite dans le scénario d’utilisation de la publication de contenu en libre-service, où le créateur utilise le stockage OneDrive avec suivi de version. 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.

Voici quelques considérations clés pour vous aider à configurer un référentiel distant pour le contrôle de version.

• Étendue : définissez clairement l'étendue du référentiel. Idéalement, l’étendue du référentiel est identique à l’étendue des espaces de travail et des applications en aval que vous utilisez pour fournir du contenu aux consommateurs.
• Access: Vous devez configurer l’accès au référentiel en utilisant un modèle d’autorisations similaire à celui que vous avez mis en place pour vos autorisations de pipeline de déploiement et, ainsi que pour les rôles d’espace de travail . Les créateurs de contenu doivent accéder au référentiel.
• documentation: ajoutez des fichiers texte au référentiel pour documenter son objectif, sa propriété, son accès et ses processus définis. Par exemple, la documentation peut décrire comment les modifications doivent être placées en phase intermédiaire et validées.
• Tools: pour valider et envoyer (push) des modifications vers un référentiel distant, les créateurs de contenu ont besoin d’un client Git comme Visual Studio ou Visual Studio Code. 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 ?.

Notes

Envisagez d’utiliser le stockage de fichiers volumineux Git (LFS) si vous envisagez de valider Power BI Desktop fichiers (.pbix). Git LFS fournit des options avancées pour la gestion des fichiers où les modifications ne sont pas visibles (fichiers indifférables), comme un fichier .pbix. Par exemple, vous pouvez utiliser le verrouillage de fichiers pour empêcher les modifications simultanées d’un rapport Power BI pendant le développement. Toutefois, Git LFS a son propre client et sa propre configuration.

Collaboration avec Azure DevOps

À mesure qu’une solution augmente en étendue et en complexité, plusieurs créateurs et propriétaires de contenu devront sans doute collaborer. Les créateurs et les propriétaires de contenu communiquent et collaborent dans un hub central et organisé à l’aide d’Azure DevOps.

Pour collaborer et communiquer dans Azure DevOps, vous utilisez des services de prise en charge.

• Azure Boards: les propriétaires de contenu utilisent des tableaux pour suivre éléments de travail. Les éléments de travail sont chacun attribués à un développeur unique au sein de l’équipe, et ils décrivent les problèmes, bogues ou fonctionnalités de la solution, ainsi que les parties prenantes correspondantes.
• azure Wiki: les créateurs de contenu partagent des informations avec leur équipe pour comprendre et contribuer à la solution.
• Azure Repos: les créateurs de contenu effectuent le suivi des modifications dans le référentiel distant et les fusionnent dans une seule solution.
• Azure Pipelines: les propriétaires de pipelines configurent la logique programmatique pour déployer la solution, automatiquement ou à la demande.

Diagramme de flux de collaboration

Le diagramme suivant illustre une vue d’ensemble générale d’un exemple de la façon dont Azure DevOps permet la collaboration dans le scénario d’utilisation de la publication de contenu d’entreprise. Le diagramme se concentre sur l’utilisation d'Azure DevOps pour créer un processus de publication de contenu structuré et documenté.

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.

Pour élaborer, les créateurs de contenu collaborent à l’aide d’une stratégie en branche. Une stratégie de ramification est la manière dont les créateurs de contenu créent, utilisent et fusionnent les ramifications pour apporter et gérer efficacement les modifications de contenu. Les créateurs de contenu individuels travaillent 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. Un message de validation décrit les modifications apportées à cette validation.

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é.

Recommandations relatives à la collaboration

Nous vous recommandons de définir un processus structuré pour la façon dont les créateurs de contenu doivent collaborer. Vérifiez que vous déterminez :

• Comment le travail est délimité et comment les branches sont créées, nommées et utilisées.
• Comment les auteurs regroupent les modifications et les décrivent avec des messages de validation.
• Qui est responsable de l’examen et de l’approbation des demandes de tirage.
• Comment les conflits de fusion sont résolus.
• Comment les modifications apportées dans différentes branches sont fusionnées en une seule branche.
• Comment le contenu est testé et qui effectue les tests avant le déploiement du contenu.
• Comment et quand les modifications sont déployées dans les espaces de travail de développement, de test et de production.
• Comment et quand les modifications ou versions de la solution doivent être restaurées.

Important

La valeur fournie par DevOps est directement proportionnelle à l’adhésion aux processus qui définissent son utilisation.

Une collaboration réussie dépend d’un processus bien défini. Il est important de décrire et de documenter clairement le workflow de développement de bout en bout. Assurez-vous que les stratégies et processus sélectionnés s’alignent sur les pratiques existantes au sein de votre équipe et, si ce n’est pas le cas, sur la façon dont vous allez gérer les changements. De plus, assurez-vous que les processus sont clairs et communiqués à tous les membres de l’équipe et les parties prenantes. Assurez-vous que les membres de l’équipe et les parties prenantes qui débutent dans les processus sont formés à la façon de les adopter et qu’ils apprécient la valeur d’une adoption réussie de DevOps.

API REST Power BI

Vous développez une logique programmatique pour importer et déployer du contenu à partir d’Azure DevOps à l’aide des API REST Power BI. Vous importez des fichiers Power BI (.pbix) dans un espace de travail à l’aide d’une opération d’importation. Vous utilisez une opération de pipeline pour déployer du contenu ou tout le contenu dans des espaces de travail de test ou de production à l’aide de pipelines de déploiement Power BI. La logique programmatique est définie dans Azure Pipelines.

Nous vous recommandons d’utiliser un principal de service pour appeler des API REST Power BI dans vos pipelines. Un principal de service est destiné aux activités automatisées et sans assistance et ne repose pas sur les informations d’identification de l’utilisateur. Toutefois, certains éléments et activités ne sont pas pris en charge par les API REST Power BI ou lors de l’utilisation d’un principal de service, comme les flux de données.

Lorsque vous utilisez un principal de service, veillez à gérer soigneusement les autorisations. Vous devez suivre le principe du moindre privilège. Vous devez définir des autorisations suffisantes pour le principal de service sans autorisations de surapprovisionnement. Utilisez Azure Key Vault ou un autre service qui stocke en toute sécurité les secrets et les informations d’identification du principal du service.

Attention

Si vous avez un modèle de données enregistré en tant que format de métadonnées lisible par l’homme, il ne peut pas être publié à l’aide des API REST Power BI. Au lieu de cela, vous devez le publier à l’aide du point de terminaison XMLA. Vous pouvez publier des fichiers de métadonnées à l’aide d’outils tiers tels que l’interface de ligne de commande de l’Éditeur tabulaire (CLI). Vous pouvez également publier des fichiers de métadonnées par programmation à l’aide de votre propre développement .NET personnalisé. Le développement d’une solution personnalisée nécessite plus d’efforts, car vous devez utiliser l’extension TOM (Microsoft Tabular Object Model) des bibliothèques clientes AMO (Analysis Management Object).

Azure Pipelines

Azure Pipelines automatise par programmation le test, la gestion et le déploiement du contenu. Lorsqu’un pipeline est exécuté, les étapes du pipeline s’exécutent automatiquement. Les propriétaires de pipelines peuvent personnaliser ses déclencheurs, ses étapes et ses fonctionnalités pour répondre aux besoins de déploiement. Par conséquent, le nombre et les types de pipelines varient en fonction des exigences de la solution. Par exemple, un pipeline Azure peut exécuter des tests automatisés ou modifier les paramètres du modèle de données avant un déploiement.

Il existe trois types d’Azure Pipelines que vous pouvez configurer pour tester, gérer et déployer votre solution Power BI :

• Pipelines de validation.
• Pipelines de build.
• Pipelines de mise en production.

Notes

Il n’est pas nécessaire d’avoir ces trois pipelines dans votre solution de publication. En fonction de votre workflow et de vos besoins, vous pourriez configurer une ou plusieurs des variantes des pipelines décrites dans cet article pour automatiser la publication de contenu. Cette possibilité de personnaliser les pipelines est un avantage d’Azure Pipelines par rapport aux pipelines de déploiement Power BI intégrés. Par exemple, vous n’avez pas besoin d’avoir un pipeline de validation. Vous pouvez utiliser uniquement des pipelines de build et de mise en production.

Pipelines de validation

Les pipelines de validation effectuent des vérifications de qualité de base des modèles de données avant leur publication dans un espace de travail de développement. En règle générale, les modifications d’une branche du référentiel distant déclenchent la validation par le pipeline de ces modifications à l’aide de tests automatisés.

Parmi les exemples de tests automatisés, citons l’analyse du modèle de données à la recherche de violations de règles de meilleures pratiques à l’aide de Best Practice Analyzer (BPA) ou l’exécution de requêtes DAX sur un modèle sémantique publié. Les résultats de ces tests sont ensuite stockés dans le référentiel distant à des fins de documentation et d’audit. Les modèles de données qui échouent à la validation ne doivent pas être publiés. Au lieu de cela, le pipeline doit informer les créateurs de contenu des problèmes.

Pipelines de build

Les pipelines de build préparent les modèles de données pour la publication sur le service Power BI. Ces pipelines combinent les métadonnées de modèle sérialisées dans un fichier unique publié ultérieurement par un pipeline de mise en production (décrit dans le diagramme des pipelines de mise en production). Un pipeline de build peut également apporter d’autres modifications aux métadonnées, comme la modification des valeurs de paramètres. Les pipelines de build produisent des artefacts de déploiement qui se composent de métadonnées de modèle de données (pour les modèles de données) et de fichiers Power BI Desktop (.pbix) prêts à être publiés dans le service Power BI.

Pipelines de mise en production

Les pipelines de mise en production publient ou déploient du contenu. Une solution de publication comprend généralement plusieurs pipelines de mise en production, en fonction de l’environnement cible.

• Pipeline de mise en production de développement : ce premier pipeline est déclenché automatiquement. Il publie le contenu dans un espace de travail de développement une fois les pipelines de build et de validation réussis.
• Pipelines de test et de mise en production: Ces pipelines ne sont pas déclenchés automatiquement. Au lieu de cela, ils sont déclenchés à la demande ou lorsqu’ils sont approuvés. Les pipelines de mise en production et de test déploient le contenu dans un espace de travail de test ou de production, respectivement, après approbation de la mise en production. Les approbations de mise en production garantissent que le contenu n’est pas déployé automatiquement dans une phase de test ou de production avant d’être prêt. Ces approbations sont fournies par les gestionnaires de mise en production, qui sont responsables de la planification et de la coordination de la publication de contenu dans les environnements de test et de production.

Il existe deux approches différentes pour publier du contenu avec des pipelines de test et de mise en production. Soit ils font la promotion du contenu à l’aide d’un pipeline de déploiement Power BI, soit ils publient du contenu sur le service Power BI à partir d’Azure DevOps.

Le diagramme suivant illustre la première approche. Dans cette approche, les pipelines de mise en production orchestrent le déploiement de contenu sur les espaces de travail de test et de production à l’aide de pipelines de déploiement Power BI. Le contenu est promu via des espaces de travail de développement, de test et de production dans Power BI. Bien que cette approche soit plus robuste et plus simple à gérer, elle nécessite des licences Premium.

Le diagramme illustre les actions, processus et fonctionnalités utilisateur suivants de la première approche.

Item	Description
	Dans la première approche, les pipelines de mise en production publient du contenu à l’aide du point de terminaison XMLA et des API REST Power BI avec des pipelines de déploiement Power BI. Le contenu est publié, puis promu via des espaces de travail de développement, de test et de production. Les pipelines de déploiement Power BI et le point de terminaison de lecture/écriture XMLA sont des fonctionnalités Premium.
	Une fusion de branche réussie ou l’achèvement d’un pipeline en amont déclenche le pipeline de build. Le pipeline de build prépare ensuite le contenu pour la publication et déclenche le pipeline de mise en production de développement.
	Le pipeline de mise en production de développement publie le contenu dans l’espace de travail de développement à l’aide du point de terminaison XMLA (pour les métadonnées du modèle de données) ou des API REST Power BI (pour les fichiers Power BI Desktop, qui peuvent contenir des modèles de données et des rapports). Le pipeline de développement utilise l’interface de ligne de commande (CLI) de l’Éditeur tabulaire pour déployer des métadonnées de modèle de données à l’aide du point de terminaison XMLA.
	Un déclencheur d’approbation de mise en production ou à la demande active le pipeline de mise en production de test.
	Le pipeline de mise en production de test déploie le contenu à l’aide des opérations de déploiement de l’API REST Power BI, qui exécutent le pipeline de déploiement Power BI.
	Le pipeline de déploiement Power BI promeut le contenu de l’espace de travail de développement vers l’espace de travail de test. Après le déploiement, le pipeline de mise en production effectue des activités post-déploiement à l’aide des API REST Power BI (non indiquées dans le diagramme).
	Un déclencheur d’approbation de mise en production ou à la demande active le pipeline de mise en production.
	Le pipeline de mise en production déploie le contenu à l’aide des opérations de déploiement de l’API REST Power BI, qui exécutent le pipeline de déploiement Power BI.
	Le pipeline de déploiement Power BI promeut le contenu de l’espace de travail de test vers l’espace de travail de production. Après le déploiement, le pipeline de mise en production effectue des activités post-déploiement à l’aide des API REST Power BI (non indiquées dans le diagramme).

Le diagramme suivant illustre la deuxième approche. Cette approche n’utilise pas de pipelines de déploiement. Au lieu de cela, elle utilise des pipelines de mise en production pour publier du contenu sur des espaces de travail de test et de production à partir d’Azure DevOps. Notamment, cette deuxième approche ne nécessite pas de licence Premium lorsque vous publiez uniquement des fichiers Power BI Desktop avec les API REST Power BI. Cela implique davantage d’efforts et de complexité de configuration, car vous devez gérer le déploiement en dehors de Power BI. Les équipes de développement qui utilisent déjà DevOps pour des solutions de données en dehors de Power BI connaîtront sans doute mieux cette approche. Les équipes de développement qui utilisent cette approche peuvent consolider le déploiement de solutions de données dans Azure DevOps.

Le diagramme illustre les actions, processus et fonctionnalités utilisateur suivants dans la deuxième approche.

Item	Description
	Dans la deuxième approche, les pipelines de mise en production publient du contenu à l’aide du point de terminaison XMLA et des API REST Power BI uniquement. Le contenu est publié dans les espaces de travail de développement, de test et de production.
	Une fusion de branche réussie ou l’achèvement d’un pipeline en amont déclenche le pipeline de build. Le pipeline de build prépare ensuite le contenu pour la publication et déclenche le pipeline de mise en production de développement.
	Le pipeline de mise en production de développement publie le contenu dans l’espace de travail de développement à l’aide du point de terminaison XMLA (pour les métadonnées du modèle de données) ou des API REST Power BI (pour les fichiers Power BI Desktop, qui peuvent contenir des modèles de données et des rapports). Le pipeline de développement utilise l’interface de ligne de commande (CLI) de l’Éditeur tabulaire pour déployer des métadonnées de modèle de données à l’aide du point de terminaison XMLA.
	Un déclencheur d’approbation de mise en production ou à la demande active le pipeline de mise en production de test.
	Le pipeline de mise en production de développement publie du contenu dans l’espace de travail de test à l’aide du point de terminaison XMLA (pour les métadonnées du modèle de données) ou des API REST Power BI (pour les fichiers Power BI Desktop, qui peuvent contenir des modèles de données et des rapports). Le pipeline de développement utilise l’interface de ligne de commande (CLI) de l’Éditeur tabulaire pour déployer des métadonnées de modèle de données à l’aide du point de terminaison XMLA. Après le déploiement, le pipeline de mise en production effectue des activités post-déploiement à l’aide des API REST Power BI (non indiquées dans le diagramme).
	Un déclencheur d’approbation de mise en production ou à la demande active le pipeline de mise en production.
	Le pipeline de mise en production publie du contenu dans l’espace de travail de production à l’aide du point de terminaison XMLA (pour les métadonnées du modèle de données) ou des API REST Power BI (pour les fichiers Power BI Desktop, qui peuvent contenir des modèles de données et des rapports). Le pipeline de développement utilise l’interface de ligne de commande (CLI) de l’Éditeur tabulaire pour déployer des métadonnées de modèle de données à l’aide du point de terminaison XMLA. Après le déploiement, le pipeline de mise en production effectue des activités post-déploiement à l’aide des API REST Power BI (non indiquées dans le diagramme).

Les pipelines de mise en production doivent gérer les activités post-déploiement. Ces activités peuvent inclure la définition des informations d’identification du modèle sémantique ou la mise à jour de l’application Power BI pour les espaces de travail de test et de production. Nous vous recommandons de configurer des notifications pour informer les personnes concernées des activités de déploiement.

Conseil

L’utilisation d’un référentiel pour le contrôle de version permet aux créateurs de contenu de créer un processus de restauration. Le processus de restauration peut inverser le dernier déploiement en restaurant la version précédente. Envisagez de créer un ensemble distinct d’Azure Pipelines que vous pouvez déclencher pour restaurer les modifications de production. Réfléchissez soigneusement aux processus et approbations nécessaires pour lancer une restauration. Assurez-vous que ces processus sont documentés.

Pipelines de déploiement Power BI

Un pipeline de déploiement Power BI comporte trois phases : développement, test et production. Vous affectez un espace de travail Power BI unique à chaque étape du pipeline de déploiement. Lorsqu’un déploiement se produit, le pipeline de déploiement promeut les éléments Power BI d’un espace de travail à un autre.

Un pipeline de mise en production Azure Pipelines utilise les API REST Power BI pour déployer du contenu à l’aide d’un pipeline de déploiement Power BI. L’accès à l’espace de travail et au pipeline de déploiement est nécessaire pour les utilisateurs effectuant un déploiement. Nous vous recommandons de planifier l’accès au pipeline de déploiement afin que les utilisateurs de pipeline puissent afficher l’historique des déploiements et comparer le contenu.

Conseil

Lorsque vous séparez les espaces de travail de données des espaces de travail de création de rapports, envisagez d’utiliser Azure Pipelines pour orchestrer la publication de contenu avec plusieurs pipelines de déploiement Power BI. Les modèles sémantiques sont déployés en premier, puis ils sont actualisés. Enfin, les rapports sont déployés. Cette approche vous aide à simplifier le déploiement.

Licences Premium

Les pipelines de déploiement Power BI et le point de terminaison de lecture/écriture XMLA sont des fonctionnalités Premium. Ces fonctionnalités sont disponibles avec la capacité Power BI Premium et Power BI Premium par utilisateur (PPU).

PPU est un moyen économique de gérer la publication de contenu d’entreprise pour les espaces de travail de développement et de test, qui ont généralement peu d’utilisateurs. Cette approche présente l’avantage supplémentaire d’isoler les charges de travail de développement et de test des charges de travail de production.

Notes

Vous pouvez toujours configurer la publication de contenu d’entreprise sans licence Premium, comme décrit dans la deuxième approche de la section du pipeline de mise en production. Dans la deuxième approche, vous utilisez Azure Pipelines pour gérer le déploiement de fichiers Power BI Desktop dans des espaces de travail de développement, de test et de production. Toutefois, vous ne pouvez pas déployer de métadonnées de modèle à l’aide du point de terminaison XMLA, car il n’est pas possible de publier un modèle sémantique au format de métadonnées avec les API REST Power BI. En outre, il n’est pas possible de promouvoir du contenu via des environnements avec des pipelines de déploiement sans licence Premium.

Configuration de la passerelle

En règle générale, une passerelle de données est requise pour l’accès aux sources de données qui résident dans le réseau privé d’une organisation ou dans un réseau virtuel. Les deux objectifs d’une passerelle sont les suivants : actualiser les données importées et afficher un rapport qui interroge une connexion active ou un modèle sémantique DirectQuery (non représenté dans le schéma du scénario).

Lorsque vous utilisez plusieurs environnements, il est courant de configurer des connexions de développement, de test et de production pour différents systèmes sources. Dans ce cas, utilisez des règles de source de données et des règles de paramètre pour gérer les valeurs qui diffèrent entre les environnements. Vous pouvez utiliser Azure Pipelines pour gérer les passerelles à l’aide des opérations de passerelle des API REST Power BI.

Notes

Une passerelle de données centralisée en mode standard est fortement recommandée sur les passerelles en mode personnel. En mode standard, la passerelle de données prend en charge la connexion dynamique et les opérations DirectQuery (en plus des opérations programmées d’actualisation des données).

Supervision du système

Le journal d’activité enregistre les événements qui se produisent dans le service Power BI. Les administrateurs Power BI peuvent utiliser le journal d’activité pour auditer les activités de déploiement.

Vous pouvez utiliser les API d’analyse des métadonnées Power BI pour créer un inventaire de locataire. Les résultats de l’API sont utiles pour vérifier quels éléments ont été déployés dans chaque espace de travail, pour vérifier la traçabilité et pour valider les paramètres de sécurité.

Il existe également un journal d’audit dans Azure DevOps, qui est en dehors du service Power BI. Les administrateurs Azure DevOps peuvent utiliser le journal d’audit pour passer en revue les activités dans les référentiels et pipelines distants.

Contenu connexe

Pour d’autres scénarios utiles qui vous aideront dans les décisions d’implémentation de Power BI, consultez l’article Scénarios d’utilisation de Power BI.