Control de versiones y archivo de configuración personal

Nuestro proyecto utiliza un archivo de configuración específico del usuario. Este archivo no está actualmente en control de versiones, ya que es diferente para cada usuario. El problema es que cada vez que un desarrollador agrega un nuevo módulo que requiere configuración o cambia el nombre de un módulo existente, los otros desarrolladores obtienen errores porque sus archivos de configuración privados no se actualizan.

Para resolver el problema, pensamos en trabajar con dos archivos de configuración: un archivo de configuración predeterminado / global que estará en control de versiones y será actualizado regularmente por cada desarrollador que agregue un nuevo módulo, y un archivo de configuración privado que se mantendrá fuera de control de versiones y contendrá solo los cambios específicos del usuario.

Sin embargo, esto todavía parece una solución ad-hoc.

¿Puedes proponer una solución mejor?

¿Qué hacen los profesionales?

Aunque ya obtuvo algunas buenas respuestas aquí, la mayoría de ellas omiten la causa raíz de su problema: sus archivos de configuración de usuario parecen contener más que solo información específica del usuario, también contienen información (quizás redundante) que está bajo el control de versiones en otro lugar , probablemente en diferentes archivos, como los nombres de los módulos.

Puedo pensar en dos posibles soluciones aquí:

• intenta separar esa información rigurosamente. Por ejemplo, no use ningún nombre de módulo en su configuración de usuario. Use números de identificación (por ejemplo, GUID) para referirse a los módulos, y deje que esos números de identificación nunca cambien después de haber sido asignados a un módulo. Por supuesto, eso probablemente tiene el inconveniente de que sus archivos de configuración de usuario pierden algo de la simplicidad que pueden tener ahora. Quizás necesite crear una herramienta GUI para editar sus archivos de configuración en lugar de usar un editor de texto sin formato.

• asigne a su formato de archivo de configuración un número de versión, y cada vez que cambie algo como el nombre de un módulo, asígneles un nuevo número de versión. Luego, puede proporcionar un script de actualización que verifique los números de versión, y si el archivo de configuración no está actualizado, cambia todos los nombres de módulos que encuentra dentro del archivo y luego aumenta el número de versión. Esto puede automatizarse, por lo que el proceso de actualización no molestará a sus compañeros de equipo en su trabajo diario.

EDITAR: después de leer su publicación nuevamente, creo que su supuesta solución es razonable, siempre y cuando se agreguen nuevos módulos, pero no se les cambie el nombre. Lo que escribí anteriormente permitirá cambiar los nombres de los módulos o la estructura de la configuración de los módulos existentes después. Pero si no necesita eso, me quedaría con la solución más simple.

Es una solución razonable.

Necesita una forma de especificar los valores iniciales de cualquier elemento (s) de configuración nuevo. Estos deben almacenarse en algún lugar y la elección obvia es un archivo de configuración global de solo lectura.

Luego, cuando cada usuario cambia su configuración personal, escribe estos cambios en su copia local.

Su código deberá leer primero la configuración global y la específica del usuario para sobrescribir los valores modificados. Esto será mucho más simple que leer el local y luego tratar de averiguar cuáles no se han configurado y, por lo tanto, deben leerse desde el archivo de configuración global.

Si usa algo como XML para el almacenamiento, entonces no tiene que preocuparse por manejar el caso en el que elimina la configuración. No se les solicitará a los usuarios una copia del archivo y si vuelve a crear el archivo al guardarlo, se eliminarán la primera vez que se use la aplicación después del cambio.

Tenemos una solución algo interesante, somos principalmente desarrolladores de PHP, por lo que usamos Phing que le permite crear tareas automatizadas escritas en PHP, por lo que en lugar de hacer nuestra actualización normal de svn, hacemos una "actualización de phing" que llama svn update, y luego reemplaza nuestras configuraciones con las variables adecuadas, por ejemplo, una configuración:

$db_user = "${test.db_user}";

Entonces, los archivos de configuración están versionados con esa sintaxis interesante, y luego generamos un archivo de configuración adverso, no versionado para mi instancia específica, que reemplaza esas "variables" con configuraciones no versionadas especificadas en archivos ini no versionados. De esta forma, podemos modificar cualquier archivo específico del usuario y hacer que los cambios se completen en otras copias de trabajo.

El programa debe tener una configuración predeterminada en el código para cuando el valor no se encuentra en el archivo de configuración. De esta manera, a medida que se agreguen cosas nuevas, no se romperá, su ruta de actualización sería más fluida y sus usuarios también tendrán una reserva para cuando estropeen el archivo de configuración.

Otro ejemplo más complejo sería el inicio del programa o algún otro punto clave, abra el archivo de configuración utilizando un módulo de inicialización y agregue los valores predeterminados que faltan, pero esto parece bastante pesado.

Ponga un número de versión en el archivo de configuración personal (el número de versión del formato del archivo de configuración).

Haga que el código que procesa el archivo de configuración personal verifique el número de versión y, si está desactualizado, ejecute un procedimiento de actualización. Entonces, básicamente, cualquier persona que realice un cambio que rompa los archivos de configuración existentes debe cambiar el número de versión del formato del archivo de configuración y escribir un procedimiento para actualizar los archivos de configuración de la versión anterior (renombrar secciones, etc.) y volver a guardar ellos.

De todos modos, es probable que desee un proceso como este para los usuarios finales, por lo que también podría usarlo para facilitar la vida de sus desarrolladores.

Normalmente, cómo lo he visto hacer es tener un archivo de configuración con valores predeterminados ingresados ​​en el repositorio. Estos podrían ser, por ejemplo, los valores necesarios en el servidor de prueba. Luego, cuando un desarrollador desprotege el archivo, tendrá todos los valores. Si se agrega un nuevo campo o se elimina un campo, esto se maneja en una fusión. Un desarrollador registrará el valor necesario para el servidor de destino y no registrará ningún otro cambio en los campos que sean para su entorno de desarrollo personal.

Se asegura de que la fusión se realice correctamente, pero me parece bastante segura.

Lo que hacemos aquí es crear bloques de configuraciones. Esto se puede hacer en Zend así:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

Esto significa que las pruebas heredan la producción y la extienden con key3. Todo lo que cada desarrollador necesita hacer es establecer su entorno (prueba o producción en este caso)

Esta es una solución útil basada en la publicación: mantener las contraseñas en el control de origen

En resumen, la estrategia es "mantener una versión encriptada del archivo de configuración en el control de origen y luego proporcionar un medio a través del cual el usuario pueda encriptar y desencriptar esos datos".

1. Cree un archivo de combo ficticio y .gitignore.
2. Cree un archivo MAKE que pueda cifrar y descifrar el archivo de configuración
3. Almacene el archivo MAKE y el archivo de configuración cifrado en el repositorio
4. El archivo MAKE solicita una contraseña y cómo comunicarse con el autor para obtener la contraseña.
5. Al compilar el proyecto, si el archivo MAKE no se ha ejecutado, avise al usuario con console.error ("¡Falta el archivo de configuración [conf / settings.json]! ¿Olvidó ejecutar make decrypt_conf?");
6. Se describe una comprobación para garantizar que el archivo de configuración esté actualizado.

Creamos una herramienta llamada Config que maneja problemas de configuración como este. Lo que hará es crear (o importar) 1 archivo de configuración maestra. Luego cree un entorno llamado Local. En el entorno local, cree varias instancias, 1 instancia por usuario. Si necesita hacer un cambio que sea común en todos los ámbitos, como agregar una nueva entrada de configuración o modificar el nombre del módulo, simplemente realice el cambio y se aplicará en todos los ámbitos. Si desea hacer un cambio de instancia / usuario, haga que el valor de configuración sea una variable, luego cambie la variable. Este cambio solo se aplicará a su instancia / usuario. Todos estos están bajo control de versiones. Despliega los archivos de configuración mediante push o pull. La opción de extracción es similar a git pull, pero para esa instancia / usuario específico.

Config le brinda características adicionales como comparar configuraciones entre usuarios, búsqueda, etiquetado, validación y flujo de trabajo. Es SaaS, por lo que no es realmente para aquellos que aún no están listos para la nube, pero tenemos un plan local.