Éléments importants à prendre en compte pour l’ALM

Effectué

Les architectes de solution doivent définir la stratégie de l’Application lifecycle management (ALM) pour le projet. Cette tâche fait partie du processus visant à aider l’organisation à établir une gouvernance appropriée pour la solution.

Stratégie relative à l’environnement

Un environnement est un conteneur qui stocke, gère et partage les données métier, les applications, les flux, les connexions et d’autres actifs, ainsi que les autorisations qui permettent aux utilisateurs de l’organisation d’utiliser les ressources.

Un environnement tient lieu de conteneur permettant de séparer les applications susceptibles d’avoir des rôles, des exigences de sécurité ou des publics cibles différents. Votre façon d’utiliser les environnements dépend de votre organisation et des applications que vous tentez de créer. Par exemple :

• Vous pouvez décider de créer toutes vos applications dans un seul environnement.
• Vous pouvez créer des environnements distincts qui regroupent les versions de test et de production de vos applications.
• Vous pouvez créer des environnements distincts correspondant à des équipes ou départements spécifiques de votre société, chacun comportant les données et applications pertinentes pour chaque audience.
• Vous pouvez créer des environnements distincts pour différentes succursales mondiales de votre société.

L’élaboration d’une stratégie d’environnement implique de configurer les environnements et d’autres couches de sécurité des données d’une manière capable de prendre en charge le développement productif de votre organisation, tout en sécurisant et en organisant les ressources. Il est important pour les objectifs suivants d’établir une stratégie visant à gérer l’approvisionnement des environnements et leur accès, et à contrôler les ressources en son sein :

• Sécuriser les données et les accès.
• Comprendre comment utiliser correctement l’environnement par défaut.
• Gérer le nombre correct d’environnements pour éviter la prolifération et maintenir la capacité.
• Faciliter l’Application Lifecycle Management (ALM).
• Organiser les ressources en partitions logiques.
• Faciliter les opérations (et le travail du service d’assistance) consistant à identifier les applications qui sont en production en les plaçant dans des environnements dédiés.
• Veiller à ce que les données soient stockées et transférées dans des régions géographiques acceptables (pour des raisons de performance et de conformité).
• Assurer l’isolement des applications en cours de développement.

Les types d’environnement suivants sont disponibles dans Microsoft Power Platform :

• Bac à sable : un environnement de bac à sable désigne tout environnement hors production dans Dataverse. Isolé de la production, un environnement de bac à sable est l’endroit idéal pour développer et tester en toute sécurité des modifications d’application avec peu de risques.
• Production : l’environnement dans lequel les applications et autres logiciels sont mis en service pour l’usage auquel ils sont destinés.
• Community (développeur) : l’offre Community Power Apps donne à un utilisateur l’accès aux fonctionnalités Power Apps Premium, à Dataverse et à Microsoft Power Automate pour un usage individuel uniquement. Cet environnement est principalement destiné à des fins d’apprentissage. Un environnement de développement est un environnement dédié à un seul utilisateur, qui ne peut pas être utilisé pour exécuter ou partager des applications. Un environnement de l’offre Community peut faire partie d’un pipeline Azure DevOps.
• Par défaut : un environnement par défaut unique est automatiquement créé pour chaque abonné ; il est partagé par tous les utilisateurs de cet abonné. L’environnement par défaut est utilisé par les services Microsoft 365.
• Test : les environnements de test permettent d’essayer de nouvelles fonctionnalités ou d’exécuter des preuves de concept. Les environnements de test sont automatiquement supprimés après 30 jours.

Important

L’architecte de solution doit définir le nombre d’environnements requis, leurs objectifs et les dépendances entre les environnements. Au minimum, une bonne pratique ALM consiste à utiliser un environnement de test avant de déployer quoi que ce soit dans l’environnement de production. Cette pratique vous garantit non seulement de disposer d’un emplacement pour tester votre application, mais aussi de pouvoir tester le déploiement.

Pour en savoir plus, consultez Environnements et Stratégie d’environnement.

Gérer les solutions et autres codes et composants non compatibles avec des solutions

Les projets Microsoft Power Platform sont constitués de composants qui peuvent être packagés dans des solutions dans des environnements et de composants qui ne peuvent pas être ajoutés à des solutions. Les composants qui ne peuvent pas êtres ajoutés comprennent les composants déployés dans Azure, les données de configuration et les états Power BI. Le plan ALM doit prendre en compte la manière de gérer ces composants non compatibles avec des solutions.

L’architecte de solution doit décider si le processus Application Lifecycle Management sera géré à l’aide de solutions ou du contrôle de code source. Traditionnellement, les projets Microsoft Power Platform étaient davantage centrés sur l’environnement, mais beaucoup s’orientent maintenant vers le contrôle de code source.

Si vous utilisez une approche centrée sur l’environnement, alors :

• L’environnement de développement est la copie de référence de toutes les modifications.
• Les modifications sont promues directement ainsi : dev> test> production.

Si vous utilisez une approche centrée sur le contrôle de code source, alors :

• Le contrôle de code source est le maître.
• L’environnement de développement est recréé à partir du contrôle de code source (ce processus peut être automatisé et reproductible).
• Les modifications de l’environnement de développement sont archivées dans le contrôle de code source.

Une approche centrée sur le contrôle de code source vous incite à avoir un maître définitif et la possibilité de recréer des environnements de développement pour toutes les versions suivies. Actuellement, Microsoft favorise l’ALM centrée sur le contrôle de code source et développe des outils dans ce sens.

Remarque

Dans l’idéal, tous les environnements hors production devraient être jetables. Autrement dit, les environnements de développement et de test peuvent être supprimés et recréés sans entraîner aucune perte.

L’utilisation d’une approche centrée sur le contrôle de code source rend possible une approche Azure DevOps avec des pipelines de build et de mise en production. L’adoption d’une approche centrée sur l’environnement implique que vous devez définir le flux de travail pour les créateurs et les développeurs d’applications. L’architecte de solution doit définir comment et par qui est décidée la promotion de l’application d’un environnement à un autre, du développement à la production.

L’architecte de solution devra également définir comment configurer chaque environnement et chercher des moyens de faciliter cette tâche.

Travail d’équipe

Par rapport au développement d’applications traditionnel, les projets Microsoft Power Apps diffèrent par deux aspects clés :

• La manière dont les différents membres de l’équipe de projet travaillent ensemble pour créer la solution
• La méthodologie de développement

Power Apps est une plateforme avantageuse pour les développeurs professionnels et les développeurs citoyens. Dans un environnement de développement traditionnel, seuls des développeurs professionnels pouvaient être impliqués dans la création d’une application proprement dite. Avec Power Apps, toute personne a le pouvoir de créer les applications dont elle a besoin en utilisant des fonctionnalités avancées qui n’étaient auparavant disponibles que pour les développeurs professionnels. Power Apps démocratise la création d’applications métier personnalisées en permettant aux utilisateurs de créer des applications métier personnalisées enrichies de nombreuses fonctionnalités sans écrire de code.

Avec Power Apps, vous pouvez créer rapidement une version utilisable de votre application, car Power Apps offre une expérience de développement WYSIWYG (ce que vous voyez est ce que vous obtenez). Vous pouvez tester l’application fonctionnelle dès le début du processus de développement et, si de nouvelles exigences se présentent, vous pouvez ajouter de nouvelles fonctionnalités à la version suivante.

Les éventuels problèmes de personnalisation et de développement de composants dans Microsoft Power Platform sont notamment les suivants :

• Microsoft Power Platform ne prend pas en charge la gestion des versions des composants (sauf pour les applications canevas).
• Différents utilisateurs ne peuvent pas travailler simultanément sur le même composant Microsoft Power Platform.
• Les applications pilotées par modèle comportent plusieurs composants, chacun ayant son propre éditeur, ce qui permet de répartir le travail entre les créateurs. À l’inverse, les applications canevas n’ont qu’un seul éditeur et une seule personne à la fois peut travailler sur une application. En utilisant des composants de canevas, vous pouvez faire en sorte que plusieurs créateurs travaillent simultanément sur la même application.

Les architectes de solution doivent établir le flux de travail des modifications et de leur promotion pour les créateurs d’applications. La communication proactive et l’affectation du travail doivent être gérées pour réduire les conflits entre les créateurs.

Vous pouvez réduire le risque de dispute entre les créateurs en créant un environnement individuel pour chacun. Les environnements individuels des créateurs assurent l’isolement et le suivi, mais nécessitent un effort supplémentaire pour fusionner le travail et résoudre les conflits. Un environnement de création partagé peut être moins complexe, mais il n’assure pas l’isolement entre les créateurs d’applications et offre un suivi des modifications moins détaillé.

Contrôle de code source

Même si vous adoptez une approche centrée sur l’environnement, vous devez toujours décider de l’emplacement de résidence de la copie de référence des solutions et du code.

Les actifs de code de développement compatibles avec les solutions (tels que les plug-ins, les composants de code PCF et les scripts de formulaire (transpilés à partir de TypeScript)) doivent être « construits » dans un environnement de build et non sur le bureau du développeur. Une fois construits, les actifs doivent être déployés dans un environnement à partir duquel la solution principale sera exportée, ou être intégrés à une solution qui sera installée.

Outils

Microsoft fournit plusieurs outils et applications que vous pouvez utiliser avec l’ALM dans Microsoft Power Platform :

• Centre d’administration de Microsoft Power Platform : fournit aux administrateurs un portail unifié pour créer et gérer les environnements.
• Outils Power Apps Build Tools : permettent d’automatiser les tâches courantes de build et de déploiement en lien avec Power Apps à l’aide d’Azure DevOps.
• GitHub : système bien connu de contrôle de version.
• Configuration Migration Tool : vous permet de déplacer les données de configuration et/ou de référence d’un environnement à un autre.
• Package Deployer : vous permet de déployer des packages d’actifs sur des instances Dataverse. Les packages peuvent être constitués de fichiers de solution et de fichiers plats, de code personnalisé, de fichiers HTML et de données.
• Packager de solution : un outil capable de décompresser un fichier de solution compressé en plusieurs fichiers XML et autres fichiers plus faciles à gérer par un système de contrôle de code source.
• Microsoft Power Apps CLI : une interface de ligne de commande qui permet aux développeurs de créer des composants de code.
• Module PowerShell de déploiement de package : utilisé pour déployer des packages dans l’environnement Dataverse.
• Module PowerShell de vérificateur Power Apps : interagit avec le service de vérificateur de Power Apps pour vous permettre d’exécuter des analyses statiques et de télécharger les résultats.

Remarque

Les actions GitHub pour Microsoft Power Platform sont actuellement en version préliminaire.