Introduction
La Power Platform est une suite de solutions technologiques dites « low code », à destination d’un public varié. En effet, de la petite application de productivité personnelle réalisée par un Citizen Developer[1] à l’outil cœur de métier développé par la DSI, les usages sont larges et très divers. La population d’utilisateurs, dont les exigences et les attentes sont assez hétérogènes, ne cesse de croître, d’où l’impératif de comprendre et maîtriser un minimum de bonnes pratiques, outils et méthodologies afin de s’assurer du bon usage de ces technologies dans un cadre professionnel.
Si les bonnes pratiques d’ALM (Application Lifecycle Management ou Gestion du cycle de vie des applications en français) sont encore peu connues des Citizen Developers, elles sont en revanche largement utilisées chez les Pro Developers, qui réclament à juste titre des outils pour automatiser leurs déploiements sur la PowerPlatform et se conformer ainsi à l’état de l’Art de la gouvernance IT concernant les activités de développement d’applications et logiciels.
Dans ce qui suit nous allons donc, en pratique, comprendre comment mettre en œuvre différents pipelines sur Azure DevOps pour nous permettre de sauvegarder le code source de nos applications sur Git, et bien sûr automatiser le déploiement d’une solution hébergée depuis un environnement de développement vers un environnement de production.
[1] Citizen Developer : A citizen developer is an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT. (Gartner 2022)
Les environnements PowerPlatform
La première étape de mise en place d’un ALM consiste à créer à minima deux environnements Power Platform : l’un qui sera utilisé par les équipes des développeurs pour travailler sur la création et la maintenance des applications (que nous appellerons environnement de DEV), et un qui sera utilisé par les utilisateurs finaux des applications (environnement de PROD).
Vous pouvez mettre en place également des environnements intermédiaires permettant par exemple aux équipes de testeurs de vérifier les livraisons avant de valider leur déploiement en production.
Note importante : ces environnements doivent impérativement avoir une base de données Dataverse[1], même si celle-ci n’est pas utilisée dans vos applications.
[1] Dataverse : base de données intégrée de la Power Platform : https://powerplatform.microsoft.com/fr-fr/dataverse/
Les « solutions » Power Platform
L’activation d’une base de données Dataverse sur un environnement Power Platform nous permet d’utiliser les « solutions » : une solution Power Platform est un conteneur qui va accueillir tous les composants de votre application, aussi simple soit elle (même si elle ne comporte qu’une application Canvas).
Les composants peuvent être par exemple une application Power Apps Canvas, un flux Power Automate Cloud ou Desktop, un rapport Power BI, etc… Mais aussi une variable d’environnement, une table Dataverse, un rôle de sécurité…
La bonne pratique est de créer une solution par « business use case » (cas d’usage métier) : par exemple une application de gestion de RTT va peut-être être composée d’une application PowerApps Canvas à destination de tous les collaborateurs, et d’une seconde uniquement réservée aux RH qui leur permet de déclarer des RTT obligatoires. Le « use case » étant « la gestion des RTT », ces deux applications seront logiquement dans la même solution. Si vous avez un flux PowerAutomate Cloud qui envoie des notifications aux collaborateurs sur leur solde de RTT à chaque fin de mois, il sera également dans cette même solution.
Une solution peut être exportée d’un environnement en un fichier zip versionné, puis importée vers un autre environnement : c’est le mécanisme de livraison de la Power Platform.