Instance de préproduction (Staging) ou de production ?
Vous ne devriez vraiment pas modifier vos configurations en fonction de si vous êtes en production ou en préproduction (staging). La zone de staging n’est pas conçue pour être un environnement de « QA » mais uniquement une zone de transit avant le déploiement en production.
Lorsque vous téléversez un nouveau déploiement, l’emplacement de déploiement actuel où vous téléversez votre package est détruit et est indisponible pendant 10-15 minutes pendant le téléversement et le démarrage des machines virtuelles. Si vous téléversez directement en production, cela représente 15 minutes d’indisponibilité en production. C’est pourquoi la zone de staging a été inventée : vous téléversez vers le staging, testez, et cliquez sur le bouton « Swap » et votre environnement de staging devient magiquement la production (échange d’IP virtuelle).
Ainsi, votre staging devrait vraiment être 100 % identique à votre production.
Ce que vous recherchez, je pense, est un environnement de QA/test ? Vous devriez ouvrir un nouveau service pour l’environnement de test avec ses propres Production/Staging. Dans ce cas, vous voudrez maintenir plusieurs jeux de fichiers de configuration, un jeu par environnement de déploiement (Production, Test, etc.)
Il existe de nombreuses façons de gérer le « chaos de configuration » qui survient, surtout avec Azure qui a, en plus des fichiers .config, ses propres fichiers *.cscfg. La manière dont je préfère le faire avec un projet Azure est la suivante :
Configurez un petit projet Config, créez-y des dossiers correspondant aux types de déploiement. À l’intérieur de chaque dossier, configurez des jeux de fichiers *.config et *.cscfg correspondant à un environnement de déploiement particulier : Debug, Test, Release… ceux-ci sont également configurés dans Visual Studio comme types de cibles de build. J’ai une petite commande xcopy qui s’exécute à chaque compilation du projet Config et qui copie tous les fichiers du dossier de la cible de build du projet Config vers le dossier racine du projet Config.
Ensuite, chaque autre projet de la solution RELIE au fichier .config ou .cscfg depuis le dossier racine du projet Config.
Et voilà, mes configurations s’adaptent magiquement à chaque configuration de build automatiquement. J’utilise également les transformations .config pour gérer les informations de débogage pour les cibles de build Release vs non-Release.
Si vous avez
(Réponse tronquée)