Quelle est la meilleure pratique pour utiliser Subversion (SVN) pour la gestion d'un projet nécessitant un seul fichier de configuration comportant plusieurs versions simultanées pour différents environnements.
I.e.
Je suis conscient qu'un modèle de fichier de configuration et SVN: Ignorer pourrait être utilisé, mais se demandait si quelqu'un pouvait décrire les meilleures pratiques pour cette approche et / ou toute autre alternative appropriée.
Merci d'avance!
m.
4 Réponses :
Je ne sais pas si c'est une "meilleure pratique", mais c'est comme ça que je gère cela et ça fonctionne très bien. J'ai plusieurs applications et ils ont chacun un fichier de configuration distinct pour leurs environnements de production, de stadification et de développement. Les configurations sont nommées web.config, stade.config et dev.config. Tous les trois sont conservés sous la version de la version. L'application s'attend et utilise Web.config pour revenir des paramètres de configuration. Dans le cadre de nos scripts de construction et de déploiement Nant appelés par le contrôle de la croisière, en fonction de l'environnement déployé, la configuration appropriée est renommée sur web.config et déployé.
J'espère que cela aide.
Je seconde cela. En outre, une légère permutation de cette méthode pouvant être utilisée s'il existe très peu de différences entre les fichiers de configuration (c.-à-d. Quelques instructions SQL et quelques paramètres d'application) consiste à stocker les modifications apportées au script de construction, elle-même et utilisez Xmlpeoke de Nant. Mise à jour de la chaîne de connexion appropriée. Vous pouvez ensuite vous empêcher de créer des scripts dans leur propre repo et de conserver les mots de passe de production séparés de votre base de code.
Garder plusieurs fichiers dans le contrôle de la source peut être délicat. Nous utilisons un outil de configuration à domicile qui lit une variable d'environnement système et à partir de celui indiquant un fichier de configuration correspondant, puis modifie un fichier de configuration partagé. Je ne peux pas dire que c'est une excellente solution, mais ça marche.
Pour des années et de nombreux projets différents et réussis, je ne fais tout simplement pas la version du fichier de configuration spécifique du système ou du développeur. Parfois, ce n'est que des informations d'accès à la base de données, ou quelques chemins vitaux ou autre. Rétrécissez-le aussi peu que possible. Ne vous sentez pas mal quant à la version de cette information. Cela a été fait avec chaque nombre entre 2 et 5 développeurs sur plusieurs projets et n'a jamais causé de confusion, de problèmes ou de débats sur des projets du monde réel.
À mon avis, il n'est pas utile de garder tous les fichiers de configuration sous contrôle de la version. Dans l'un de mes projets, nous avons eu des fichiers de configuration créés avec CMAKE pour plusieurs plates-formes (du même modèle). Chaque développement de notre équipe a eu son propre script supplémentaire personnalisé pour créer les configurations nécessaires.
Mais si vous n'avez jamais commis de fichier de configuration sous contrôle de version, comment êtes-vous d'accord sur lequel l'une est la par défaut? ne pas avoir au moins besoin d'un modèle pour être le modèle?