¿Cómo se trata la implementación de archivos de configuración en diferentes sistemas en Subversion?

Question

Subversion es una excelente manera de actualizar nuestras aplicaciones web en nuestros servidores. Con un simple svn update todos los archivos cambiados se ... cambian.

Excepto por los archivos de configuración omnipresentes como config.php que contienen la configuración de acceso a la base de datos, las rutas del servidor, etc. Y, por lo tanto, son diferentes en mi sistema de desarrollo local y en el servidor remoto.

Con el comando update, un archivo modificado en el servidor no se sobrescribirá, pero si cambio el archivo localmente y lo confirmo, el servidor obtiene el archivo de configuración incorrecto.

Pero tampoco quiero establecer la propiedad svn:ignore, ya que el archivo de configuración pertenece al proyecto.

¿Existe un mecanismo de Subversión que me permita manejar fácilmente este tipo de archivos? ¿O es la única forma de resolver este problema hacer que un sistema cambie dentro del archivo de configuración que determinará el sistema de ejecución y establecerá la configuración en consecuencia?

Answer 1

Me parece que la forma más fácil es activar el nombre de host de la máquina. Tengo un archivo .ini con una sección general que también anula esto para los sistemas de producción, prueba y desarrollo.

[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 

Así dev: db.password == 'secret3', pero dev: db.host == 'localhost', del grupo original de 'general'.

La 'producción', 'prueba' y 'dev' podrían ser los nombres de host de la máquina, o son alias para ellos configurados a partir de algún otro mecanismo en una secuencia de comandos de control de configuración.

Answer 2

Cree una plantilla para el archivo (por ejemplo, config.php-default) y permita que el usuario copie la plantilla. También puede hacer una diferencia para ver qué cambió entre las versiones para incorporar estos cambios en la versión implementada localmente del archivo.

Answer 3

En los proyectos en los que estoy trabajando tenemos 2 archivos de propiedades para la información del esquema de la base de datos, uno para el entorno de producción y otro para el desarrollo. Tenemos una clase que carga todas nuestras propiedades para el módulo que se está ejecutando, con lógica que determina qué archivo cargar.

Dado que nuestro entorno de desarrollo a nivel local es un sistema de archivos de Windows y los servidores de producción operan en sistemas de archivos UNIX, nuestra solución fue determinar el sistema operativo del host y cargar el archivo correcto.

Mantenemos estos directamente dentro de nuestro control de fuente con el fin de mantener un historial de los cambios realizados. Creo que aprendimos una lección de nuestro dedo del cliente (interno) señalando con respecto a CAMBIOS EN REQUISITOS INSUFICIENTEMENTE FRECUENTES, en el que necesitábamos poder defender cualquiera de los cambios pasados ​​en los archivos.

Esto puede ser único para nuestra situación, pero he encontrado que es extremadamente útil, especialmente si estoy tratando de replicar una ejecución de prueba de una revisión anterior.

Answer 4

Algunas posibles soluciones:

Si está utilizando un servidor de aplicación J2EE, se puede consultar a través de JNDI propiedades, existen herramientas para configurar fácilmente y verlos en el servidor.

Puede tener un archivo de propiedades predeterminado en su servidor de subversión, pero busque en otros servidores (fuera de las partes del proyecto que están registradas en svn) para el archivo de propiedades reales, pero normalmente obtendrá rutas dependientes del sistema operativo y Recuerde que debe actualizar manualmente los archivos de propiedades reales cuando agrega nuevas propiedades en su archivo svn.

Puede establecer las propiedades en un archivo de propiedades como parte de la compilación y pasar un parámetro al comando de compilación para indicarle para qué entorno de servidor se debe compilar. Esto puede parecer un poco indirecto, y debe recordar actualizar el script de compilación con nuevas propiedades. Pero puede funcionar bien: si configura un servidor de integración continua, puede compilar para todos los diferentes entornos y probar los paquetes por usted. Entonces sabrá que tiene algo preparado para el despliegue.

Answer 5

Es posible que desee considerar el hecho de que los desarrolladores no tendrán (y probablemente no deberían) tener acceso al nombre de usuario/contraseñas de la máquina de producción.

Para hacer frente a esto, dicha configuración debe considerarse como 'detalles de implementación', en lugar de la configuración general de la aplicación. Incluso cuando hace esta distinción conceptual, aún necesita lidiar con los diferentes entornos de implementación pero, como parece que se trata de PHP, no puedo comentar los detalles de su caso.

Como mencionó Lars, una posible solución J2EE es almacenar dichos detalles bajo JNDI, haciendo que la misma aplicación binaria se despliegue en cualquier entorno, dejando que los DBA/Administradores establezcan el nombre de usuario/contraseña para cada máquina.

Answer 6

También puede hacer que su dominio de archivo de configuración dependa. De esta forma, puede crear una configuración para su máquina local y para los servidores de producción. Necesitas construir la lógica, por supuesto, para manejar esto.

Si ejecuta apache webserver, puede configurarlo fácilmente para que cada desarrollador use su propio (sub) dominio en su casilla local en lugar de simplemente usar localhost. De esta forma, cada desarrollador puede usar su propia configuración.