Organiser vos solutions
Avant de créer des solutions, prenez le temps d’y réfléchir. Par exemple, réfléchissez au nombre de solutions que vous souhaitez publier et si les solutions partageront des composants.
En outre, déterminez le nombre d’environnements Microsoft Dataverse dont vous aurez besoin pour développer votre ligne de solutions. Vous pouvez utiliser un seul environnement pour la plupart des stratégies décrites dans cet article. Toutefois, si vous décidez de n’avoir qu’un seul environnement et que vous vous rendez compte par la suite que vous en avez besoin d’autres, il peut être compliqué de modifier les solutions si les utilisateurs les ont déjà installées. L’utilisation de plusieurs environnements, même si cela présente plus de complexité, peut offrir une meilleure flexibilité.
Les sections suivantes décrivent différentes stratégies de gestion des solutions répertoriées de la plus simple à la plus complexe.
Solution unique
En créant une solution, vous créez un ensemble fonctionnel de personnalisations. Cela facilite la recherche des éléments que vous avez personnalisés.
Cette approche est recommandée lorsque vous souhaitez uniquement créer une solution gérée unique. Si vous pensez devoir fractionner la solution par la suite, envisagez d’utiliser plusieurs solutions.
Plusieurs solutions
Si vous avez deux solutions indépendantes qui ne partagent pas de composants, la solution la plus directe consistera à créer deux solutions non gérées.
Note
Il est très courant dans les solutions de modifier les rubans de l’application ou le plan du site. Si vos deux solutions modifient ces composants de solution, elles représenteront des composants partagés. Consultez la section suivante pour voir comment exploiter les composants partagés.
Couches et dépendances de solutions multiples
Lorsque vous importez différentes solutions dans votre environnement cible, vous créez souvent des couches où la solution existante se trouve sous celle en cours d’importation. En ce qui concerne la superposition de solutions, il est important que vous n’ayez pas de dépendances entre les solutions. Il faut éviter d’avoir plusieurs solutions dans le même environnement utilisant le même composant non géré. Cela est particulièrement vrai avec les tableaux.
Segmentez vos solutions par type de composant lorsqu’il n’y a pas de risques de dépendance croisée. Par exemple, ayez une solution qui inclut toutes vos tables, une autre solution qui a tous vos plug-ins et une troisième solution qui a tous vos flux. Ces différents composants ne présentent pas de risques de dépendances entre solutions. Par conséquent, il est sûr d’avoir plusieurs solutions formées de cette manière dans le même environnement.
N’ayez pas deux solutions différentes dans un environnement où les deux contiennent 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.
Lorsque vous concevez vos couches de solution et que vous souhaitez avoir une approche structurée pour les applications, vous devez commencer par une couche de base. Plus tard, vous importez des solutions supplémentaires qui résideront au-dessus de la couche de base. Par la suite, vous avez une couche de base et des couches d’extension au-dessus qui prolongent cette couche de base.
Lorsque vous gérez vos projets de cette manière, nous vous recommandons d’utiliser un environnement distinct pour chaque couche. Créez votre couche de solution en suivant ces étapes.
Avant de créer les solutions dans les étapes suivantes, utilisez un seul éditeur pour toutes vos solutions dans vos environnements. Plus d’informations : Éditeur de solutions
Dans l’environnement « de base », vous avez votre solution de base avec les tables non gérées de cet environnement et aucune autre table. Vous exportez ensuite cette solution comme gérée.
Vous configurez un deuxième environnement pour l’extension ou la couche « app » qui résidera plus tard au-dessus de la couche de base.
Vous importez la couche de base gérée dans l’environnement de couche d’application et créez une solution non gérée pour la couche d’application.
Vous pouvez désormais étendre le modèle de données en ajoutant des tables, des colonnes, une table Relations, etc. supplémentaires dans la solution d’application. Vous exportez ensuite cette solution d’application comme gérée. Notez que la solution d’application aura des dépendances sur la solution de couche de base.
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 gérées dans l’environnement avec des dépendances claires entre les deux solutions gérées. La gestion de plusieurs solutions de cette manière ne créera pas de dépendances entre les solutions, ce qui peut entraîner des problèmes de maintenance des solutions, tels que la suppression de la couche supérieure si nécessaire.
Répétez ce modèle de segmentation 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.
Voir aussi
Utiliser des solutions segmentées
Scénario 5 : Soutenir le développement de l’équipe