ncmt

powerbi-devops : CI/CD Power BI sur Azure DevOps

Le versioning, les contrôles qualité et le déploiement automatique des rapports Power BI d'une équipe BI, dans Azure DevOps.

en cours · 2026 · alternance, Seqens, direction financière

$ cat probleme.md

L'équipe BI produit des rapports Power BI pour plusieurs directions de l'entreprise. Il fallait les versionner, les faire relire, repérer les écarts de bonnes pratiques avant la recette plutôt qu'après, et les déployer sans manipulation à la main.

$ cat solution.md

Les rapports passent au format PBIP : un dossier par rapport, avec le modèle sémantique et le rapport en fichiers texte. Ils sont versionnés dans Git, rangés par direction et par thème métier, et chaque modification passe par une pull request.

À chaque pull request, un script PowerShell retrouve par git diff les projets touchés. Deux pipelines leur appliquent des règles BPA (Best Practices Analyzer) : Tabular Editor pour les modèles sémantiques, PBI-Inspector pour les rapports. Les erreurs bloquent la fusion. Les avertissements peuvent devenir bloquants par une simple variable, pour que l'équipe s'y mette progressivement.

Une troisième pipeline vérifie les livrables : chaque projet a un README et, pour aller en production, un PV de recette versionné.

Après la fusion sur main, les projets modifiés et déclarés actifs dans un fichier de correspondance sont déployés dans leur workspace Fabric avec fabric-cicd, le modèle sémantique avant le rapport. Le README de chaque projet est publié dans le wiki Azure DevOps, avec un index et une page des destinations de déploiement générés à chaque fois.

J'ai aussi écrit la documentation pour l'équipe BI, qui débute avec Git et les pipelines : comment les pipelines fonctionnent, comment lire un avertissement, quoi vérifier avant un push.

$ open demo

sur mon postepull request vers mainaprès fusion sur mainPower BI Desktoprapport et modèleprojet PBIPdossiers en texte (TMDL)branche Gitcommits, BPA en localenregistrecommitgit diff → projets touchésBPA modèleTabular EditorBPA rapportPBI-InspectorlivrablesREADME, PV de recettemappingworkspace cible déclaré+ relecture de la PRgit pusherreur : on corrige, on repoussefusiondeploy-fabricfabric-cicd, projets actifsworkspace Fabricmodèle, puis rapportpubliepipeline wikiREADME modifiéswiki Azure DevOpsREADME, indexpubliepage des destinations sur mon postePower BI Desktoprapport et modèleprojet PBIPdossiers en texte (TMDL)branche Gitcommits, BPA en localenregistrecommitgit pushpull request vers maingit diff → projets touchésBPA modèleTabular EditorBPA rapportPBI-InspectorlivrablesREADME, PV de recettemappingworkspace cible déclaréerreur : on repousserelecture, fusiondeploy-fabricfabric-cicdpipeline wikiREADME modifiéspubliepublieworkspace Fabricmodèle, puis rapportwiki Azure DevOpsREADME, index
Le chemin d'une modification de rapport. Les quatre contrôles tournent sur chaque pull request ; une erreur bloque la fusion et renvoie sur la branche. Les avertissements BPA passent, sauf si l'équipe décide de les rendre bloquants.

$ cat stack.txt

  • Power BI, format PBIP, TMDL
  • Azure DevOps : Repos, Pipelines YAML, Wiki
  • PowerShell
  • Python
  • Tabular Editor, PBI-Inspector
  • Microsoft Fabric, fabric-cicd

$ cat suite.md

En place : les contrôles BPA à chaque pull request, la vérification des livrables, le déploiement vers Fabric et la publication du wiki.

Ensuite : une procédure en cas d'incident, une échelle de criticité des règles BPA, une alerte quand une pipeline passe avec des avertissements, et le choix du dossier de destination dans le workspace.

$ cd ..

~/projets