Fichiers semi-modifiables (fichiers de configuration, par exemple) et contrôle de version - meilleures pratiques?

Question

Donc, j'ai tué la construction aujourd'hui en vérifiant un fichier de configuration. Il sait où se trouve le serveur (pensez au serveur SQL ou autre), et j'ai travaillé sur le serveur qui fonctionne sur ma machine. Normalement, ou plutôt, dans d'autres circonstances, nous courions contre le serveur central. La construction quotidienne, bien sûr, n'a pas trouvé «mon» serveur, d'où la casse. Ensuite, éditer le fichier de configuration pour pointer vers le serveur 'normal' avant l'archivage, et le ré-éditer après l'enregistrement est tendineux.

J'ai été tenté d'avoir VC juste ignorer le fichier de configuration, de sorte qu'il ne soit pas vérifié accidentellement. D'un autre côté, le référentiel doit contenir une version propre et utilisable du fichier. Je ne peux pas l'ignorer et l'enregistrer en même temps, maintenant, pourrais-je? Donc, ce que je cherche serait un moyen d'avoir un fichier qui, errr, qui vérifie, mais ne vérifie jamais. Au moins dans le cas le plus commun - si le fichier de configuration change de manière significative, certains spéciaux procédure pour obtenir la nouvelle version dans le référentiel serait faisable.

Si vous avez déjà rencontré ce problème, je serais intéressé par les solutions que vous avez trouvées. Tant qu'ils ne cassent pas la construction, c'est;)

Answer 1

Ce que vous pouvez faire est d'avoir un fichier de configuration par défaut qui reste inchangé, à moins qu'une nouvelle configuration ne soit ajoutée. Ensuite, vous avez un fichier différent qui remplace les configs du fichier par défaut.

config.Default.xml 
config.User.xml 

Seul config.Default.xml est contrôlé par la source. config.User.xml contient uniquement les configurations qui sont différentes pour vous. Donc, disons que vous testez sur un serveur SQL local, vous ne mettez que la chaîne de connexion et il écrasera la chaîne de connexion config.Default.

Jetez un coup d'œil à la configuration de l'application .Net Framwork, elle effectue la plupart (sinon la totalité) du travail pour vous.

Answer 2

Une méthode que j'ai utilisée est d'avoir deux versions du fichier de configuration, et que le script installeur tire la bonne version.

• settings.xml
• settings.xml libération

Les deux fichiers contiennent les mêmes clés, mais contient « dev » les valeurs et l'autre contient les valeurs nous nous attendons à déployer et à éditer Sur le terrain.

Answer 3

Si je travaillais, nous avons des fichiers de configuration séparés pour les déploiements. Donc les fichiers de configuration dans nos solutions sont les versions de développement et les gens peuvent les changer au contenu de leur coeur. Ces fichiers de configuration ne sont jamais déployés nulle part.

Les fichiers de configuration déployés sont stockés dans un emplacement distinct de notre fournisseur de contrôle de source. Si quelqu'un doit effectuer un changement de configuration qui sera déployé, il doit plutôt modifier cette version.

Answer 4

Nous stockons ce type de fichiers dans notre système de contrôle de source, et nous avons différents dossiers pour l'environnement pour lequel nous construisons.

Nous avons donc:

Dev 
Test 
Live 

Il y a les sous-dossiers pour ces autres fichiers spécifiques de l'environnement.

Answer 5

Nous avons

• *. (Config | xml)
• *. (Config | xml) .cert
• *. (Config | xml) .Production

Hudson supprime le fichier initial et déploie le fichier correct pour l'environnement correct (actuellement seul cert).

Cela permet aux développeurs de documenter et de développer des fichiers de configuration de production, de cert et de niveau de développement de manière indépendante et de les avoir versionnés séparément dans SVN.

Answer 6

Pour chaque fichier de configuration x, créez un fichier que vous devez enregistrer, appelé x.dist, qui est la configuration distribuée par défaut. Une fois que les développeurs ont vérifié, ayez un script qui copie chaque fichier x.dist en x, où ils peuvent personnaliser x autant que nécessaire. Ce script peut être réexécuté pour mettre à jour les fichiers suite à des changements majeurs, ou les développeurs peuvent fusionner manuellement leurs modifications.

Pour le déploiement, vous pouvez archiver vos fichiers de déploiement en direct et faire en sorte que vos scripts de démarrage s'y réfèrent explicitement (par exemple, --config x.production). Cette approche est utilisée, par exemple, dans la distribution de Wordpress (vous devez copier un fichier template wp-config.php) ou dans les projets de développement utilisant autoconf (où configure.ac est archivé mais le fichier configure doit être généré par chaque développeur, un fichier de configuration spécial est créé pour la distribution dans les archives tar au moment de la publication).

Answer 7

Je pense que la réponse acceptée est bonne, mais en fonction de vos besoins, il peut y avoir des limites.

Nous utilisons l'approche suivante. Notez que nous sommes un magasin .NET utilisant VS et utilisons des tâches MSBuild (intégrées, communautaires et personnalisées).

• App.config est ignoré par le contrôle de version, mais inclus dans le projet.
• App.default.config est sous le contrôle de version et également inclus dans le projet. Au lieu de choses codées en dur qui peuvent changer, par ex. chaînes de connexion db, nous utilisons des jetons à la place.

tâche BeforeBuild cherche existance est un projet de App.config et si pas trouvé des copies App.default.config à App.config. En outre, le serveur de génération supprime toujours App.config s'il existe sur une génération CI (garantit une configuration propre). Nous utilisons également la tâche MSBuild Community FileUpdate pour remplacer les jetons par les valeurs appropriées en fonction de la construction du projet.

Par exemple, une caisse de révélateur frais peut les chaînes de connexion de configuration db pour une base de données locale, une nightly build peut configurer pour la nuit db, etc.

Answer 8

La réponse acceptée est bonne.Cependant, il est possible de faire ce que vous voulez (il y a 4 ans), et maintenir un seul fichier de configuration qui vérifie et ne vérifie jamais - si votre système de contrôle de version a le concept des listes de modifications. J'ai fait cela dans Perforce:

Vérifiez le fichier de configuration et conservez-le dans sa propre liste de modifications. Lorsque vous commettez, ne commettez que les autres changelists; C'est facile à retenir si vous nommez votre liste de modifications de fichier de configuration quelque chose comme "NE PAS COMMIT". Un avantage de ce système est que si quelqu'un d'autre change la version de production du fichier de configuration - c'est-à-dire celle qui existe sur le serveur, et dont tout le monde maintient une version locale modifiée - alors vous serez averti de conflits possibles lorsque vous obtenez le fichier de configuration du serveur. Avec une solution comme celle suggérée dans la réponse acceptée, vous pouvez continuer à ignorer silencieusement les nouveaux paramètres de production avec vos paramètres locaux, ce qui pourrait casser votre build local ou vous faire casser la construction lors de la prochaine validation.