Stratégie environnementale pour ALM
Pour suivre les principes de gestion du cycle de vie des applications (ALM), vous aurez besoin d’environnements distincts pour le développement et la production d’applications. Bien que vous puissiez exécuter ALM de base avec uniquement des environnements de développement et de production distincts, nous vous recommandons de maintenir également au moins un environnement de test distinct de vos environnements de développement et de production. Lorsque vous disposez d’un environnement de test distinct, vous pouvez effectuer une validation de bout en bout qui inclut le déploiement de la solution et les tests d’application. Certaines organisations ont peut-être besoin de plus d’environnements pour le test d’acceptation utilisateur, le test d’intégration des systèmes et la formation.
Des environnements de développement distincts peuvent être utiles pour isoler les modifications d’un effort de travail archivé avant qu’il ne soit terminé. Des environnements de développement séparés peuvent également être utiles pour réduire les situations où une personne affecte négativement une autre tout en effectuant des changements.
Chaque organisation est unique, alors examinez attentivement les besoins environnementaux de votre organisation.
Environnement de développement
Vous devez répondre à des questions telles que :
- De combien d’environnements de développement ai-je besoin ?
- Pour en savoir plus, consultez Présentation des environnements.
- Comment approvisionner automatiquement des environnements à partir du code source ?
- Plus d’information : Microsoft Power Platform Build Tools pour Azure DevOps
- Quelles sont les dépendances de mes environnements ?
- Plus d’informations : Superposition de plusieurs solutions et dépendances
Autres environnements
Vous devez également répondre à la question : « De quels types d’environnements autres que de développement ai-je besoin? »
Par exemple, en plus de votre environnement de production, vous pourriez avoir besoin d’environnements de test, UAT, SIT et de pré-production distincts. Notez que, au minimum, toute pratique saine d’ALM doit inclure l’utilisation d’un environnement de test avant de déployer quoi que ce soit dans l’environnement de production. Cela garantit que vous disposez d’un emplacement pour tester votre application, mais garantit également que le déploiement lui-même peut être testé.
Informations complémentaires : Création d’une stratégie d’environnement pour Microsoft Power Platform
Considérations multi-géographiques
Les environnements Power Platform suivent une certaine planification des mises à jour de service au fur et à mesure que les environnements sont mis à jour dans le monde entier. 6 stations en tout sont principalement définies par leur emplacement géographique. Les mises à jour de service sont appliquées en séquence pour chaque station. Ainsi, les mises à jour de service de la station 2 sont appliquées avant la station 3. Il est donc courant que les environnements qui se trouvent dans différentes stations aient des versions différentes à un moment donné. Pour plus d’informations sur la planification des mises à jour de service d’environnement, accédez à Versions publiées de Microsoft Dataverse
Importation de la solution et version de l’environnement
Si vous avez plusieurs environnements dans différentes régions, il est important de comprendre ce qui suit lorsque vous importez une solution :
- Vous pouvez importer une solution dans un environnement dont la version est plus récente que celle de l’environnement dans lequel la solution a été exportée.
- Vous ne pouvez pas importer de manière fiable une solution dans un environnement dont la version est plus ancienne que celle de l’environnement dans lequel la solution a été exportée. Cela est dû au fait qu’il peut y avoir des composants manquants ou des fonctionnalités obligatoires dans l’ancien environnement.
Exemple d’alignement réussi des environnements avec des stations de mise à jour de service
Imaginez que vous avez des environnements de production au Canada et aux États-Unis. Dans ce cas, vos environnements de développement doivent être en Amérique du Nord (station 5) et non au Canada (station 2). Ensuite, vos environnements de développement auront toujours la même version ou une version antérieure à celle de vos environnements de production, ce qui réduira les conflits de version d’importation de solution.
