Archivos semi editables (por ejemplo, archivos de configuración) y control de versiones: ¿prácticas recomendadas?

Question

Así que, maté la compilación hoy al registrar un archivo de configuración. Sabe dónde está el servidor (piense en el servidor SQL o similar), y he estado trabajando contra el servidor que se ejecuta en mi caja. Normalmente, o mejor dicho, bajo otras circunstancias, nos encontraríamos con el servidor central. La construcción diaria, por supuesto, no encontró 'mi' servidor, de ahí la rotura. Por otra parte, la edición del archivo de configuración para apuntar al servidor "normal" antes del checkin, y su edición de nuevo después de la entrada es tendido.

He estado tentado de que VC simplemente ignore el archivo de configuración, para que no se active accidentalmente. Por otro lado, el repositorio debe contener una versión limpia y utilizable del archivo. No puedo ignorarlo y hacer que se lo revisen al mismo tiempo, ¿o sí?

Así que, lo que estoy buscando sería una manera de tener un archivo que, por ejemplo, lo compruebe, pero nunca lo haga. Al menos en el caso más común: ¿debería cambiar el archivo de configuración de manera significativa? El procedimiento para obtener la nueva versión en el repositorio sería factible.

Si ustedes han tenido este problema antes, me interesarían las soluciones que haya encontrado. Mientras no rompan la compilación, eso es;)

Answer 1

Lo que puede hacer es tener un archivo de configuración predeterminado que no se modifique, a menos que se agregue una nueva configuración. Luego tiene un archivo diferente que anula las configuraciones del archivo predeterminado.

config.Default.xml 
config.User.xml 

Solo config.Default.xml es fuente controlada. config.User.xml contiene solo las configuraciones que son diferentes para usted. Entonces, digamos que está probando en un servidor SQL local, coloca solo la cadena de conexión allí y anulará la cadena de conexión config.Default.

Eche un vistazo a .Net Framwork Application Configuration, que hace la mayoría (si no todos) del trabajo para usted.

Answer 2

Un método que he usado es tener dos versiones del archivo de configuración, y hacer que la secuencia de comandos del instalador obtenga la versión correcta.

• settings.xml
• settings.xml de liberación

Ambos archivos contienen las mismas claves, pero uno contiene valores 'dev' y el otro contiene los valores que esperan desplegar y ser editado en el campo.

Answer 3

Si trabajo, tenemos archivos de configuración separados para despliegues. Por lo tanto, los archivos de configuración en nuestras soluciones son las versiones de desarrollo y las personas pueden cambiarlas según su corazón. Estos archivos de configuración nunca se implementan en ningún lado.

Los archivos de configuración que se implementan se almacenan en una ubicación separada en nuestro proveedor de control de código fuente. Si alguien necesita hacer un cambio de configuración que se implementará, deberá modificar esta versión.

Answer 4

Almacenamos este tipo de archivos en nuestro sistema de control de origen y tenemos diferentes carpetas para el entorno en el que estamos creando.

Así tenemos:

Dev 
Test 
Live 

Hay subcarpetas de estos archivos específicos para otro entorno.

Answer 5

Tenemos

• *. (Config | xml)
• *. (Config | xml) .cert
• *. (Config | xml) .PRODUCCIÓN

Hudson borra el archivo inicial y despliega el archivo correcto para el entorno correcto (actualmente solo cert).

Esto permite a los desarrolladores documentar y desarrollar archivos de configuración de nivel de producción, certificado y desarrollo de forma independiente y tenerlos versionados por separado en SVN.

Answer 6

Para cada archivo de configuración x, cree un archivo que haga el check-in llamado x.dist, que es la configuración distribuida predeterminada. Después de que los desarrolladores revisen, tenga un script que copie cada archivo x.dist en x, donde pueden personalizar x tanto como sea necesario. Este script se puede volver a ejecutar para actualizar los archivos después de cambios importantes, o los desarrolladores pueden fusionarse manualmente en sus cambios.

Para la implementación, puede verificar sus archivos de implementación en vivo y hacer que sus scripts de inicio se refieran a ellos explícitamente (por ejemplo, --config x.production).

Este enfoque se usa, por ejemplo, en cómo se distribuye Wordpress (debe copiar una plantilla de archivo wp-config.php) o en proyectos de desarrollo que usan autoconf (donde se configura el configure.ac pero el archivo de configuración debe ser generado por cada desarrollador, se crea un archivo de configuración especial para su distribución en archivos comprimidos en el momento del lanzamiento).

Answer 7

creo que la respuesta aceptada es buena, pero dependiendo de sus necesidades, que pueden tener limitaciones.

Usamos el siguiente enfoque. Tenga en cuenta que somos .NET shop utilizando VS y hacemos uso de MSBuild (tareas integradas, comunitarias y personalizadas).

• App.config es ignorado por el control de versiones pero incluirse en el proyecto.
• App.default.config está bajo control de versiones y también se incluye en el proyecto. En lugar de cosas difíciles de codificar que pueden cambiar, p. cadenas de conexión db, usamos tokens en su lugar.

tarea BeforeBuild de un proyecto busca existencia de App.config y si no se encuentra copias App.default.config a App.config. Además, el servidor de compilación siempre elimina App.config si existe una acumulación de CI (config asegura limpia). También usamos la tarea MSBuild Community FileUpdate para reemplazar los tokens con los valores apropiados en función de lo que sea que esté construyendo el proyecto.

Por ejemplo, un desarrollador puede obtención nueva configuración de las cadenas de conexión db para una base de datos local, una nightly build puede configurar para la db noche, etc.

Answer 8

La respuesta aceptada es buena.Sin embargo, es posible hacer lo que usted quería (hace 4 años), y mantener solo un archivo de configuración único que verifica y nunca ingresa - si su sistema de control de versiones tiene el concepto de listas de cambios. He hecho esto en Perforce:

Revise el archivo de configuración y guárdelo en su propia lista de cambios. Cuando te comprometas, compromete solo a las otras listas de cambios; esto es fácil de recordar si nombra su lista de cambios de archivo de configuración algo así como "NO COMPROMETER".

Una ventaja de este sistema es que si alguien más cambia la versión de producción del archivo de configuración, es decir, la que existe en el servidor y en la que todos mantienen una versión local modificada, se le notificará de posibles conflictos cuando obtiene el archivo de configuración del servidor. Con una solución como la que se sugiere en la respuesta aceptada, es posible que continúe sobrescribiendo silenciosamente la nueva configuración de producción con su configuración local, lo que podría romper su compilación local o hacer que rompa la compilación la próxima vez que se comprometa.