ALM : environnements et solutions dans le cycle de vie des applications
Cette page approfondit la page Environnement & Solutions sous l'angle de l'ALM (Application Lifecycle Management) : comment les environnements et les solutions s'articulent pour développer, tester puis déployer proprement des applications et des flux.
Le principe : un environnement par usage
Un ALM sain repose sur la séparation des usages, avec au minimum trois environnements :
| Environnement | Usage | Qui y accède |
| Développement | Construire les applications et les flux | Créateurs et développeurs uniquement (rôle Créateur d'environnement au minimum) ; pas d'utilisateurs finaux |
| Test | Valider les livraisons (recette, UAT) | Administrateurs et testeurs, avec les seuls privilèges nécessaires ; pas de créateurs ni d'utilisateurs de production |
| Production | Exploitation par les utilisateurs | Administrateurs et utilisateurs ; les créateurs n'y ont pas accès, ou en simple niveau utilisateur |
Le cas de l'environnement par défaut
- Chaque tenant possède un environnement par défaut, créé automatiquement et partagé par tous les utilisateurs, nommé « {nom du tenant} (par défaut) ».
- Tout utilisateur y est automatiquement Créateur d'environnement : il peut y créer applications et flux.
- Recommandation : ne pas y faire vivre les projets sérieux ; créer des environnements dédiés par usage et y attribuer les rôles au strict nécessaire.
Applications Dynamics 365 : choix irréversible
- Au moment de la création d'un environnement avec Dataverse, l'installation des applications Dynamics 365 (Sales, Customer Service...) doit être décidée : elles ne peuvent être ni installées ni désinstallées ensuite.
- Si vous ne construisez pas sur ces applications, ne les installez pas : vous éviterez des complications de dépendances lors de la distribution de solutions entre environnements.
Solutions : le véhicule du déploiement
Les solutions transportent :
- les applications
- et les composants
d'un environnement à un autre.
À retenir :
- Elles contiennent des métadonnées et de la configuration, jamais de données métier.
- Elles peuvent embarquer :
- applications canvas et pilotées par modèle,
- flux,
- tables,
- formulaires,
- connecteurs personnalisés,
- choix,
- graphiques,
- colonnes,
- plans de site...
Solution non gérée ou gérée
| Type | Où l'utiliser | Caractéristiques |
| Non gérée (unmanaged) | Environnement de développement uniquement | Modifiable ; sert de source de travail |
| Gérée (managed) | Test, UAT, production | Non modifiable sur place ; maintenable indépendamment (mise à jour, correctif, suppression) ; à considérer comme un artefact de build |
Mise à jour, correctif, mise à niveau
- Mise à jour : se déploie sur la version précédente de la solution gérée, sans couche supplémentaire ; ne peut pas supprimer de composants.
- Correctif (patch) : petites modifications superposées à la solution parente, désinstallables ; ne peut pas supprimer de composants.
- Mise à niveau (upgrade) : installe une nouvelle couche, supprime les correctifs existants et retire les composants qui ne font plus partie de la version ; c'est la seule opération qui supprime des composants.
Contrôle de code source et automatisation
- Le contrôle de code source (Git, Azure DevOps, GitHub) devient la « source unique de vérité » des solutions : suivi des modifications, retour arrière, travail à plusieurs.
- L'intégration Git de Power Platform permet de lier directement un environnement à un dépôt ; sinon, les Power Platform Build Tools (Azure DevOps) exportent, décompressent et empaquettent les solutions dans des pipelines CI/CD.
- Éviter que plusieurs personnes modifient en même temps des composants complexes (formulaires, flux, applications canvas) : les fusions y sont mal prises en charge.
En résumé : le cycle complet
- Développer dans un environnement de développement, dans une solution non gérée.
- Exporter la solution en version gérée (idéalement via un pipeline de build).
- Importer la solution gérée en test, faire valider.
- Importer la même solution gérée en production.
- Corriger en développement, puis rejouer le cycle (mise à jour ou mise à niveau).
Voir aussi dans ce support : la page Attribuer des droits sur un environnement, la page Créer une base de données Dataverse et la page Gestion du cycle de vie d'une application Power Apps (ALM).
Travaux pratiques
- Dans votre environnement de développement, créer une solution non gérée NomProjet-Dev avec un éditeur personnalisé (préfixe dédié).
- Y ajouter une application canvas et un flux existants.
- Exporter la solution en version gérée.
- L'importer dans un second environnement (bac à sable) et vérifier que les composants n'y sont pas modifiables.
- Modifier l'application en développement, exporter une nouvelle version et réaliser une mise à niveau dans le bac à sable.