Mise en place d’un déploiement automatisé de Power BI dans un environnement Azure et Azure DevOps

Merci à Gabrielle PANIZZOLI avec qui j'ai eu la chance de travailler sur le sujet !

Dans le cadre du développement d’un projet sur une infrastructure Azure, avec Azure DevOps comme outil d’Intégration Continue (CI) / usine de déploiement, et Power BI en front-end, nous souhaitions mettre en place le déploiement automatisé de Power BI.

Pour ceux qui ne connaissent pas Power BI, il s’agit d’un outil low-code - voire no-code - de visualisation de données développé par Microsoft, disponible aussi bien sous forme de client lourd que d’outil SaaS (Software as a Service) en ligne. On utilise l’interface graphique du client lourd pour créer les vues et graphiques désirés, puis on les enregistre sous forme de rapport en format .pbix. Dans notre cas, on envoie ensuite notre rapport dans l’outil SaaS, et on déploie l’application à partir de ce rapport.

Power BI n’est pas vraiment pensé pour être déployé automatiquement :

• Il n’y aucune documentation expliquant comment le faire.
• Nous avons contacté des experts Microsoft qui nous ont demandé de leur faire un retour si nous réussissions, car eux non plus ne savaient pas comment faire.
• Il existe une API et des commandes PowerShell mais elles ne permettent pas d’effectuer l’ensemble des actions nécessaires pour automatiser un déploiement.
• Depuis environ 1 an, Power BI Premium permet de gérer le déploiement des rapports Power BI d’un environnement à l’autre. D’après les retours que nous avons eus, il n’est pour le moment pas possible de l’intégrer au déploiement continu d’une infrastructure. N’ayant pas accès à Power BI Premium, nous n’avons pas pu explorer cette piste.

Nous avons donc tenté de récolter des informations d’un peu partout (documentation Microsoft, forums, collègues, centre de compétences et experts Microsoft…) afin de finalement trouver une solution qui pouvait nous convenir.

Nous sommes conscients qu’il ne s’agit que d’une façon de faire parmi d’autres. Elle est un exemple dans un contexte précis de ce qu’il est possible de faire.

Contexte et raisons derrière notre besoin d’automatisation du déploiement de Power BI

Douleur

Nous travaillions sur 3 environnements : Développement, Préproduction et Production. Dans Power BI, ces environnements sont nommés des Workspaces.

Notre infrastructure et notre backend étaient déployés automatiquement via la CI sur l'environnement souhaité, mais pas notre rapport Power BI. Il nous fallait déployer manuellement la bonne version de ce rapport et le connecter à la base de données de l’environnement cible.

Processus de déploiement manuel de Power BI :

• Générer un rapport Power BI sur le client lourd et l’envoyer vers le Workspace correspondant à l’environnement cible.
• Changer la datasource (source de données) pour référencer la base de données de l’environnement cible à laquelle Power BI doit se connecter. Dans notre cas, nous modifions un paramètre dans le menu “settings” du dataset (jeu de données) dans le Workspace cible.
• Mettre à jour l’utilisateur technique qui a les droits d’accès à la datasource.
• Lancer le refresh (mise à jour) du rapport.
• Connecter le rapport à l'application.
• Mettre à jour l’application.

Ces étapes sont à refaire à chaque déploiement et pour chaque environnement. C’est assez laborieux.

Objectif

Notre objectif était donc de déployer l’Application Power BI automatiquement en même temps que l’infrastructure et le backend. Lancer un déploiement via la CI sur un environnement cible déploierait donc l’infrastructure et le backend sur cet environnement et y déploierait ensuite la partie Power BI.

Étapes du déploiement automatisé

Dans les grandes lignes

1. Envoyer la nouvelle version du rapport Power BI sur le Workspace de Développement à la main (comme décrit précédemment) :
   1. Créer la version sur le client lourd.
   2. Pousser le rapport du client lourd vers l’outil SaaS de Power BI - dans notre cas, sur le Workspace de Développement.
2. Indiquer la version du rapport Power BI souhaitée côté backend. Nous la passerons à la CI. Dans notre cas précis, nous avons finalement décidé de systématiquement déployer la même version sur tous les environnements, et nous renommons donc juste la dernière version du rapport que l’on souhaite déployer en “rapport.pbix” sur l’outil SaaS.
3. Créer un job de déploiement du rapport Power BI dans la CI. Ce job s’exécute après le déploiement de l’infrastructure et du backend. Ce job effectuera automatiquement les étapes manuelles citées plus haut, à savoir :
   1. envoyer la version du rapport Power BI désirée dans le bon Workspace,
   2. l’associer à la bonne datasource - à savoir la base de données de l’environnement cible,
   3. lui associer l’utilisateur technique qui a les droits nécessaires sur la base de données cible,
   4. relier le rapport à l’application,
   5. mettre en place un refresh quotidien du dataset du rapport Power BI.

Détails du job de déploiement Power BI

Comme je l’ai évoqué, nous avons fait pas mal de recherches et échangé avec de nombreuses personnes mais il semble que Power BI ne soit pas pensé pour être déployé automatiquement. La méthode que nous avons trouvée peut donc sembler un peu compliquée. Le job va utiliser un mélange de code PowerShell, d'appels à l’API et de la task Azure DevOps “Power BI Actions” (qui est une extension tierce, non certifiée par Microsoft) pour :

• aller chercher le fichier Power BI (format .pbix) désiré sur le Workspace de Développement, et le télécharger sur le serveur lancé par Azure DevOps pour le déploiement via la CI (via Powershell / API),
• l’uploader sur le Workspace désiré (via Power BI Actions),
• permettre à l’utilisateur technique (celui qui a accès à la base de données) de prendre le contrôle (“ownership”) sur le dataset (via Power BI Actions),
• associer la bonne datasource au dataset Power BI (via Power BI Actions),
• mettre à jour les identifiants de l’utilisateur technique pour qu’il puisse accéder à la datasource (via Powershell / API),
• refresh le dataset (via Power BI Actions).

Informations complémentaires

Le déploiement de l’application Power BI (connexion de l’application au bon rapport) doit être effectué une première fois manuellement via l'interface Power BI. Par la suite, nous écrasons la version du rapport associée à l’application déployée par la nouvelle version, qui porte le même nom. Nous n’avons pas trouvé comment automatiser le déploiement d’une nouvelle version sans procéder ainsi.

Les tâches Power BI Actions n’attendent pas de voir si la task a réussi ou pas dans la CI. En cas d’erreur du refresh du dataset, la task associée n’échoue pas dans la CI. La task de la CI se contente de lancer le refresh, sans attendre de voir s’il réussit ou échoue. Nous avons écrit un script pour vérifier si le Refresh Dataset a réussi, et faire échouer la CI en cas d’échec du refresh.

Il n’est pas possible de créer automatiquement un scheduled refresh quotidien pour le dataset de Production. Nous n'avons pas réussi à activer le schedule (cron) de Power BI automatiquement. On peut créer le scheduled refresh manuellement via l’interface, mais il est supprimé lorsque l’on écrase un rapport, et il faudrait donc le reconfigurer à chaque déploiement.  Nous avons donc créé un job dans la CI qui lance un refresh sur le Workspace Power BI de production tous les matins.

Nous n'avons pas trouvé comment mettre l’application à jour automatiquement.

Étapes techniques nécessaires & gestion des droits

Accès Power BI à la base données :

• Créer un utilisateur technique par environnement.
• Ajouter l’utilisateur au groupe d’utilisateurs de la base de données (avec les droits nécessaires - dans notre cas lecture seule).

Pour utiliser Power BI Actions :

• Ajouter la task “Power BI Actions” via l’interface Azure DevOps.
• Dans Azure DevOps, créer un “Power BI Service Connection”. Un Service Connection permet à Azure DevOps d’accéder à d’autres ressources externes - dans notre cas c’est un Service Connection spécifique à Power BI. Il en faut un par utilisateur technique (nécessaire pour Power BI Actions). Azure DevOps pourra donc effectuer des actions dans Power BI au nom de l’utilisateur technique Power BI.
• Pour utiliser la CI, vous avez normalement un Service Principal (SP) rattaché à chacun de vos environnements (ou subscriptions) Azure. Dans Azure DevOps, créer un Power BI Service Connection par SP. Ceci est nécessaire pour la task “upload” de Power BI Actions.
• Pour que Power BI Actions ait les droits nécessaires sur Power BI SaaS :
  • Créer un groupe de sécurité Azure contenant le SP
  • Ajouter ce groupe de sécurité dans Power BI, en tant que groupe de sécurité pouvant utiliser les APIs Power BI (il faut avoir les droits d’administrateur sur l’outil).
  • Dans Power BI SaaS, donner les droits à l’utilisateur technique et au SP pour accéder au Workspace associé.

Mieux comprendre les raisons derrière nos choix

Pourquoi ne pas avoir automatisé le déploiement du rapport vers l’outil SaaS ?

Suite à nos divers échanges et à ce que nous avons trouvé comme documentation, cela ne se justifiait pas à nos yeux. Nous aurions pu versionner le fichier .pbix :

• Sur GIT, mais comme le .pbix contient des données, nous avons préféré éviter de le faire : nous souhaitions éviter d’exposer nos données (notamment celles de production) sur GIT, et éviter d’y versionner inutilement des fichiers lourds.
• Il existe un format .pbit sans données, mais a priori pour le moment ce format n’est pas géré par l’outil SaaS.
• Dans un storage account Azure (le stockage objet offert par ce cloud provider, équivalent à AWS S3), mais il aurait de toute façon fallu des étapes pour générer le .pbix, l’envoyer dans le storage account et ensuite le récupérer depuis le storage account.

C’est tout aussi simple de juste pousser le fichier .pbix depuis le client lourd vers l'outil Power BI SaaS.

Nous assumons le fait que les versions sont gérées dans le Workspace de Développement de l'outil Power BI SaaS.

Pourquoi mélanger Powershell cmdlets, appels API et Power BI Actions ?

Tout simplement parce qu’aucun de ces outils ne gère tout ce dont nous avons besoin.

Entre temps, il nous a été indiqué qu’il serait peut-être possible de tout gérer uniquement en Powershell cmdlets et appels API. Comme nous n’avons pas testé si la commande fonctionne correctement et que cela implique de scripter tout ce qui fonctionne déjà chez nous avec Power BI Actions, nous n’allons pas changer cela dans l’immédiat.

Pour rappel : Power BI Actions n’est pas un outil officiel certifié par Microsoft.

Pourquoi télécharger le fichier .pbix sur le serveur de déploiement et le reuploader ?

Il est possible de déplacer le rapport d’un Workspace à un autre, mais il reste par défaut associé au dataset du Workspace précédent. Il faudrait ensuite déplacer le dataset, et associer le Workspace et le dataset, ce qui est contraignant - et nous n’avons pas vraiment trouvé comment faire pour déplacer le dataset.

De plus, télécharger le .pbix n’est pas gênant dans notre cas car c’est sur un serveur temporaire.

Comme expliqué dans l’introduction, Power BI Premium pourrait aider à gérer le déploiement entre les Workspaces, mais il faudrait trouver un moyen de l’associer à Azure DevOps pour déployer la bonne version sur le bon Workspace.

Comment repasser sur une version antérieure si la nouvelle version du rapport Power BI ne fonctionne pas ou ne se déploie pas correctement ?

Nous avons mis en place un système de déploiement de version de backup. En cas de soucis avec la nouvelle version du rapport, le backup permet à un contributeur de rapidement brancher manuellement l’application sur le rapport en backup déployé.

Le déploiement du rapport de backup fonctionne de la même manière que pour le fichier déployé :

• Nous précisons quelle sera la version de backup en même temps que nous précisons la version déployée.
• Nous écrasons le fichier de backup précédent avec le nouveau backup.

/!\ Ceci n’est valable que si l’ancienne version du rapport Power BI est compatible avec la nouvelle version du backend !

Pourquoi passe-t-on par une pipeline Azure DevOps pour le refresh quotidien des datasets plutôt que par le Scheduled Refresh Power BI :

Quand la configuration du schedule est faite à la main, tout fonctionne.

Quand la configuration est faite via la CI, cela lance le refresh et tourne plusieurs minutes, puis cela échoue avec l’erreur : “Processing error : The credentials provided for the SQL source are invalid. “

Il s’agirait a priori d’une expiration du token d'authentification généré par la CI, qui n’est valable qu’une heure. Ainsi, le scheduled refresh ne fonctionne que s’il est effectué dans l’heure suivant le déploiement. Dans notre cas, le refresh effectué via la CI refait quotidiennement toute la mise à jour des identifiants avant chaque refresh.

Peut-on automatiser la création d'alertes sur Power BI ?

En cas d'échec du refresh du dataset, l’alerte est par défaut envoyée à l'owner du dataset (en l’occurrence, notre utilisateur technique).

Une option pourrait être de redonner l’ownership à la personne qui souhaite recevoir les alertes en fin de déploiement sauf que :

• tout repose sur une seule personne,
• il faut spécifier dans le code le nom de la personne qui recevra ces alertes,
• donc changer le code à chaque changement du récepteur des alertes (congés, sortie de mission…).

Nous avons opté pour un ajout à la main des emails souhaités sur l’environnement de Production (cela n’est pas indispensable sur les autres environnements)

Conclusion

Dans l’ensemble, nous sommes plutôt satisfaits de notre solution. L’expérience a été douloureuse et nous avons cru à plusieurs reprises devoir laisser tomber l’idée d’avoir un déploiement automatisé de Power BI. Le résultat final n’est pas optimal et nous avons dû utiliser plusieurs méthodes différentes pour parvenir à nos fins, mais cela fonctionne ! Chaque déploiement de l’infrastructure déploie aujourd’hui la version souhaitée du rapport Power BI sur l’environnement cible.

Cela nous permet :

• de pouvoir déployer n’importe quand sans avoir à faire intervenir la personne chargée de gérer les versions des rapports Power BI,
• d’être sûrs de toujours avoir la dernière version du rapport Power BI à chaque déploiement,
• d’avoir des Workspaces Power BI “propres” - chaque nouveau rapport écrase le précédent, et nous n’avons donc pas à gérer le stockage d’innombrables versions ailleurs que sur le Workspace de Développement,
• d’être sereins sur l’état de santé de l’application, car le refresh du dataset est intégré dans la CI, et toute l’équipe est alertée s’il échoue.

Nos takeways :

• L’outil n’est pas pensé pour être automatisé :
  • Tout n’est pas automatisable : nous n’avons pas trouvé comment mettre à jour l’application après avoir déployé une nouvelle version d’un rapport, ou comment déplacer un dataset d’un workspace à un autre par exemple.
  • Ce que nous avons pu automatiser, nous l’avons fait à travers un mélange de Powershell cmdlets, appels API et Power BI Actions - ce dernier n’étant même pas un outil officiel.
• Power BI Actions n’a pas réellement de documentation. Nous avons dû avancer à tâtons, mais l’outil est réellement utile dans un environnement Azure DevOps. Être administrateur sur l'outil Power BI aurait été un grand plus et un gain de temps pour nos tests.

Avec l’essor de l’Infrastructure as Code, peut-être qu’un des enjeux pour Power BI dans les mois à venir serait de nous fournir les outils nécessaires pour faciliter le déploiement automatisé ?