Partager via

Organiser vos solutions

Avant de créer des solutions, prenez un certain temps pour planifier votre stratégie d’environnement et votre stratégie de solution. Tenez compte des aspects suivants :

Aspect Considération
Portée de l’application Votre implémentation couvre-t-elle plusieurs applications telles que Sales, Customer Service, Field Service, Finance, etc. ?
Cadence de mise en production À quelle fréquence envisagez-vous de déployer des mises à jour en production ?
Votre méthodologie de livraison est-elle basée sur des pratiques agiles comme les cycles sprint ?
Prise en charge de la production Comment gérez-vous des correctifs urgents en production sans introduire de nouvelles fonctionnalités prématurément ?
Architecture de la solution Combien de solutions gérez-vous ?
Ces solutions partagent-elles des composants ou dépendent-elles les unes des autres ?
Planification de l’environnement Combien d’environnements Microsoft Dataverse avez-vous besoin pour prendre en charge votre cycle de vie de développement ?
Avez-vous besoin d’environnements distincts pour le développement, les tests et la production ?
Les développeurs travaillent-ils en collaboration dans un environnement partagé ou ont-ils besoin d’environnements isolés pour fonctionner indépendamment ?

Les sections suivantes décrivent trois stratégies, organisées du plus simple au plus complexe, et mettent en évidence leurs avantages et inconvénients respectifs.

Stratégie de solution unique

Toutes les personnalisations sont regroupées en une solution non managée pendant le développement, qui est ensuite exportée en tant que solution managée unique pour le déploiement.

Recommandé pour :

  • Implémentations à petite échelle moyenne
  • Scénarios où la modularisation future est peu probable
Avantage Désavantage
Configuration et gestion simplifiées de l’environnement. Nécessite davantage d’efforts pour mettre à l’échelle ou modulariser ultérieurement si nécessaire.
Déploiement simplifié. Avec une seule solution pour gérer, exporter et importer entre les environnements est simple et moins sujette aux erreurs. Une seule solution contenant un grand nombre de personnalisations peut entraîner des temps de déploiement plus longs. Pour réduire la taille de la solution, utilisez la segmentation de table. Pour réduire les temps d’importation, accédez aux recommandations de performances.
Plus facile à localiser, auditer et gérer les modifications. Lorsque plusieurs développeurs travaillent dans le même environnement de développement, ils risquent de remplacer les modifications des autres. Ce risque peut être réduit en implémentant le contrôle de version du code source, en adoptant une stratégie de branchement et en utilisant un environnement de développement dédié pour chaque branche. La stratégie de contrôle de version et de branchement du code source fournit des mécanismes de suivi des modifications, de prise en charge de la collaboration et de résolution des conflits. Pour plus d’informations, adoptez une stratégie de branchement Git.

Nonte

Les améliorations récentes apportées à Microsoft Power Platform ont réduit les temps d’importation pour les solutions managées, y compris celles qui utilisent l’option de mise à niveau. Ces optimisations incluent une meilleure gestion des dépendances des composants et une surcharge réduite pour les composants inchangés. Pour savoir comment tirer parti de ces améliorations, consultez les recommandations en matière de performances.

Plusieurs solutions dans le même environnement de développement

Plusieurs solutions non managées sont conservées dans un environnement de développement unique, chacun étant généralement dédié à des fonctionnalités ou modules non liés.

Recommandé pour :

  • Implémentations à petite échelle à moyenne échelle avec des zones fonctionnelles distinctes et indépendantes qui ne partagent pas de composants.
Avantage Désavantage
Configuration et gestion simplifiées de l’environnement. La gestion de plusieurs solutions non managées dans le même environnement de développement augmente la probabilité de conflits de dépendances. Par exemple, vous pouvez rencontrer une situation où la solution A ne peut pas être importée, car elle dépend de la solution B, tandis que la solution B ne peut pas être importée, car elle dépend de la solution A.
Les zones fonctionnelles peuvent être déployées indépendamment les unes des autres. Plusieurs développeurs travaillant sur le même environnement de développement peuvent remplacer les modifications des uns des autres. L’utilisation d’une solution non managée ne fournit pas d’isolation. Chaque modification est appliquée directement à l’environnement, quelle que soit la solution en cours de modification.

Nonte

Lorsque vous avez plusieurs solutions dans le même environnement de développement, après avoir importé les solutions managées dans votre environnement cible, vous créez souvent des couches. Plus d’informations : Couches de solution et comportement de fusion

Il est important que vous :

  • N’incluez pas le même composant non managé dans plusieurs solutions.
  • Ayez une seule solution qui inclut toutes vos tables. Ne devez pas avoir deux solutions différentes où chacune contient des tables. En effet, il existe fréquemment des risques d’une relation unique entre les tables, ce qui crée une dépendance entre les solutions et provoque des problèmes de mise à niveau ou de suppression de solution dans l’environnement cible à un moment ultérieur.
  • Utilisez un seul éditeur de solution. L’éditeur de solution possède les composants d’une solution managée et son association ne peut pas être modifiée ultérieurement. Par exemple, si une table personnalisée est importée comme gérée via la solution A avec Publisher X, vous ne pouvez pas déplacer cette table vers la solution B avec Publisher Y. La seule option consiste à supprimer la table, à mettre à niveau la solution A pour supprimer la table du système cible, puis à recréer la table dans la solution B avec Publisher Y et importer la solution B. Ce processus entraîne la perte de toutes les données stockées dans la table personnalisée, sauf s’il est migré au préalable.
  • Évitez de créer des dépendances entre les solutions. Les dépendances appliquent un ordre d’importation et peuvent provoquer des problèmes. Par exemple, si vous avez une solution pour les tables et une autre pour les flux cloud, et qu’un flux s’appuie sur une colonne personnalisée, il fonctionne en développement, car la colonne existe. Toutefois, si seule la solution de flux cloud est importée dans l’environnement cible, le processus d’importation risque de ne pas reconnaître la dépendance sur la colonne personnalisée. Par conséquent, la solution de flux s’installe correctement, mais le flux lui-même ne fonctionne pas. Plus d’informations : Exemples de dépendances créées par plusieurs solutions

Exemples de dépendances créées par plusieurs solutions

  • Rubans d’application. Lorsque plusieurs solutions modifient le ruban de l’application ou la carte de site de la même application.
  • Plug-ins ou flux de cloud. Si le plug-in ou le flux se déclenche sur une colonne personnalisée ou met à jour une table personnalisée, l’objet dépend de ces tables personnalisées.
  • Rôles de sécurité. Quand des tables personnalisées existent, les rôles de sécurité dépendent généralement de ces tables pour l’accès utilisateur.

Plusieurs solutions avec des environnements de développement dédiés

Cette stratégie implique le développement de chaque solution non managée dans son propre environnement de développement Dataverse isolé. Cette stratégie est couramment utilisée dans les architectures modulaires où, par exemple, différentes applications ( ventes, service clientèle ou service de terrain) sont créées et gérées indépendamment. Une solution de base contenant des composants courants (par exemple, des tables de compte et de contact) est créée et déployée en tant que solution managée dans chaque environnement de développement spécifique à l’application. Chaque application dispose ensuite de sa propre solution non managée, superposée à la solution managée de base, ce qui permet aux équipes d’étendre les fonctionnalités sans modifier la base de base.

Recommandé pour :

  • Projets d’entreprise à grande échelle.
  • Teams avec plusieurs développeurs ou partenaires
  • Scénarios nécessitant une gouvernance stricte et des pipelines CI/CD.
Avantage Désavantage
Plus facile à développer et à faire évoluer votre système en ajoutant ou en mettant à jour des modules sans affecter d’autres personnes. Surcharge de maintenance et d’infrastructure supérieures.
Plusieurs équipes peuvent travailler en parallèle sur différents modules sans entrer en conflit avec les modifications des autres. Nécessite une stratégie et une gouvernance d’environnement robustes.
Plus facile à implémenter les pratiques de test automatisé et DevOps. Déploiement plus complexe.
Les solutions plus petites sont plus rapides à déployer, en particulier dans les pipelines CI/CD si vous devez déployer uniquement une application spécifique.
Les bogues ou régressions sont plus faciles à tracer lorsque les modifications sont isolées sur des modules spécifiques.

Comment créer votre couche de solution

Nonte

Avant de créer les solutions dans les étapes suivantes, utilisez le même éditeur pour toutes vos solutions dans vos environnements. Plus d’informations : Éditeur de solutions

  1. Dans l’environnement de développement « base », vous disposez de votre solution de base avec les tables non managées courantes et aucune autre table. Exportez ensuite cette solution en tant que solution gérée.
  2. Vous configurez un deuxième environnement de développement pour la couche d’extension ou d’application qui résidera ultérieurement au-dessus de la couche de base.
  3. Vous importez la couche de base managée dans l’environnement de développement de couche d’application et créez une solution non managée pour la couche d’application. Superposition de solutions appropriée à l’aide de plusieurs solutions avec plusieurs environnements.
  4. Vous pouvez désormais étendre le modèle de données en ajoutant des tables, des colonnes, des relations de table, des plug-ins, des flux, et ainsi de suite, à la solution « application » spécifique. Vous exportez ensuite cette solution d’application comme gérée. Notez que la solution d’application dépend toujours de la solution de couche de base, mais la gestion de plusieurs solutions de cette façon est une meilleure approche. Considérons l’exemple précédent du flux qui s’appuie sur une colonne personnalisée. Dans la plupart des cas, la colonne personnalisée et le flux résident dans la même solution d’application. Mais même si la colonne personnalisée fait partie de la solution de base, vous devez effectuer et déployer cette solution de base en tant que solution gérée en premier, sinon, le flux à l’intérieur de la solution d’application ne peut même pas être créé.
  5. Dans votre environnement de production, vous importez la couche de base gérée, puis importez la couche d’application gérée. Cela crée deux couches managées dans l’environnement avec des dépendances claires entre les solutions managées.
  6. Répétez ce modèle pour avoir autant de solutions différentes que nécessaire. Bien que nous vous recommandons de garder le nombre de solutions aussi petit que possible pour garder votre solution en couches gérable.

Utiliser la segmentation de table
Scénario 5 : Soutenir le développement de l’équipe

  • Last updated on