Branching: diferentes archivos de configuración para lanzamiento/desarrollo

Question

Heredé un proyecto y estamos usando git. Tenemos varios entornos (dev, test, prod). El equipo anterior recreó básicamente todo en cada instancia, utilizando las mismas cuentas, contraseñas, sid, etc. Lo único que cambió fueron las asignaciones de nombres de host en/etc/hosts. Para que se conectara a un servidor de base de datos diferente.

Ahora, esto crea un problema, porque no puedo, por ejemplo, copiar un esquema para que un desarrollador pueda ejecutar un experimento utilizando la misma instancia de base de datos que el servidor de desarrollo principal. Básicamente, tengo que crear una nueva instancia de base de datos en otro host y cambiar/etc/hosts para que apunte a ese nuevo servidor.

Si bien esta es una configuración en funcionamiento, estoy tratando de encontrar una forma de mantener diferentes archivos de configuración para cada instancia. es decir: diferentes versiones de applicationConfig.xml dependiendo de la rama. Supongo que se podría argumentar que mantener la credencial de la base de datos en el repositorio no es una gran idea, pero solo ignorémoslo por un segundo.

Otra situación que podría justificar tener una versión diferente de un archivo podría ser la depuración. Digamos que estoy usando un marco de registro de JavaScript y agrego un código de depuración que no desearía enviar con una versión de producción. No quiero tener que agregar las cosas del registrador al desarrollar/probar y luego quitarlo nuevamente antes de liberarlo. Uno podría olvidarse de hacerlo.

¿Cuál es la forma correcta de tratar con las diferentes "versiones" de un archivo para diferentes ramas? ¿Hay alguna forma de tener una rama que permanezca sincronizada con el último código en el maestro, pero con unos pocos archivos de configuración/código modificados? No espero que se mantenga sincronizado automáticamente, pero me gustaría poder fusionar los archivos de configuración (o partes de ellos), sin ignorarlos por completo (?). Por ejemplo: no combine líneas 6,7 (nombre de usuario y contraseña de db), pero combine los otros cambios en los archivos.

Answer 1

Parece que deberías leer sobre los atributos de git. Check out the section at the bottom of this page

Esto es útil si una rama en su proyecto se ha desviado o es especializada, pero que desea ser capaz de combinar los cambios de vuelta en de ella, y que desea ignorar ciertos archivos. Digamos que tiene una configuración de base de datos archivo llamado database.xml que es diferente en dos ramas, y desea fusionar en su otra rama sin arruinar el archivo de base de datos .

Answer 2

Como ya dijo, no es una buena idea almacenar las configuraciones dentro de su código. Especialmente, tus desarrolladores ni siquiera deberían saber las credenciales para la base de datos de producción, en mi opinión.

Lo que hacemos aquí es que en cada servidor tenemos variables de entorno predefinidas que apuntan a un archivo de configuración que tiene las credenciales necesarias. Como estamos utilizando Java aquí, este es un archivo como database.properties y este archivo nunca está dentro de un sistema de control de versiones.

Esto también permite tener diferentes configuraciones y credenciales diferentes en cada servidor