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 :
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.
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 :
Ces étapes sont à refaire à chaque déploiement et pour chaque environnement. C’est assez laborieux.
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.
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 :
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.
Accès Power BI à la base données :
Pour utiliser Power BI Actions :
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 :
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.
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.
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.
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é :
/!\ Ceci n’est valable que si l’ancienne version du rapport Power BI est compatible avec la nouvelle version du backend !
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.
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 :
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)
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 :
Nos takeways :
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é ?