Git: configuración de la aplicación y diferentes entornos

Question

Usamos git para la mayoría de las aplicaciones web que creamos en nuestra tienda, y aunque las aplicaciones usan una variedad de tecnologías (PHP, Rails, etc.), generalmente tenemos una puesta en escena y producción servidor para cada sitio. Normalmente, estos servidores tienen diferentes conjuntos de credenciales de base de datos, así como diferentes configuraciones de configuración basadas en el entorno (por ejemplo, almacenamiento en caché). Nuestro flujo de trabajo generalmente implica el mantenimiento de dos ramas de git por proyecto: maestro, que refleja el servidor de producción, y organización, que refleja la puesta en escena. Las nuevas características se desarrollan en etapas (o una sub-bifurcación) y se fusionan de nuevo a maestro una vez finalizado e implementado.

Mi pregunta es con respecto a la mejor manera de mantener los archivos de configuración que son específicos de rama y entorno. He visto las respuestas de las preguntas similares here y here, y ninguna de las dos me satisface. Los dos enfoques principales parecen ser: a) usar la exclusión de .gitignore para dejar los archivos de configuración fuera del ámbito de git, o b) escribir un código reflexivo y respetuoso con el entorno que determine, p. qué credenciales de base de datos usar en base al nombre de host. Mi problema con a) es que solo permite que exista un conjunto de archivos de configuración en la base de código (independientemente de la rama actual), por lo que los archivos de configuración del otro entorno se pierden. b), por otro lado, simplemente parece requerir una modificación innecesaria de la base de código de una manera que no se siente relacionada con la funcionalidad de la aplicación.

Idealmente, me gustaría una forma de "bloquear" los archivos de configuración dentro de una determinada rama, de modo que cada vez que obtengo el master, obtengo los archivos de configuración maestra, y cada vez que pago, obtengo los archivos de configuración provisional. Además, fusionar la transición al maestro no debería afectar los archivos de configuración maestra de ninguna manera. Hasta la fecha, hemos solucionado esto al tener carpetas que contienen archivos de configuración específicos del entorno fuera de la raíz de git y mover manualmente los archivos apropiados a la base de código durante la implementación, pero esto es, por supuesto, innecesariamente peligroso (y potencialmente peligroso).

¿Hay alguna manera de lograr esto usando git?

Gracias por su atención!

Answer 1

No estoy seguro de por qué las personas piensan que pueden escaparse sin algún tipo de herramienta de instalación. Git se trata de hacer un seguimiento de la fuente, no de implementarla. Aún debe tener una herramienta de tipo "make install" para pasar de su repositorio de git a la implementación real, y esta herramienta puede hacer varias cosas, como la expansión de plantillas o la selección de archivos alternativos.

Por ejemplo, es posible que haya configurado "config.staging" y "config.production" en git, y cuando implemente en etapas, la herramienta de instalación selecciona "config.staging" para copiar a "config". O puede que tenga un solo archivo "config.template", que tendrá la función de hacer "config" en la implementación.

Answer 2

Supongo que, por lo general, master solo contiene confirmaciones que ya están en staging. Si agrega una confirmación adicional al master que contiene las diferencias en la configuración entre las dos ramas, entonces al volver a establecer esta confirmación en la parte superior de lo que se extraiga del staging se debe mantener la configuración. Esto no es tan simple como "fusionar la puesta en escena en el maestro no debería afectar a los archivos de configuración maestra de ninguna manera", pero como tendrías un conflicto de combinación en estos casos, puede ser lo suficientemente cerca.

Answer 3

Puede intentar usar los ganchos post-merge o post-checkout para verificar que todo esté como debería y, de lo contrario, corríjalo. Esto realmente seems to be suggested by the ProGit book.

El concepto es básicamente escribir esos ganchos para actuar como mini scripts de "make install" que aseguran la configuración correcta por bifurcación, host, presencia o contenido de otros archivos, por lo que sea que desee.Los ganchos podrían incluso reescribir sus archivos de configuración o recrearlos completando plantillas.