Sujets de l’atelier ALM
Dans cette unité, nous allons examiner les éléments à prendre en compte lorsque vous remplissez et évaluez le modèle de l’atelier ALM (Application Lifecycle Management). Ces sujets sont conçus pour permettre à l’architecte de solutions d’évaluer les informations recueillies au cours de l’atelier et de formuler les conclusions et les recommandations. N’oubliez pas que l’ALM n’est pas une solution générique. Le quantité et la sophistication de l’ALM doivent être décidés projet par projet. Un bon point de départ pour comprendre l’ALM avec Dynamics 365 et Microsoft Power Platform consiste à lire et examiner les rubriques Application Lifecycle Management avec Microsoft Power Platform sur cette page de documentation.
Stratégie générale
Il est important de comprendre la méthodologie de développement utilisée par l’équipe de projet pour produire la solution. En outre, il est important de connaître le nombre d’équipes impliquées, en particulier dans la création de personnalisations. La stratégie ALM doit être adaptée pour soutenir ces équipes et permettre aux équipes de projet de travailler efficacement.
Principales questions à poser
Absence totale de méthodologie de développement. Dans un projet, « simplement foncer bille en tête » est une mauvaise idée.
Les approches en cascade plus traditionnelles sont déconseillées avec les projets Microsoft Power Platform et Dynamics 365. La plupart des équipes trouvent qu’une forme d’approche agile ou itérative est plus efficace pour livrer un projet réussi.
Ne pas bien connaître ni les acteurs impliqués dans les changements apportés, ni leur coordination est un risque.
Un outil est-il en place pour suivre les éléments de travail, notamment leur affectation ?
Évolution de l’ALM
Tous les clients n’automatisent pas entièrement leur processus ALM dès le début. Certains choisissent l’approche « Crawl, Walk, Run » (Ramper, Marcher, Courir).
Non géré en développement
Crawl :
- Exportation/Importation
- Exportation/Enregistrement dans un fichier
- Système/Importation
Walk :
- Plusieurs solutions sans contrôle de code source
- Introduction des données principales
- Introduction du contrôle de code source basé sur la solution
Run :
- Introduction de l’automatisation avec déploiements de packages
- Contrôle de version activé au moyen d’un packager de solution
Géré partout en amont
- Builds automatisées et gestion des instances
- Azure Devops automatisé avec contrôle de code source
Environnements
Des environnements doivent être créés pour soutenir la stratégie ALM en cours d’implémentation. Au minimum, le projet doit généralement disposer d’un environnement de développement, d’un environnement de test et d’un environnement de production. Ces environnements doivent être de type bac à sable ou production, et non de type essai ou communautaire. Envisagez également d’avoir un environnement de correctifs pour les modifications qui doivent être appliquées à la post-mise en service dans l’environnement de production.
Si des environnements doivent être créés dans différentes régions géographiques, les équipes doivent savoir qu’ils seront mis à jour à des moments différents. Par exemple, si l’environnement de développement se trouve dans la région Canada et l’environnement de production dans la région Amérique du Nord, le Canada peut disposer de fonctionnalités dont l’Amérique du Nord ne dispose pas encore. Lorsque vous utilisez plusieurs régions géographiques, davantage de coordination avec les mises à jour et les fonctionnalités de Microsoft est requise.
Chaque solution Microsoft Dataverse doit être dotée d’au moins un environnement de développement qui prend en charge les membres de l’équipe créant des personnalisations. Avec un modèle axé sur la source, plusieurs environnements de développement sont possibles, mais nécessitent une coordination pour résoudre les conflits de fusion lors de leur survenue. Les environnements de développement uniques sont plus simples à gérer grâce à une coordination de base, mais plusieurs environnements permettent un meilleur isolement développeur et une vélocité d’équipe plus élevée. Un contrôle d’accès approprié doit être mis en place pour garantir non seulement que seuls les membres de l’équipe adéquats ont accès aux différents environnements, mais aussi qu’aucun changement n’est apporté en dehors de l’environnement de développement affecté.
Principales questions à poser concernant les environnements
Un nombre raisonnable d’environnements a-t-il été identifié ? Au minimum, l’équipe doit disposer d’un environnement de développement, d’un environnement de test et d’un environnement de production. Trop d’environnements sans objectif clair peuvent conduire à une complexité difficile à gérer.
L’équipe prévoit-elle de stocker des solutions décompressées dans le contrôle de code source ?
Des environnements d’essai sont-ils utilisés ? Si tel est le cas, ils risquent d’expirer et d’entraîner la perte de personnalisations de manière inattendue.
Une capacité de stockage est-elle disponible pour prendre en charge le plan d’environnement ?
Contrôle de code source
Il est également important de comprendre comment les personnalisations et autres ressources de code seront promues de l’environnement de développement à travers les différents environnements de test jusqu’à l’environnement de production. Une partie importante de cette démarche consiste à examiner ce qui sera considéré comme la source de vérité pour la personnalisation et les ressources de code. Par le passé, les projets étaient axés sur l’environnement, et l’environnement de développement serait par exemple la source de vérité pour les personnalisations. Dans ce modèle, les personnalisations passeraient directement de l’environnement de développement à l’environnement de test, puis à l’environnement de production. Les changements seraient transportés en tant que solution exportée à partir du développement.
Si vous améliorez un déploiement existant qui a été effectué par le passé, il peut s’agir du modèle utilisé pour le projet d’origine. Les nouveaux projets doivent utiliser le contrôle de code source comme source de vérité pour toutes les personnalisations et les ressources de code de projet. Par exemple, des dépôts Git Azure DevOps pourraient permettre de tout stocker. À l’aide de ce modèle, l’équipe de projet vérifie ses personnalisations dans le contrôle de code source. La solution gérée à déployer est générée à partir du contrôle de code source et permet de promouvoir les personnalisations vers l’environnement de test, puis enfin l’environnement de production. Cette approche rend les environnements de développement jetables. L’autre avantage de l’approche axée sur le contrôle de code source est qu’elle conserve des informations détaillées sur les changements apportés et facilite une stratégie de branches. Les branches sont essentielles pour activer le service vers une version de production pendant la création de la prochaine version. De plus, liaison de la demande de tirage (pull request) ou des validations aux éléments de travail crée une traçabilité qui améliore le processus de développement global.
Principales questions à poser concernant le contrôle de code source
Si une approche axée sur l’environnement était utilisée auparavant plutôt qu’une approche axée sur le contrôle de code source, l’équipe dispose-t-elle d’un plan pour passer au contrôle de code source ?
Un nombre raisonnable d’environnements a-t-il été identifié ? Au minimum, l’équipe doit disposer d’un environnement de développement, d’un environnement de test et d’un environnement de production. Trop d’environnements peuvent conduire à une complexité difficile à gérer.
Des solutions gérées sont-elles utilisées dans tous les environnements autres que l’environnement de développement ?
Solutions
Si possible, toutes les ressources de projet qui sont des composants compatibles avec les solutions doivent être gérées dans une solution Dataverse. La plupart des projets axés sur un seul métier ou processus métier doivent utiliser une seule solution personnalisée. L’équipe de projet doit associer un éditeur de solutions personnalisé qui représente la société ou le produit qu’elle crée et ne doit pas utiliser l’éditeur par défaut. N’utilisez pas plusieurs éditeurs à moins qu’un scénario professionnel n’existe.
Si plusieurs solutions sont utilisées, elles doivent permettre d’atteindre un objectif précis. Par exemple, un projet qui pourrait être placé dans une solution distincte est un composant réutilisable que l’équipe prévoit d’utiliser plusieurs fois. Les solutions peuvent être segmentées par métier ou processus métier. Ces solutions segmentées peuvent partager une base commune, mais doivent être isolées uniquement pour leurs personnalisations et ne pas avoir de dépendances mutuelles. Cependant, cela peut rapidement accroître la complexité et doit être évalué par rapport aux avantages de disposer des solutions distinctes.
Chaque solution doit être dotée de son propre environnement de développement afin d’être isolée des autres. Lorsqu’une solution dépend d’une autre, la version gérée de la solution dépendante doit être installée dans l’environnement de développement. Bien que l’infrastructure de solution prenne en charge le concept de solutions de correctifs, elles ne sont pas recommandées lors de l’utilisation d’un modèle axé sur la source.
Principales questions à poser concernant les solutions
Un éditeur personnalisé a-t-il été créé avec un pré-correctif personnalisé approprié et l’équipe n’utilise pas l’éditeur par défaut ?
L’architecture de solution proposée utilise-t-elle un nombre raisonnable de solutions, chacune avec un objectif clair ?
Le plan d’environnement prend-il en charge le nombre de solutions utilisées dans le projet pour garantir un isolement adéquat des solutions ?
Plan de build
Dans cette section, nous examinons comment l’équipe prévoit de gérer la création de solutions à l’aide de plusieurs environnements. Les solutions doivent être composées dans l’environnement de développement où leurs composants sont modifiés. Le plan ALM doit garantir que des modifications sont apportées uniquement dans l’environnement de développement. L’environnement de développement doit être le seul endroit où des solutions non gérées sont utilisées ; des solutions gérées doivent être installées dans tous les autres environnements. Chaque environnement de développement ne doit être doté que d’une seule solution non gérée.
Bien que l’exportation manuelle des solutions et leur importation soient prises en charge, le processus de build comprendrait idéalement une certaine automatisation pour créer un processus reproductible.
Principales questions à poser concernant les plans de build
Les environnements de développement ne contiennent-ils qu’une seule solution non gérée ?
Des solutions gérées sont-elles utilisées dans tous les environnements autres que l’environnement de développement ?
Des restrictions d’accès ou d’autres mécanismes ont-ils/elles été mis(es) en place pour garantir que des modifications sont apportées uniquement dans l’environnement de développement ?
Tous les composants ne sont pas compatibles avec les solutions et un plan doit exister pour gérer les composants non compatibles avec les solutions (par exemple, visualisations Power BI).
Packager de solution
Le packager de solution doit servir à extraire la solution non gérée de l’environnement de développement et la préparer pour son stockage dans un dépôt de contrôle de code source. Le packager de solution prend le fichier de solution unique et le décompose en fichiers individuels représentant chaque composant de solution. Ce processus est qualifié de décompression de la solution. La sortie du packager de solution est ensuite archivée dans le dépôt de contrôle de code source. Cette version archivée représente désormais la source de vérité du projet.
Le packager de solution peut également compresser le dossier à partir du contrôle de code source, en recréant le fichier de solution unique. Voilà comment les fichiers archivés dans le contrôle de code source permettent ensuite de créer les solutions importées dans les autres environnements.
Principales questions à poser concernant les packagers de solution
Un packager de solution et un dépôt de contrôle de code source sont-ils prévus ?
La solution déployée dans les environnements de test et de production est-elle créée à partir du dépôt de contrôle de code source ?
Vérificateur de solution
Alors que Power Automate et Power Apps permettent de personnaliser un déploiement Dynamics 365, chaque outil offre ses propres Vérificateurs d’application en ligne qui permettent de résoudre des problèmes en temps réel. Cependant, le Vérificateur de solution est capable d’examiner la solution dans son ensemble, de réaliser une analyse statique et de produire une liste détaillée de tous les problèmes détectés. (Pour en savoir plus, consultez Utiliser le Vérificateur de solution pour valider vos applications pilotées par modèle dans Power Apps.)
Le Vérificateur de solution doit être exécuté régulièrement sur toute solution non gérée que vous créez dans vos environnements de développement. Le Vérificateur de solution peut analyser les flux Power Apps et Power Automate, ainsi que des ressources de code telles que des plug-ins créés par les développeurs. L’équipe de projet peut exécuter manuellement le Vérificateur de solution à partir de Maker Portal en sélectionnant la solution, puis en exécutant le Vérificateur.
Le Vérificateur de solution peut également être automatisé pour s’exécuter dans le cadre d’un processus de build à l’aide de tâches de pipeline PowerShell ou Azure DevOps. En automatisant l’exécution du Vérificateur de solution, il peut devenir une partie intégrante du processus de build et peut même être configuré pour arrêter la build si trop d’erreurs se sont produites. La simple exécution du Vérificateur de solution ne garantit pas le succès de l’équipe. Cette dernière doit également avoir mis en place un plan pour évaluer et résoudre régulièrement les problèmes identifiés.
Principales questions à poser concernant le Vérificateur de solution
Un plan est-il en place pour exécuter le Vérificateur de solution dans le cadre du processus de build ?
Les résultats du Vérificateur de solution sont-ils régulièrement examinés et intégrés au processus ?
Le Vérificateur de solution a-t-il été intégré à l’automatisation du processus de build, de sorte qu’il s’exécute sans intervention manuelle ?
Automatisation du déploiement
Un aspect tout aussi important dans le cadre du plan de build consiste à déterminer l’automatisation permettant de rendre le processus reproductible. De nombreux outils fournis par Microsoft et la communauté permettent d’automatiser le processus de build. Les tâches Azure DevOps et Microsoft Power Platform sont une option pouvant être utilisée pour automatiser les tâches de gestion et de déploiement de solutions.
Par exemple, une équipe pourrait disposer d’un pipeline Azure DevOps qui effectue une extraction à partir de l’environnement de développement tous les jours à 19h00 et l’archive dans un dépôt Git. Le même pipeline permet également d’exécuter le Vérificateur de solution afin que, lorsque l’équipe commence sa journée de travail, elle sache immédiatement si des problèmes ont été identifiés dans la build de la nuit précédente.
Le pipeline pourrait également importer la solution dans un environnement de build de qualité permettant la détection de toutes les dépendances introduites involontairement lors du développement de ce jour-là. Ainsi, ce qui est archivé dans le contrôle de code source est une version de qualité prête à être déployée dans d’autres environnements. Les pipelines permettent également d’automatiser les tests afin qu’il ne s’agisse que d’une étape supplémentaire dans le pipeline.
Les pipelines Azure Pipelines permettent également de produire l’artefact de solution gérée à utiliser dans les pipelines de mise en production pour le déploiement dans les environnements en amont tels que les environnements de test et de production. Le même artefact de solution utilisé dans l’environnement de test est utilisé jusqu’à la production. Ainsi, il n’introduit aucun nouveau changement surprenant à mesure que la promotion progresse dans la série d’environnements se terminant en production. Les pipelines Azure Pipelines permettent également de créer des ressources de code développeur afin de garantir qu’elles ne sont pas créées sur une station de travail locale d’un développeur.
GitHub Actions est une autre option pour automatiser les déploiements.
Principales questions à poser concernant l’automatisation du déploiement
Le processus de build est-il automatisé à l’aide d’Azure DevOps ou d’un autre outil d’automatisation, ou l’équipe a-t-elle toujours recours à une intervention manuelle ?
Le Vérificateur de solution a-t-il été intégré au pipeline automatisé ?
Toutes les ressources de code développeur sont-elles créées au moyen d’un processus de build, et non sur la machine locale d’un développeur individuel ?
Contrôle de version
Un autre élément du plan de build à examiner est la stratégie de gestion de plusieurs versions actives. Par défaut, à mesure que les modifications progressent de l’environnement de développement à l’environnement de test, puis à l’environnement de production, cela représente un flux de travail unique de modifications. Si un problème est identifié dans l’environnement de production, vous le corrigez dans l’environnement de développement, puis le promouvez à travers la série d’environnements pour retourner en production. Un seul flux de travail comme celui-ci fonctionne bien si aucun nouveau développement n’est effectué.
Si l’équipe de développement est déjà passée à la version deux dans son environnement de développement, puis corrige un bogue identifié en production, alors que le correctif est transféré en production, il en est de même pour tout travail en cours pour la version deux, car tous les éléments étaient mélangés ensemble. L’idéal est d’apporter le changement dans un environnement de développement de flux de travail distinct qui représente uniquement les éléments déjà en production, et les éléments promus comprennent uniquement le correctif, sans rien de la version deux. Par conséquent, l’équipe de projet doit planifier et disposer d’une stratégie pour gérer plusieurs versions actives. Il peut s’agir simplement d’un flux de développement actif et d’un flux de maintenance pour soutenir la production. Des projets plus complexes peuvent même disposer de plusieurs flux de développement actifs en cours simultanément.
La gestion simultanée des flux de développement actifs et de maintenance est généralement effectuée au moyen d’une combinaison d’environnements Dataverse et de branches de contrôle de code source. Les branches permettent de disposer d’une copie des ressources du projet, et d’un moyen isolé d’apporter des changements dans un environnement associé à une branche donnée. Les modifications d’une branche peuvent être fusionnées avec une autre branche. La stratégie de branches doit être aussi simple que possible pour éviter d’avoir à résoudre de nombreux conflits lors de la fusion de branches.
Principales questions à poser concernant le contrôle de version
L’équipe a-t-elle réfléchi à la manière dont elle maintiendra le travail de développement séparément des correctifs de bogues pour la production ?
La stratégie de branches identifiée est-elle trop complexe ?
Les branches pour le contrôle de code source sont-elles coordonnées avec le plan d’environnement ?
Un processus de gestion du changement est-il en place pour veiller à la réintégration des correctifs de bogues dans l’environnement de développement principal ?
Stratégie de test
Même si un atelier est dédié à la stratégie de test, le processus de test lui-même doit être intégré à la stratégie ALM globale. Par exemple, si vous prévoyez des tests quotidiens du travail de la veille effectués par l’équipe d’assurance qualité, vous devez d’une manière ou d’une autre vous assurer que cette équipe dispose d’un environnement mis à jour avec les modifications d’hier et prêt à l’emploi avant que les tests puissent commencer.
L’automatisation des tests doit également être envisagée et peut être intégrée au processus de build. Cela peut inclure l’approvisionnement d’un environnement de test, le chargement de données de test et l’exécution de tests. Les résultats du test peuvent permettre de bloquer la progression des pipelines de build et les empêcher de continuer en cas d’erreurs.
Les applications Power Apps pilotées par modèle peuvent être testées à l’aide d’Easy Repro. Les applications canevas Power Apps peuvent être testées à l’aide du studio de test Power Apps. Le studio de test fonctionne en enregistrant les actions dans l’application et en les réexécutant pour automatiser les tests. Easy Repro utilise des scripts pour définir les étapes de test à effectuer. Une fois l’enregistrement et/ou les scripts générés, les tests peuvent être intégrés en tant que tâche à un pipeline Azure DevOps.
À mesure que les tests se déroulent, ils finissent par identifier les problèmes à évaluer et corriger. La stratégie ALM globale doit inclure le mode de documentation, de tri et de hiérarchisation des problèmes. Si une équipe de développement abandonne tout et corrige chaque bogue dès sa survenue, le processus global est perturbé. En général, un projet doit établir un processus de contrôle des modifications pour s’assurer que chaque problème est trié et hiérarchisé en fonction du moment où il est introduit en tant que correctif.
Principales questions à poser concernant une stratégie de test
La stratégie ALM est-elle alignée sur la stratégie de test globale ?
Un processus de contrôle des modifications est-il en place pour suivre et gérer les problèmes identifiés ?
Au moins certains tests ont-ils été intégrés à l’automatisation du processus de build ?
Mise en production et déploiement
Une fois la solution créée, elle doit être promue à travers les environnements de test jusqu’à la production. En général, cela implique plus que la simple importation d’une solution dans ces environnements. Pour commencer, vous devez avoir connaissance de l’état de départ de l’environnement. Par exemple, souhaitez-vous qu’un test commence chaque fois avec des données de test standard ou depuis le point de départ de la dernière série de tests ? Chaque environnement est susceptible d’avoir un type de données de configuration (par exemple, des variables d’environnement) à configurer au moins pour le premier déploiement. Pour les environnements de test, vous devez également vous assurer qu’ils ne communiquent pas avec les services de production dans la plupart des cas. L’envoi d’un e-mail de test à tous vos véritables clients n’est généralement pas apprécié.
Principales questions à poser concernant la mise en production et le déploiement
Existe-t-il un plan pour ce à quoi ressemble chaque environnement de test du point de vue des données, ainsi que ses connexions à des services ?
Les variables d’environnement de solution nécessaires ont-elles été créées pour garantir que la solution peut être adaptée à chaque environnement ?
Données de référence
La plupart des solutions sont dotées d’un certain type de données de référence à gérer entre les différents environnements. L’outil de migration de configuration est un outil qui vous permet d’exporter des données à partir d’un environnement et de les importer dans d’autres. L’outil de migration de configuration fonctionne en définissant un schéma des données à exporter, y compris les champs et les relations. L’exécution de l’exportation entraîne la création d’un fichier .zip de données contenant toutes les données exportées. L’outil de migration de configuration peut également prendre en charge l’importation des données dans un environnement où le fichier de données peut être utilisé avec l’outil Package Deployer. Cet outil est capable d’éviter les doublons à l’aide de conditions uniques définies pour chaque entité sur la base d’une combinaison de champs. Si un enregistrement correspondant est trouvé, l’enregistrement est mis à jour, sinon un enregistrement est créé.
Principales questions à poser concernant les données de référence
Y a-t-il une compréhension claire de ce qui constitue des données de référence pour la solution ?
La nature de la copie principale des données de référence, ainsi que son emplacement de stockage et de suivi sont-ils clairement définis ?
Un plan est-il en place pour gérer les données de référence entre les environnements ?
Package Deployer
Un autre outil utile dans la gestion de la mise en production et du déploiement est l’outil Package Deployer. Package Deployer vous permet de créer un package qui comprend plusieurs solutions, des données de l’outil de migration de configuration et une logique de code développeur qui s’exécute avant et après l’importation du package. À bien des égards, vous pouvez considérer Package Deployer comme un assistant d’installation pour Microsoft Power Platform. Package Deployer peut être exécuté de manière interactive pour importer manuellement des packages et des données dans un environnement. Package Deployer prend également en charge l’exécution à l’aide de PowerShell, ce qui permet l’automatisation et l’intégration dans Azure Pipeline.
Principales questions à poser concernant Package Deployer
- L’équipe a-t-elle réfléchi à l’utilité de Package Deployer dans le cadre de sa stratégie de déploiement ?
Pipelines de mise en production
Plus tôt dans cette unité, nous avons parlé de l’automatisation du processus de build, qui prépare la solution pour le déploiement et la crée sous forme d’artefact de build. Azure Pipelines prend également en charge le concept de pipelines de mise en production pour gérer la mise en production dans un ou plusieurs environnements. Les pipelines de mise en production sont destinés à utiliser les artefacts de build (par exemple, un fichier de solution gérée) et à les déployer dans des environnements de test ou de production. Les pipelines de mise en production peuvent intégrer des processus d’approbation entre chacun des environnements. Les approbations permettent de coordonner le feu vert donné par plusieurs parties prenantes à mesure que la mise en production progresse à travers les niveaux d’environnement.
Principales questions à poser concernant les pipelines de mise en production
Les solutions créées entre les environnements sont-elles déployées à l’aide d’Azure Pipelines ou d’un outil similaire ?
À mesure que le déploiement progresse entre les environnements, comment les approbations sont-elles gérées ?
Modèle d’exécution
Ici, nous jetons un œil à la stratégie post-mise en service. Cela suppose que vous avez effectué votre déploiement initial et que vous passez désormais à la maintenance de ce que vous avez déployé et que vous travaillez sur des améliorations. Comme les utilisateurs utilisent inévitablement ce que vous avez créé, ils identifient les éléments qu’ils souhaitent modifier ou améliorer pour les rendre plus productifs. L’équipe de projet doit avoir mis en place un outil pour capturer ces demandes de changement, et un moyen de les évaluer, de les hiérarchiser et de les classer par mises à jour.
Par exemple, ces changements pourraient facilement être regroupés en trois catégories : critique, mineur et majeur.
Lorsque vous réfléchissez à la gestion de vos modifications en cours, vous devez mettre en place des processus pour gérer au moins ces trois types de changements. Les changements critiques, par exemple, doivent pouvoir être déployés presque immédiatement, car ils empêchent les utilisateurs de terminer leur travail. En général, ces changements ne peuvent pas attendre qu’un déploiement hebdomadaire se produise. Vous avez donc besoin d’un moyen d’effectuer la maintenance de la production sans attendre une build et un déploiement planifiés de la prochaine mise à jour prévue. Il est important de disposer d’un processus pour gérer ces problèmes critiques, car vous souhaitez éviter de devoir apporter des modifications à l’environnement de production pour contourner le problème.
Principales questions à poser concernant la stratégie post-mise en service
La stratégie de branches de contrôle de code source et d’environnement prend-elle en charge le déploiement immédiat des correctifs critiques ?
Existe-t-il un plan pour intégrer tout backlog de problèmes pré-mise en service à un cycle de maintenance et d’amélioration ?
Un contrôle des modifications est-il en place pour suivre et trier les problèmes identifiés dans l’application d’exploitation ?
Un processus est-il en place pour veiller à l’intégration des correctifs critiques se produisant rapidement au processus de mise en production standard ?
Cycle de mises à jour Microsoft
Outre les mises à jour créées par votre équipe pour apporter des améliorations ou résoudre des problèmes, Microsoft fait de même pour les applications Microsoft Power Platform et Dynamics 365. En général, Microsoft déploie des mises à jour chaque semaine qui ne perturbent pas l’expérience utilisateur. Ces mises à jour sont déployées à l’aide d’une pratique de déploiement sécurisée qui réduit tout impact sur vos environnements. Vous pouvez contrôler le moment où ces mises à jour sont appliquées à votre environnement de production au moyen de l’outil d’administration.
La plupart des modifications apportées aux applications Dataverse et Dynamics 365 sont déployées par région. Afin de vous assurer que ces modifications n’entraînent aucun effet négatif sur vos personnalisations, une stratégie consiste à les tester dans un environnement qui réside dans une région où les mises à jour sont disponibles avant la vôtre, et à y exécuter des tests automatisés pour identifier les problèmes. Même si cela n’est pas viable, vous pouvez toujours exécuter des tests automatisés hebdomadaires pour les fonctionnalités critiques afin d’éviter tout effet négatif sur vos personnalisations.
À l’heure actuelle, Microsoft publie deux fois par an (en avril et octobre) des mises à jour plus importantes pouvant inclure des modifications susceptibles de perturber l’expérience utilisateur de l’application existante. Ces mises à jour sont planifiées et préalablement annoncées par un plan de lancement publié détaillant les changements à venir. Cela se produit plusieurs mois avant l’application automatique de la mise à jour réelle.
Dans le cadre du processus menant à la mise à jour automatique, les modifications peuvent être activées manuellement par les administrateurs dans des environnements avant leur application automatique à tous les environnements. Ainsi, vous pouvez copier un environnement de production dans un environnement de bac à sable hors production et tester les modifications avant leur déploiement en production. Une fois les tests réussis, vous pouvez accepter les modifications selon votre propre calendrier, au lieu d’attendre les mises à jour automatiques.
Principales questions à poser concernant les cycles de mises à jour
L’équipe a-t-elle évalué si elle doit effectuer des tests hebdomadaires et a-t-elle mis en place des plans ?
Le client comprend-il le processus de mise à jour et comment, deux fois par an, il peut accepter des tests à l’avance ?
Gestion de la capacité
La gestion de la capacité est importante à la fois lors du pré-déploiement et de la gestion de l’utilisation après la mise en service du projet. La gestion de la capacité ne se limite pas au stockage, mais ce dernier en est un élément clé. Les requêtes d’API sont une autre capacité importante à surveiller. Veillez à rester en conformité avec vos allocations de licences et, si nécessaire, à ajouter des requêtes d’API supplémentaires. D’autres produits et compléments comme AI Builder et Power Virtual Agents disposent également d’une capacité dont vous devriez tenir compte dans votre effort global de gestion de la capacité.
Du point de vue de la capacité de stockage, la capacité de Dataverse est répartie en capacité de base de données, capacité de journal et capacité de fichier. Chacun de ces éléments est suivi et un stockage supplémentaire peut être ajouté individuellement en fonction de votre utilisation réelle. Pour créer des environnements dans votre client, vous devez disposer d’au moins un Go de capacité de base de données. Vous devez prendre en compte cet élément lorsque vous créez votre stratégie ALM qui comprendra plusieurs environnements. Si votre stratégie ALM implique des environnements temporaires, ceux-ci mobilisent de la capacité seulement s’ils sont réellement utilisés. Mais pour les créer au moyen d’un processus automatisé, la capacité doit être disponible lors de l’exécution de l’automatisation, sinon cette dernière échoue.
Pour la capacité de base de données, vous devez estimer la capacité initiale en fonction des données que vous allez migrer dans Dataverse lors de la mise en service. Cela inclut également les données pouvant exister dans des environnements hors production. Une première étape clé de ce processus consiste à connaître le nombre d’enregistrements dont vous disposez par entité. Dès que vous pouvez migrer une partie de vos données, vous pouvez commencer à obtenir des insights en extrapolant votre charge de données réelle en fonction de l’échantillon que vous chargez dans Dataverse. Une fois que vous pouvez effectuer un chargement complet des données que vous prévoyez de migrer, vous devriez être en mesure d’obtenir des informations de dimensionnement pour cet environnement. Le Centre d’administration Microsoft Power Platform fournit des outils qui vous permettent d’examiner l’utilisation du stockage par les principales entités. Outre la capacité initiale, il est important de tenir compte de la croissance continue lorsque votre solution s’exécute dans un environnement réel. Connaître le taux de croissance des principales entités vous permet de déterminer en permanence les besoins en capacité.
L’utilisation de la capacité de fichier dépend de votre utilisation des pièces jointes et des types de données de fichier image sur les enregistrements. La capacité de fichier est également utilisée si vous avez installé une ou plusieurs applications Insights. L’estimation du stockage s’apparente à la capacité de base de données et il est essentiel de connaître le nombre d’enregistrements et la taille moyenne des fichiers pour ces enregistrements.
L’utilisation de la capacité de journal dépend de votre utilisation de la fonctionnalité d’audit et de suivi du plug-in. Même si elle utilise de la capacité, l’audit est une fonctionnalité précieuse à activer. L’audit est contrôlé au niveau de l’environnement, de l’entité et du champ, et doit être activé là où cela a du sens. L’audit est précieux pour les scénarios métier afin de savoir qui a effectué quel changement et pour la résolution des problèmes liés au système. Tirez parti de la fonctionnalité qui vous permet de définir un délai de rétention si cela répond aux besoins de votre entreprise.
Vous pouvez surveiller votre utilisation du stockage dans le Centre d’administration Microsoft Power Platform. Pour en savoir plus, consultez Analyse Dataverse.
Principales questions à poser concernant la capacité
L’équipe a-t-elle une bonne compréhension du volume d’enregistrements par entité ?
Un plan est-il en place pour surveiller la capacité après la mise en service initiale afin de veiller à l’approvisionnement de la capacité adéquate ?
Gestion de la capacité de requête d’API
Les requêtes d’API incluent toutes celles des connecteurs, chacune des actions d’étape Power Automate et toute l’utilisation de l’API Dataverse. Une liste complète des éléments comptabilisés est consultable ici dans Limites et allocations de requêtes. Chaque licence dont vous disposez pour Power Apps, Power Automate et Dynamics 365 fournit une allocation de requêtes d’API par période de 24 heures. En général, l’allocation de licence comprend de nombreuses requêtes d’API pour une utilisation normale des applications pour lesquelles vous disposez d’une licence. Si vous dépassez régulièrement votre plafond d’allocations, vous pouvez acheter des requêtes d’API supplémentaires au moyen de licences complémentaires. Cause la plus courante de dépassement : les intégrations ou la logique personnalisée effectuant un traitement en bloc. Ces éléments peuvent souvent être ajustés pour un traitement plus efficace afin d’éviter de dépasser le plafond des requêtes d’API. Les architectes de solutions doivent prêter particulièrement attention à ces types de processus pour veiller à optimiser leur utilisation des API.
Outre le suivi des allocations des requêtes d’API, Dataverse implémente également des limites de protection du service. Elles sont conçues pour garantir une disponibilité et des performances homogènes pour tous les utilisateurs du service. Encore une fois, une utilisation normale ne devrait pas déclencher la protection du service. Cependant, les intégrations de grands volumes de données peuvent parfois entraîner des erreurs causées par le déclenchement de la protection du service. Les limites de protection du service sont évaluées toutes les cinq minutes à l’aide d’une fenêtre glissante. L’utilisation évaluée est le nombre de requêtes envoyées par un utilisateur, le temps d’exécution combiné des requêtes et les requêtes simultanées d’un utilisateur.
Les limites de protection du service ne peuvent pas être remplacées en achetant davantage d’allocations de licence et doivent être gérées dans les applications par une logique de nouvelle tentative appropriée. Pour en savoir plus sur les limites de protection du service et la gestion des nouvelles tentatives, consultez Limites d’API pour la protection du service.
Principales questions à poser concernant les requêtes d’API
L’équipe a-t-elle identifié des points chauds potentiels pour les requêtes d’API susceptibles de causer des problèmes ?
Une logique de nouvelle tentative a-t-elle été ajoutée à toutes les intégrations ou au travail d’API en bloc ?
Un plan est-il en place pour surveiller l’utilisation des API et ajuster la capacité selon les besoins ?