Bases d’ALM avec Microsoft Power Platform
Cet article décrit les composants, les outils et les processus nécessaires pour implémenter la gestion du cycle de vie des applications (ALM).
Environnements
Les environnements sont un espace pour stocker, gérer et partager les données d’entreprise, les applications et les processus d’entreprise. Ils servent également de conteneurs pour séparer des applications qui pourraient avoir différents rôles, exigences de sécurité ou publics cibles. Chaque environnement ne peut comporter qu’une seule base de données Microsoft Dataverse. Pour en savoir plus, consultez Présentation des environnements.
Important
Lorsque vous créez un environnement, vous pouvez choisir d’installer des applications Dynamics 365, telles que Dynamics 365 Sales et Dynamics 365 Marketing. Il est important de déterminer à ce moment si ces applications sont requises ou non car elles ne peuvent pas être désinstallées ou installées ultérieurement. Si vous ne construisez pas sur ces applications et n’en aurez pas besoin à l’avenir, nous vous recommandons de ne pas les installer dans vos environnements. Cela vous évitera des complications de dépendance lorsque vous distribuerez des solutions entre des environnements.
Types d’environnements utilisés dans ALM
À partir du Centre d’administration de Power Platform, vous pouvez créer ces types d’environnements Power Platform :
Sandbox Un sandbox environnement est tout environnement non productif Dataverse. Isolé de la production, un environnement sandbox désigne le lieu pour développer et tester en toute sécurité les modifications apportées à l’application avec peu de risques. Les environnements bac à sable incluent des fonctionnalités qui seraient nuisibles dans un environnement de production, telles que les opérations de réinitialisation, de suppression et de copie. Plus d’informations : Gérer les environnements bac à sable
Production Le environnement où les applications et autres logiciels sont mis en service pour leur utilisation prévue.
Développeur (anciennement appelé Communauté). Le Plan Développeur Power Apps vous donne accès à la fonctionnalité Premium Power Apps, Dataverse et Power Automate pour usage individuel. Ce plan est principalement destiné à construire et à tester avec Power Apps, Power Automate et Microsoft Dataverse ou à des fins d’apprentissage. Un environnement de développeur est un environnement mono-utilisateur et ne peut pas être utilisé pour exécuter ou partager des applications de production.
Par défaut Un seul paramètre par défaut environnement est automatiquement créé pour chaque locataire et partagé par tous les utilisateurs de ce locataire. Le locataire identifie le client, qui peut avoir un ou plusieurs Microsoft abonnements et services qui lui sont associés. Chaque fois qu’un nouvel utilisateur s’inscrit à Power Apps, il est automatiquement ajouté au rôle Créateur d’environnement par défaut. L’environnement par défaut est créé dans la région la plus proche de la région par défaut du client Microsoft Entra et est nommé : « {nom du client Microsoft Entra} (par défaut) »
Créez et utilisez l’environnement correct à une fin spécifique, telles que le développement, le test ou la production.
Pour plus d’informations sur les environnements, voir : Présentation des environnements.
Qui devrait avoir accès ?
Définissez et gérez la sécurité de vos ressources et données dans Microsoft Dataverse. Microsoft Power Platform fournit des rôles d’administrateur au niveau de l’environnement pour effectuer des tâches. Dataverse comprend des rôles de sécurité qui définissent le niveau d’accès aux applications, aux composants d’application et aux ressources dont disposent les créateurs et les utilisateurs d’applications Dataverse.
| Objectif environnement | Rôles ayant accès | Commentaires |
|---|---|---|
| Développement | Créateurs et développeurs d’applications. | Les utilisateurs de l’application ne devraient pas avoir accès. Les développeurs ont besoin au moins du rôle de sécurité Créateur d’environnement pour créer des ressources. |
| Tester | Administrateurs et personnes qui effectuent des tests. | Les créateurs d’applications, les développeurs et les utilisateurs d’applications de production ne devraient pas y avoir accès. Les utilisateurs de test doivent disposer de suffisamment de privilèges pour effectuer les tests. |
| Production | Administrateurs et utilisateurs d’applications. Les utilisateurs doivent disposer d’un accès suffisant pour effectuer leurs tâches pour les applications qu’ils utilisent. | Les créateurs et développeurs d’applications ne devraient pas avoir accès, ou devraient seulement avoir des privilèges au niveau utilisateur. |
| Valeur par défaut | Par défaut, chaque utilisateur de votre client peut créer et modifier des applications dans un environnement par défaut Dataverse qui a une base de données. | Nous vous recommandons vivement de créer des environnements dans un but spécifique et d’accorder les rôles et privilèges appropriés uniquement aux personnes qui en ont besoin. |
Pour plus d’informations :
- Aperçu des environnements
- Contrôler l’accès des utilisateurs aux environnements : groupes de sécurité et licences
- Créer des utilisateurs et attribuer des rôles de sécurité
- Créer des environnements
Solutions
Les solutions sont utilisées pour transporter des applications et des composants d’un environnement à un autre ou pour appliquer un ensemble de personnalisations à des applications existantes.
Les solutions ont ces fonctionnalités :
Elles incluent les métadonnées et certaines entités avec des données de configuration. Les solutions ne contiennent aucune donnée commerciale.
Elles peuvent contenir de nombreux composants de Microsoft Power Platform, tels que les applications pilotées par modèles, les applications canevas, les plans de site, les flux, les entités, les formulaires, les connecteurs personnalisés, les ressources Web, les jeux d’options, les graphiques et les champs. Notez que toutes les entités ne peuvent pas être incluses dans une solution. Par exemple, les tables système Utilisateur d’application, API personnalisée et Paramètre d’organisation ne peuvent pas être ajoutées à une solution.
Ils sont empaquetés en tant qu’unité à exporter et importer dans d’autres environnements, ou déconstruits et vérifiés dans le contrôle de code source en tant que code source pour les actifs. Les solutions sont également utilisées pour appliquer des modifications aux solutions existantes.
Les solutions gérées sont utilisés pour se déployer dans n’importe quel environnement qui n’est pas un environnement de développement pour cette solution. Cela comprend les tests, les tests d’acceptation par l’utilisateur (UAT), les tests d’intégration de système (SIT) et les environnements de production. Les solutions gérées peuvent être tenue à jour (mise à niveau, correctif et suppression) indépendamment des autres solutions gérées dans un environnement. En tant que meilleure pratique ALM, les solutions gérées doivent être générées par un serveur de build et considérées comme un artefact de génération.
Les mises à jour d’un solution gérée sont déployées sur la version précédente du solution gérée. Cela ne crée pas de couche de solution supplémentaire. Vous ne pouvez pas supprimer des composants à l’aide d’une mise à jour.
Un correctif contient uniquement les modifications pour un parent solution gérée. Vous ne devez utiliser des correctifs que lorsque vous effectuez de petites mises à jour (similaires à un correctif) et vous avez besoin qu’il soit éventuellement désinstallé. Lorsque des correctifs sont importés, ils sont superposés au-dessus de la solution parente. Vous ne pouvez pas supprimer des composants à l’aide d’un correctif.
La mise à niveau d’une solution installe une nouvelle couche de solution immédiatement au-dessus de la couche de base et des correctifs existants.
L’application des mises à niveau de solution implique la suppression de tous les correctifs existants et de la couche de base.
Les mises à niveau de solution supprimeront les composants qui existaient mais qui ne sont plus inclus dans la version mise à niveau.
Plus d’informations : Concepts de solution
Contrôle de source
Le contrôle de source, également appelé contrôle de version, est un système qui gère et stocke en toute sécurité les ressources de développement logiciel et suit les modifications apportées à ces ressources. Le suivi des modifications est particulièrement important lorsque plusieurs créateurs et développeurs d’applications travaillent sur le même ensemble de fichiers. Un système de contrôle des sources vous donne également la possibilité d’annuler les modifications ou de restaurer les fichiers supprimés.
Un système de contrôle des sources aide les organisations à atteindre un ALM sain, car les actifs maintenus dans le système de contrôle des sources sont la « source unique de vérité » ou, en d’autres termes, le point d’accès unique et de modification de vos solutions.
Stratégie de branchement et de fusion
Presque tous les systèmes de contrôle de source ont une forme de prise en charge des branchements et des fusions. La ramification signifie que vous divergez de la ligne principale de développement et continuez à travailler sans changer la ligne principale. Le processus de fusion consiste à combiner une branche dans une autre, comme une branche de développement dans une branche de ligne principale. Certaines stratégies de branchement courantes sont les branchements basés sur les troncs, les branchements de versions et les branchements de fonctionnalités. Plus d’information : Adoptez une stratégie de branchement Git
Processus de contrôle des sources à l’aide d’une solution
Il existe deux chemins principaux que vous pouvez utiliser lorsque vous travaillez avec des solutions dans un système de contrôle de source :
- Exportez la solution non gérée et placez-la comme décompressée dans le système de contrôle de source. Le processus de génération importe la solution compressée comme non gérée dans un environnement de génération temporaire (environnement bac à sable). Ensuite, exportez la solution comme gérée et stockez-la en tant qu’artefact de génération dans votre système de contrôle de source.
- Exportez la solution comme non gérée et exportez également la solution comme gérée, et placez les deux dans le système de contrôle source. Bien que cette méthode ne nécessite pas d’environnement de génération, elle nécessite la maintenance de deux copies de tous les composants (une copie de tous les composants non gérés de la solution non gérée et une copie de tous les composants gérés de la solution gérée).
Plus d’information : Créer des tâches d’outils
Automatisation
L’automatisation est un élément clé du cycle de vie des applications qui améliore la productivité, la fiabilité, la qualité et l’efficacité d’ALM. Les outils et tâches d’automatisation sont utilisés pour valider, exporter, empaqueter, décompresser et exporter des solutions en plus de créer et de réinitialiser des environnements bac à sable.
Plus d’information : En quoi consiste Microsoft Power Platform Build Tools ?
Développement d’équipe à l’aide du contrôle de source partagé
Il est important de considérer comment vous et votre équipe de développement travaillerez ensemble pour construire le projet. La décomposition des silos et la promotion des vues et des conversations peuvent permettre à votre équipe de fournir de meilleurs logiciels. Certains outils et workflows, tels que ceux fournis dans Git, GitHub et Azure DevOps, ont été conçus dans le but exprès d’améliorer la communication et la qualité des logiciels. Notez que travailler avec des configurations dans un système de solution peut créer des défis pour le développement d’une équipe. Les organisations doivent orchestrer les modifications de plusieurs développeurs pour éviter autant que possible les conflits de fusion, car les systèmes de contrôle de source ont des limites sur la façon dont les fusions se produisent. Nous vous recommandons d’éviter les situations où plusieurs personnes apportent des modifications à des composants complexes, tels que des formulaires, flux et applications canevas, en même temps.
Plus d’information : Scénario 5 : Soutenir le développement de l’équipe
Intégration et déploiement continus
Vous pouvez utiliser n’importe quel système de contrôle de source et créer un pipeline pour commencer pour une intégration et un déploiement continus (CI/CD). Cependant, ce guide se concentre sur GitHub et Azure DevOps. GitHub est une plateforme de développement utilisée par des millions de développeurs. Azure DevOps fournit des services de développement pour aider les équipes à planifier le travail, à collaborer au développement de code et à créer et déployer des applications.
Pour commencer, vous avez besoin de ce qui suit :
Un compte GitHub, où vous pouvez créer un référentiel. Si vous n’en avez pas, vous pouvez en créer un gratuitement.
Une organisation Azure DevOps. Si vous n’en avez pas, vous pouvez en créer un gratuitement.
Plus d’information : Créez votre premier pipeline
Gestion des licences
Pour créer ou modifier des applications et des flux à l’aide de Power Apps et Power Automate, respectivement, les utilisateurs devront avoir une licence par utilisateur pour Power Apps ou Power Automate, ou une licence d’application Dynamics 365 appropriée. Pour plus d’informations, voir Présentation des licences pour Microsoft Power Platform. Nous vous recommandons également de contacter votre représentant de compte pour discuter de vos besoins en matière de licence. Microsoft
Considérations à propos des ALM
Lorsque vous considérez ALM comme une partie intégrante de la création d’applications sur Microsoft Power Platform, elle peut considérablement améliorer la vitesse, la fiabilité et l’expérience utilisateur de l’application. Elle garantit également que plusieurs développeurs, à la fois des développeurs traditionnels qui écrivent du code et des développeurs citoyens, peuvent contribuer conjointement à la création de l’application.
Consultez les articles suivants qui traitent de plusieurs éléments à prendre en compte au début de tout développement d’application :