Pipelines de build Power BI Project (PBIP) et Azure DevOps pour la validation

La combinaison de l’intégration Git Fabric à Azure DevOps vous permet de connecter un espace de travail à une branche dans un référentiel Azure DevOps, puis de les synchroniser automatiquement entre eux.

L’intégration du format PBIP avec Azure DevOps vous permet d’utiliser Azure Pipelines pour automatiser les pipelines d’intégration continue et de déploiement continu (CI/CD). Ces pipelines traitent les fichiers de métadonnées PBIP, puis appliquent une série de vérifications de qualité à votre développement avant de déployer le tout sur le système de production.

Dans cet article, nous mettons l’accent sur l’intégration continue, puis décrivons comment créer un pipeline Azure DevOps qui garantit les meilleures pratiques pour tous les modèles sémantiques et rapports au sein d’un espace de travail Fabric. En implémentant des tests de qualité automatisés, vous pouvez éviter les erreurs courantes, puis améliorer l’efficacité de l’équipe. Par exemple, cette approche garantit que les nouveaux membres de l’équipe respectent les normes établies pour le développement de modèles sémantiques et de rapports.

Découvrez l’intégration de PBIP et de Git Fabric dans project-overview dans la vue d’ensemble de l’intégration Git fabric.

Le diagramme suivant illustre le scénario de bout en bout avec deux workflows de développement qui déclenchent le pipeline Azure DevOps pour valider la qualité du développement. Le pipeline exécute les actions suivantes :

1. L’utilisateur 1 effectue le développement à l’aide de Power BI Desktop.

   1. Créer une branche depuis la branche principale à l’aide de VS Code (feature/datasetchange)
   2. Apporter des modifications au modèle sémantique à l’aide de Power BI Desktop
   3. Valider les modifications apportées à la branche du référentiel distant à l’aide de VS Code
   4. Créer une demande de tirage (pull request) vers la branche principale à l’aide d’Azure DevOps

2. En même temps, l’utilisateur 2 effectue le développement à l’aide d’un autre espace de travail Fabric.

   1. Créer une branche depuis la branche principale à l’aide de Fabric Git (fonctionnalité/rapportchange)
   2. Apporter des modifications au rapport dans l’espace de travail Fabric
   3. Valider les modifications apportées à la branche du référentiel distant à l’aide de Fabric Git
   4. Créer une demande de tirage (pull request) vers la branche principale à l’aide d’Azure DevOps

3. Le responsable de l’équipe examine les demandes de tirage (pull request), puis synchronise les modifications apportées à l’espace de travail d’équipe à l’aide de Fabric Git.

4. La demande de tirage (pull request) déclenche le pipeline Azure DevOps pour inspecter la qualité du développement de modèles sémantiques et de rapports.

Remarque

Dans cet exemple, le pipeline utilise deux outils de la communauté open source qui permettent à un développeur d’appliquer des règles de meilleures pratiques (personnalisables) aux métadonnées des modèles sémantiques et des rapports dans un dossier Projet Power BI :

• Tabular Editor et règles de meilleures pratiques
• PBI Inspector

Une approche similaire à l’exemple de cet article s’appliquera à d’autres outils de la communauté. Cet article ne fouille pas dans les spécificités des outils de la communauté mentionnés précédemment, ni la création et la modification de règles. Pour obtenir des informations détaillées sur ces rubriques, veuillez consulter les liens fournis. Cet article met l’accent sur le processus d’établissement d’une porte de qualité entre le contrôle de code source et l’espace de travail Fabric. Il est important de noter que les outils de la communauté référencée sont développés par des contributeurs tiers et que Microsoft ne leur offre pas de support, ni de documentation.

Étape 1 : connecter l’espace de travail Fabric à Azure DevOps

Connecter l’espace de travail Fabric à Azure DevOps :

Quand l’intégration Git Fabric termine l’exportation de vos éléments d’espace de travail, votre branche Azure DevOps contient un dossier pour chaque élément de votre espace de travail :

Étape 2 : créer, puis exécuter un pipeline Azure DevOps

Pour créer un pipeline :

1. Sous l’onglet Pipelines du menu de navigation de gauche, sélectionnez Créer un pipeline :

   

2. Sélectionnez Azure Repos Git, puis sélectionnez le premier référentiel (le même référentiel connecté à l’espace de travail Fabric) :

   

   

3. Sélectionnez Pipeline de démarrage.

   

   Le code YAML suivant apparaît dans l’éditeur :

   

4. Copiez, puis collez le code YAML du pipeline en mode développeur Power BI dans le pipeline que vous avez créé :

   

   

5. Sélectionnez Enregistrer et exécuter pour valider votre nouveau pipeline vers le référentiel.

   

   

Azure DevOps exécute le pipeline et démarre deux travaux de build en parallèle :

• Build_Datasets
  • Télécharge les binaires de Tabular Editor.
  • Téléchargez les règles par défaut de Best Practice Analyzer. Pour personnaliser les règles, ajoutez Rules-Dataset.json à la racine du référentiel.
  • Parcourez tous les dossiers d’éléments de modèle sémantique, puis exécutez les règles BPA de l’éditeur tabulaire.
• Build_Reports
  • Téléchargez les fichiers binaires de PBI Inspector.
  • Téléchargez les règles par défaut de PBI Inspector. Pour personnaliser les règles, ajoutez Rules-Report.json à la racine du référentiel.
  • Parcourez tous les dossiers d’éléments de rapport, puis exécutez les règles de Power BI Inspector.

À la fin de l’exécution, Azure DevOps crée un rapport de tous les avertissements et erreurs rencontrés :

Sélectionnez le lien pour ouvrir une vue plus détaillée des deux travaux :

Si votre rapport ou modèle sémantique ne respecte pas une règle avec un niveau de gravité plus élevé, la build échoue et l’erreur est mise en surbrillance :

Étape 3 : définir des stratégies de branche

Une fois le pipeline opérationnel, activez les stratégies de branche sur la branche principale. Cette étape garantit qu’aucune validation ne peut être effectuée directement dans le principal. Une « demande de tirage (pull request) » est toujours nécessaire pour fusionner, puis ramener les modifications dans la branche principale et vous pouvez configurer le pipeline pour qu’il s’exécute avec chaque demande de tirage (pull request).

1. Sélectionnez Branches>Branche principale>Stratégies de branches :

   

2. Configurez le pipeline créé en tant que stratégie de build pour la branche :

   

   

Étape 4 : créer une demande de tirage (pull request)

Si vous revenez à votre espace de travail Fabric, apportez une modification à l’un des rapports ou modèles sémantiques, puis tentez de valider la modification, vous recevez l’erreur suivante :

Vous pouvez uniquement apporter des modifications à la branche principale par le biais d’une demande de tirage (pull request). Pour créer une demande de tirage (pull request), extrayez une nouvelle branche pour apporter les modifications :

Créez une branche directement depuis l’espace de travail Fabric :

1. Dans le volet Contrôle de code source, sélectionnez Extraire une nouvelle branche, puis indiquez un nom pour la branche.

   

   

   Vous pouvez également choisir d’effectuer le développement dans un espace de travail distinct, isolé ou dans Power BI Desktop. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Développer à l’aide d’un autre espace de travail.

2. Validez vos modifications apportées à cette nouvelle branche.

   

3. Après la validation, créez une demande de tirage (pull request) dans la branche principale depuis le portail Azure DevOps.

   

   

Le flux de travail de demande de tirage (pull request) vous permet non seulement de valider, puis de passer en revue les modifications, mais également de déclencher automatiquement le pipeline.

Si une erreur de gravité élevée figure dans l’une des règles, vous ne pouvez pas finaliser la demande de tirage (pull request), puis fusionner les modifications dans la branche principale.

Découvrez-en plus sur l’intégration de PBIP et de Git Fabric dans le billet de blog.