Git: configuration de l'application et différents environnements

Question

Nous utilisons git pour la plupart des applications web que nous construisons dans notre boutique, et bien que les applications elles-mêmes utilisent une variété de technologies (PHP, Rails, etc), nous avons généralement une mise en scène et de production serveur pour chaque site. Généralement, ces serveurs ont différents ensembles d'informations d'identification de base de données ainsi que différents paramètres de configuration basés sur l'environnement (par exemple, la mise en cache). Notre flux de travail implique généralement la maintenance de deux branches git par projet: le maître, qui reflète le serveur de production, et la mise en scène, qui reflète la mise en scène. De nouvelles fonctionnalités sont développées sur une mise en scène (ou une sous-branche) et sont fusionnées à la version principale à la fin et au déploiement.

Ma question concerne la meilleure façon de gérer les fichiers de configuration qui sont propres à une branche ou à un environnement. J'ai vu les réponses à partir de questions similaires here et here, et ni vraiment satisfait. Les deux principales approches semblent être a) l'utilisation de l'exclusion .gitignore pour laisser les fichiers de configuration en dehors de la compétence de git, ou b) l'écriture d'un code réfléchissant, respectueux de l'environnement, qui détermine par ex. quelles informations d'identification de base de données utiliser en fonction du nom d'hôte. Mon problème avec a) est qu'il permet seulement à un ensemble de fichiers de configuration d'exister dans la base de code (indépendamment de la branche courante), donc les fichiers de configuration de l'autre environnement sont perdus. b), d'autre part, semble juste exiger une modification inutile de la base de code d'une manière qui ne se sent pas liée à la fonctionnalité de l'application. Idéalement, je voudrais un moyen de "verrouiller" les fichiers de configuration dans une certaine branche, de sorte que chaque fois que je mets en caisse master, j'obtiens les fichiers de configuration maître, et chaque fois que je passe en caisse, j'obtiens les fichiers de configuration. De plus, la fusion de la mise en scène dans le maître ne devrait en aucun cas affecter les fichiers de configuration principaux. À ce jour, nous avons traité cela en ayant des dossiers contenant des fichiers de configuration spécifiques à l'environnement en dehors de la racine git et en déplaçant manuellement les fichiers appropriés dans le codebase lors du déploiement, mais cela est bien sûr inutilement hackish (et potentiellement dangereux).

Existe-t-il un moyen d'accomplir cela en utilisant git?

Merci de votre considération!

Answer 1

Vous ne savez pas pourquoi les gens pensent pouvoir s'échapper sans outil d'installation. Git est sur le suivi de la source, pas sur le déploiement. Vous devriez toujours avoir un outil de type "make install" pour passer de votre repo git au déploiement réel, et cet outil pourrait faire diverses choses comme l'extension de template, ou la sélection de fichiers alternatifs. Par exemple, vous pouvez avoir "config.staging" et "config.production" archivés dans git, et lorsque vous déployez dans le stockage intermédiaire, l'outil d'installation sélectionne "config.staging" pour copier dans "config". Ou vous pourriez avoir un seul fichier "config.template", qui sera modélisé pour faire "config" dans le déploiement.

Answer 2

Je suppose que généralement, ne détient que master commits qui sont déjà en staging. Si vous ajoutez un commit supplémentaire à master qui contient les différences de configuration entre les deux branches, le fait de rebaser ce commit au-dessus de ce qui est tiré de staging devrait maintenir la configuration. Ce n'est pas aussi simple que "fusionner la mise en scène dans le maître ne devrait en aucune façon affecter les fichiers de configuration maître", mais comme vous obtiendrez un conflit de fusion dans ces cas, il peut être assez proche.

Answer 3

Vous pouvez essayer d'utiliser les points d'ancrage post-fusion ou post-vérification pour vérifier que tout est comme il se doit et corrigez-le dans le cas contraire. Ceci en fait seems to be suggested by the ProGit book. Le concept consiste essentiellement à écrire ces hooks pour qu'ils agissent comme de minuscules scripts «make install» qui assurent la configuration correcte par branche, par hôte, par la présence ou le contenu d'autres fichiers, selon ce que vous voulez.Les hooks pourraient même réécrire vos fichiers de configuration ou les recréer en remplissant des templates.