Comment traitez-vous le déploiement de fichiers de configuration sur différents systèmes dans Subversion?

Question

Subversion est un excellent moyen de mettre à jour nos applications Web sur nos serveurs. Avec un simple svn update tous les fichiers modifiés sont ... bien, changé. À l'exception des fichiers de configuration omniprésents tels que config.php qui contiennent la configuration de l'accès à la base de données, les chemins de serveur etc. Et sont donc différents sur mon système de développement local et sur le serveur distant.

Avec la commande update, un fichier modifié sur le serveur ne sera pas écrasé, mais si je modifie le fichier localement et le valide, le serveur obtient le mauvais fichier de configuration.

Mais je ne veux pas non plus définir la propriété svn:ignore car le fichier de configuration appartient au projet.

Existe-t-il un mécanisme Subversion qui me permettra de gérer facilement ce genre de fichiers? Ou est la seule façon de résoudre ce problème pour faire un changement de système dans le fichier de configuration qui va déterminer le système d'exécution et définit la configuration en conséquence?

Answer 1

Je trouve que le moyen le plus simple est d'activer le nom d'hôte de la machine. J'ai un fichier .ini avec une section générale qui l'emporte également sur les systèmes de production, de test et de développement.

[general] 
info=misc 
db.password=secret 
db.host=localhost 

[production : general] 
info=only on production system 
db.password=secret1 

[testing : general] 
info=only on test system 
db.password=secret2 

[dev : general] 
info=only on dev system 
db.password=secret3 

Alors dev: db.password == 'secret3', mais dev: db.host == 'localhost', du groupe 'général' d'origine.

La « production », « testing » et « dev » pourrait être la machine hostname, ou ils sont des alias pour les mettre d'un autre mécanisme dans un script de contrôle de configuration.

Answer 2

Créez un modèle pour le fichier (par exemple, config.php-default) et laissez l'utilisateur copier le modèle. Elle peut aussi faire un diff pour voir ce qui a changé entre les versions pour intégrer ces changements dans la version déployée localement du fichier.

Answer 3

Sur les projets sur lesquels je travaille actuellement, nous avons 2 fichiers de propriétés pour les informations de schéma de base de données - un pour l'environnement de production et un pour le développement. Nous avons une classe qui charge toutes nos propriétés pour le module en cours d'exécution, avec une logique qui détermine le fichier à charger. Comme notre environnement de développement est localement un système de fichiers Windows et que les serveurs de production fonctionnent sur des systèmes de fichiers UNIX, notre solution consistait à déterminer le système d'exploitation de l'hôte et à charger le bon fichier.

Nous les gardons directement dans notre contrôle de source afin de garder un historique de toutes les modifications apportées. Je pense que nous avons appris une leçon de notre doigt (interne) pointant du doigt en ce qui concerne EXIGENCES FORTEMENT FRÉQUENT CHANGEMENTS, en ce sens que nous devions être en mesure de défendre l'un des changements passés aux fichiers.

Cela peut être unique pour notre situation, mais j'ai trouvé cela extrêmement utile, surtout si j'essaie de reproduire un test d'une révision précédente.

Answer 4

Quelques solutions possibles:

Si vous utilisez un serveur d'applications J2EE, vous pouvez rechercher des propriétés à travers JNDI, il existe des outils pour configurer facilement et de les visualiser sur le serveur. Vous pouvez avoir un fichier de propriétés par défaut dans votre serveur Subversion, mais chercher ailleurs sur les serveurs (en dehors des parties du projet qui sont vérifiées dans svn) pour le fichier de propriétés réelles, mais vous obtenez généralement des chemins dépendants du système d'exploitation. N'oubliez pas de mettre à jour les fichiers de propriétés réels manuellement lorsque vous ajoutez de nouvelles propriétés dans votre fichier svn.

Vous pouvez définir les propriétés dans un fichier de propriétés dans le cadre de la génération et transmettre un paramètre à la commande de construction pour indiquer à quel environnement de serveur construire. Cela peut sembler un peu rond, et vous devez vous rappeler de mettre à jour le script de construction avec de nouvelles propriétés. Mais cela peut fonctionner correctement - si vous configurez un serveur d'intégration continue, il peut être construit pour tous les environnements différents et tester les bundles pour vous. Ensuite, vous savez que vous avez quelque chose de prêt à déployer.

Answer 5

Vous voudrez peut-être considérer le fait que les développeurs n'auront pas (et ne devraient probablement pas) avoir accès au nom d'utilisateur/mot de passe pour la machine de production. Pour faire face à cette situation, une telle configuration doit être considérée comme des «détails de déploiement» plutôt que comme une configuration d'application globale. Même lorsque vous faites cette distinction conceptuelle, vous devez toujours gérer les différents environnements de déploiement mais, comme vous semblez traiter avec PHP, je ne peux pas commenter les détails de votre cas. Comme Lars mentionné, une solution J2EE possible est de stocker ces détails sous JNDI, ce qui rend le même binaire d'application déployable sur tout environnement, laissant DBAs/Admins pour définir le nom d'utilisateur/mot de passe pour chaque machine.

Answer 6

Vous pouvez également faire dépendre votre domaine de fichier de configuration. De cette façon, vous pouvez créer une configuration pour votre machine locale et pour le (s) serveur (s) de production. Vous avez besoin de construire la logique bien sûr pour gérer cela. Si vous utilisez un serveur web apache, vous pouvez facilement le configurer pour que chaque développeur utilise son propre (sous-) domaine dans sa boîte locale au lieu de simplement utiliser localhost. De cette façon, chaque développeur peut utiliser sa propre configuration.