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 deviennent... eh bien, modifiés.

À 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 du serveur, etc. Et sont donc différents sur mon système de développement local et sur le serveur distant.

Avec le update un fichier modifié sur le serveur ne sera pas écrasé, mais si je modifie le fichier localement et que je le livre, le serveur reçoit le mauvais fichier de configuration.

Mais je ne veux pas mettre le svn:ignore non plus, puisque le fichier de configuration appartient au projet.

Existe-t-il un mécanisme de Subversion qui me permette de manipuler facilement ce type de fichiers ? Ou la seule façon de résoudre ce problème est-elle de faire un changement de système dans le fichier de configuration qui déterminera le système d'exécution et définira la configuration en conséquence ?

Answer 1

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

Answer 2

Vous devez tenir compte du fait que les développeurs n'auront pas (et ne devraient pas) avoir accès aux noms d'utilisateur et aux mots de passe de la machine de production.

Pour y faire face, cette configuration doit être considérée comme des "détails de déploiement", plutôt que comme une configuration globale de l'application. Même si vous faites cette distinction conceptuelle, vous devez toujours gérer les différents environnements de déploiement mais, comme vous semblez avoir affaire à PHP, je ne peux pas faire de commentaires spécifiques à votre cas.

Comme Lars l'a mentionné, une solution J2EE possible est de stocker ces détails sous JNDI, ce qui permet de déployer exactement le même binaire d'application dans n'importe quel environnement, laissant aux DBA/Admins le soin de définir le nom d'utilisateur/mot de passe pour chaque machine.

Answer 3

Sur les projets sur lesquels je travaille actuellement, nous avons 2 fichiers de propriétés pour les informations du schéma de la 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 quel fichier charger.

Comme notre environnement de développement local est 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 conservons directement dans notre contrôle de source afin de garder un historique de toutes les modifications apportées. Je pense que nous avons tiré une leçon du pointage du doigt de notre client (interne) en ce qui concerne les modifications apportées à notre système. DES CHANGEMENTS D'EXIGENCES INCROYABLEMENT FRÉQUENTS En effet, nous devions être en mesure de défendre toutes les modifications apportées aux dossiers dans le passé.

C'est 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 les propriétés par le biais de JNDI, il existe des outils pour les définir et les visualiser facilement 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 vrai fichier de propriétés, mais alors vous obtenez généralement des chemins dépendants du système d'exploitation et devez vous rappeler de mettre à jour les vrais fichiers de propriétés 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 construction, et passer un paramètre à la commande de construction pour lui indiquer l'environnement de serveur pour lequel construire. Cela peut sembler un peu détourné, et vous devez vous rappeler de mettre à jour le script de construction avec les nouvelles propriétés. Mais cela peut bien fonctionner - si vous configurez un serveur d'intégration continue, il peut construire pour tous les différents environnements et tester les bundles pour vous. Vous savez alors que vous avez quelque chose de prêt à être déployé.

Answer 5

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 permet également de remplacer ceci pour 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

Ainsi, dev:db.password == 'secret3', mais dev:db.host == 'localhost', du groupe original 'general'.

Les termes 'production', 'testing' et 'dev' pourraient être les noms d'hôtes des machines, ou bien il s'agit d'alias définis par un autre mécanisme dans un script de contrôle de configuration.