Comment gérez-vous les chaînes de connexion lors du déploiement d'un site ASP.NET?

Question

À l'heure actuelle, nos bases de données de test et de production sont sur le même serveur, mais avec des noms différents. Déployer a signifié l'édition de Web.config pour changer toutes les chaînes de connexion pour la base de données correcte. Une étape que j'oublie trop souvent ...

Nous avons enfin créé un nouveau serveur de base de données pour le test, et je déplace les bases de données ... mais maintenant le serveur sera différent et nous serons toujours besoin de gérer les problèmes de chaîne de connexion. Je pensais à le gérer via un fichier hosts, mais l'idée de le changer sur mon ordinateur de bureau chaque fois que j'ai besoin de tester les données de production me semble lourde. Donc, je me demande simplement s'il existe un meilleur moyen de le faire. Quelque chose qui construirait avec une configuration web « de production » pour le déploiement serait idéal ...

Answer 1

ont des dossiers environnementaux avec configs séparés pour chaque environnement

déployer la bonne pour l'environnement

Answer 2

I habituellement avoir trois configurations web distinctes: une pour ma machine de développement, une pour l'assurance qualité et une pour la production. Le développement se connecte à ma base de données SQL locale (qui est pare-feu de l'extérieur) et c'est le web.config par défaut. Les autres sont nommés web-prod.config et web-qa.config. Après la publication, je supprime les deux dont je n'ai pas besoin et je renomme le bon pour web.config. Si j'oublie, l'application rompt la première fois qu'elle tente d'accéder à la base de données, car la configuration par défaut fait référence à celle à laquelle elle ne parvient pas. Comme IIS refuse de servir un fichier nommé .config, je m'assure qu'ils se terminent tous par .config au lieu de dire web.config-prod ou web.config-qa.

Answer 3

Je l'ai fait si souvent, j'ai fait le web.config sur le serveur de production en lecture seule.

Answer 4

Utilisez un Web Deployment Project et mettez à jour le fichier wdproj (c'est juste un fichier MSBuild) avec des tâches de post-construction pour générer le fichier .config correct. Je garde un web.config et web.release.config ensuite utiliser dans le fichier wdproj:

<Target Name="AfterBuild"> 
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" /> 
    <Delete Files="$(OutputPath)\web.release.config" /> 
</Target> 

More information

Une solution plus simple est d'utiliser certains aiment configSource property of appSettings and connectionStrings et jamais sur ce fichier écraser le serveur de production .

Answer 5

Voici une autre chose que vous pouvez essayer:

Utilisation du Gestionnaire de configuration SQL Server, faire un alias db pour votre base de données de développement afin que le fichier web.config peut être le même sur votre boîte de développement et le serveur de production.

Answer 6

Je vais mettre mes chaînes de connexion dans le fichier machine.config dans nos boîtes de contrôle qualité et de production. Je vais les garder dans le web.config sur ma boîte de dev pour la flexibilité, cependant. Ensuite, je vais utiliser un projet de déploiement Web pour écraser mes chaînes de connexion de développement avec rien (pas de chaînes de connexion) lors du déploiement au contrôle qualité. Par conséquent, le site de contrôle qualité s'appuie sur les chaînes de connexion dans machine.config. Je continue à déployer manuellement dans Production pour m'assurer que tout va bien. Je le fais en copiant manuellement tout de QA (sauf pour web.config) à la production.

Answer 7

Je crée un alias de base de données sur chaque serveur pour qu'il pointe vers la base de données. J'utilise ensuite cet alias dans mes fichiers web.config.Si j'ai besoin de changer la base de données vers laquelle l'application pointe, alors je change l'alias et non le web.config.

Pour SQL Server, accédez à SQL Server Configuration Manager> Configuration de SQL Native Client> Alias> Créer un nouvel alias.

Vous pouvez faire la même chose avec Oracle avec le fichier tnsnames.

Answer 8

Ce type de tâche est exactement ce à quoi les événements de construction sont destinés. Pensez à construire en tant que bâtiment pour une cible spécifique, n'importe quelle configuration spécifique de cible devrait être faite là. (avec la mise en garde normale qu'il y a toujours quelques exceptions à la règle)

Answer 9

J'ai été dans quelques endroits maintenant qui les stockent dans le registre.

Il y a probablement des façons plus élaborées de le faire maintenant, mais beaucoup de code sur lequel j'ai travaillé avec un héritage 1.0/1.1 stockent les chaînes dans le registre.

Le registre a quelques avantages

1. Il empêche les gens de déployer le code aux mauvais endroits car les machines ne seront pas configurés correctement manquer les clés
2. Il élimine le problème dans lequel un développeur package accidentellement un Fichier web.config avec les chaînes de connexion de développement (suivi d'un appel téléphonique frénétique au milieu de la nuit où il est révélé que sysadmin tard dans la nuit n'a pas sauvegardé le web.config précédent et que le développeur ne sait pas ou ne se souvient pas les cordes de production)
3. Il limite le poss La possibilité pour un pirate d'obtenir la chaîne de connexion en récupérant le fichier web.config de la machine. De plus, le registre a plus de niveaux de sécurité que le système de fichiers.

Answer 10

Nous conduisons nos déploiements a de notre serveur CI. Nous avons habituellement un fichier séparé pour chaque emplacement et le serveur CI passe à la configuration appropriée en fonction des arguments passés. Toute l'édition de fichier est faite dans des scripts NAnt, donc développe peut exécuter la build sam sur leur machine pour obtenir leurs propres paramètres.

Answer 11

J'ai récemment été penché vers la manipulation de configuration sur le serveur d'intégration continue. C'est parce que nous avons eu des problèmes avec plusieurs web.config, web.qa.config, web.production.config en gardant les 95% du fichier qui devraient être les mêmes en synchronisation. En un mot: il n'y a qu'un seul web.config dans le contrôle de source et c'est la configuration de développement (debug friendly, db local, etc.). Le serveur de construction fait la compilation, puis un déploiement vers le site canari, puis le paquet pour la version candidate. Nous utilisons nant, donc c'est le fichier .build qui a xmlpoke pour définir debug = "false", modifier les chaînes de connexion, et tout ce qui doit être modifié dans la copie canary et la copie d'empaquetage du web.config .

Le déploiement de la machine de construction s'appelle "canary" car c'est la première chose à mourir en cas de problème.