Nous avons 7 composants différents et 7 environnements différents où nous installons tous ces composants. Donc, lorsque ces composants sont installés sur ces différents environnements, il y a de fortes chances que nous n'ayons pas besoin de changer les noms des serveurs en URL.gestion de fichier de configuration pour les applications .net
Toute suggestion de gestion de ces nombreux fichiers de configuration eviournment de manière bien conçue.
Qu'en est-il de l'utilisation d'un programme d'installation, lorsque vous installez l'application, assurez-vous que l'utilisateur change réellement le fichier de configuration via l'installateur?
Bien, selon ce dont vous avez besoin, vous pouvez stocker tous les éléments modifiables dans une base de données. Une autre approche que nous avons utilisée dans notre environnement est d'avoir un fichier de configuration par environnement et de laisser notre processus de déploiement pousser le bon fichier à l'emplacement correct. L'inconvénient est que vous devez gérer les différentes versions des fichiers et si vous effectuez un changement, vous devez vous assurer qu'ils sont tous mis à jour.
J'ai vu un certain nombre d'entreprises ayant un outil personnalisé pour cela, avec une petite base de données qui contient les clés qui doivent être changées et la valeur par environnement. Après la construction du projet, mais avant le déploiement, l'outil est exécuté sur la sortie de construction pour modifier les fichiers de configuration de façon appropriée.
Avez-vous envisagé d'utiliser un outil de construction qui vous permettrait de cibler vos différents environnements? J'ai utilisé Visual Build et MS build pour faire des déploiements similaires. Un autre utilisateur ici a également recommandé un outil en cours de développement appelé "dashy" si vous voulez être capable de le vérifier aussi.
nous utilisons cette approche seulement, mais nous avons oublié de mettre à jour l'un des fichiers et il a fallu 8 heures en production pour comprendre le problème – Miral