svn - tortoise - ¿Cómo manejas los archivos de configuración en el control de código fuente?

tortoise svn server (19)

+1 en el enfoque de la plantilla.

Pero como esta pregunta tiene la etiqueta Git, la alternativa distribuida viene a la mente, en la que las personalizaciones se guardan en una rama de prueba privada:

A---B---C---D--- <- mainline (public) / / B''------D''--- <- testing (private)

En este esquema, la línea principal contiene un archivo de configuración genérico, "plantilla" que requiere la cantidad mínima de ajustes para ser funcional.

Ahora, los desarrolladores / probadores pueden ajustar el archivo de configuración al contenido de su corazón, y solo confirmar estos cambios localmente en una rama de prueba privada (por ejemplo, B ''= B + personalizaciones). Cada vez que avanza la línea principal, sin esfuerzo se combinan en pruebas, lo que da como resultado fusiones de fusión como D ''(= D + versión combinada de personalizaciones de B).

Este esquema brilla realmente cuando se actualiza el archivo de configuración de la "plantilla": los cambios de ambos lados se fusionan, y es muy probable que generen conflictos (o fallas de prueba) si son incompatibles.

Supongamos que tiene una aplicación web típica y una configuración de archivo. Cada desarrollador que trabaje en el proyecto tendrá una versión para sus cajas de desarrollo, habrá una versión de desarrollador, producto y etapa. ¿Cómo lidiar con esto en el control de la fuente? ¿No compruebas en este archivo en absoluto, lo revisas con diferentes nombres o haces algo completamente sofisticado?

@Grant es correcto.

Estoy en un equipo con casi 100 desarrolladores más, y nuestros archivos de configuración no están registrados en el control de código fuente. Tenemos versiones de los archivos en el repositorio que se extraen con cada comprobación, pero no cambian.

Funcionó bastante bien para nosotros.

Actualmente tengo el archivo de configuración de "plantilla" con una extensión añadida, por ejemplo:

web.config.rename

Sin embargo, puedo ver un problema con este método si los cambios críticos han cambiado.

Durante mucho tiempo, he hecho exactamente lo que ha hecho bcwood. Guardo copias de web.dev.config, web.test.config, web.prod.config, etc. bajo control de fuente, y luego mi sistema de compilación / implementación los renombra automáticamente a medida que se implementa en varios entornos. Obtienes una cierta cantidad de redundancia entre los archivos (especialmente con todas las cosas de asp.net allí), pero en general funciona muy bien. También debe asegurarse de que todos en el equipo recuerden actualizar todos los archivos cuando realicen un cambio.

Por cierto, me gusta mantener ".config" al final como la extensión para que las asociaciones de archivos no se rompan.

En cuanto a las versiones de desarrollador locales del archivo de configuración, siempre hago mi mejor esfuerzo para alentar a las personas a utilizar la misma configuración local tanto como sea posible para que no haya necesidad de tener su propia versión. No siempre funciona para todos, en cuyo caso las personas generalmente lo reemplazan localmente según sea necesario y van desde allí. No es demasiado doloroso ni nada.

En nuestro proyecto tenemos la configuración almacenada en archivos con un prefijo, luego nuestro sistema de compilación obtiene la configuración adecuada en función del nombre de host del sistema actual. Esto nos funciona bien en un equipo relativamente pequeño, lo que nos permite aplicar cambios de configuración a los archivos de otras personas si / cuando agregamos un nuevo elemento de configuración. Obviamente, esto definitivamente no escala a los proyectos de código abierto con un número ilimitado de desarrolladores.

He usado la plantilla antes, es decir, web.dev.config, web.prod.config, etc., pero ahora prefiero la técnica ''anular archivo''. El archivo web.config contiene la mayoría de las configuraciones, pero un archivo externo contiene valores específicos del entorno, como conexiones db. Buena explicación en el blog de Paul Wilson .

Creo que esto reduce la cantidad de duplicación entre los archivos de configuración, lo que puede causar problemas al agregar nuevos valores / atributos.

La configuración es un código, y debes versionarlo. Basamos nuestros archivos de configuración en nombres de usuario; tanto en UNIX / Mac como en Windows, puede acceder al nombre de inicio de sesión del usuario, y siempre que estos sean exclusivos del proyecto, está bien. Incluso puede anular esto en el entorno, pero debe controlar todas las versiones.

Esto también le permite examinar las configuraciones de los demás, lo que puede ayudar a diagnosticar problemas de compilación y plataforma.

La solución que utilizamos es tener solo el archivo de configuración único (web.config / app.config), pero agregamos una sección especial al archivo que contiene configuraciones para todos los entornos.

Hay una sección LOCAL, DEV, QA, PRODUCTION que contiene las claves de configuración relevantes para ese entorno en nuestros archivos de configuración.

Lo que hace que todo esto funcione es un ensamblado denominado xxx.Environment al que se hace referencia en todas nuestras aplicaciones (formularios y formularios web) que le indica a la aplicación en qué entorno está funcionando.

El ensamblaje xxx.Environment lee una sola línea de información del machine.config de la máquina determinada que le dice que está en DEV, QA, etc. Esta entrada está presente en todas nuestras estaciones de trabajo y servidores.

Espero que esto ayude.

La versión de aplicación / web.config sin comprimir debe ser lo suficientemente genérica como para funcionar en todas las máquinas de desarrollo y mantenerse actualizada con los cambios de configuración nuevos, etc. Si necesita un conjunto específico de configuraciones para dev. / prueba / configuración de producción, compruebe en archivos separados con esas configuraciones, como declaró GateKiller, con algún tipo de convención de nombres, aunque normalmente utilizo "web.prod.config" para no cambiar la extensión del archivo.

La versión lo controlo, pero nunca lo empujo a los otros servidores. Si el servidor de producción requiere un cambio, hago ese cambio directamente en el archivo de configuración.

Puede que no sea lindo, pero funciona bien.

Lo que hice en el pasado es tener un archivo de configuración predeterminado que está registrado en el control de origen. Luego, cada desarrollador tiene su propio archivo de configuración de anulación que se excluye del control de origen. La aplicación primero carga el valor predeterminado, y luego, si está presente el archivo de reemplazo, lo carga y utiliza cualquier configuración de la anulación con preferencia al archivo predeterminado.

En general, cuanto más pequeño sea el archivo de anulación, mejor, pero siempre puede contener más configuraciones para un desarrollador con un entorno muy no estándar.

Me enfrenté al mismo problema y encontré una solución para eso. Primero agregué todos los archivos al repositorio central (también los desarrolladores).

Entonces, si un desarrollador obtiene los archivos del repositorio, la configuración del desarrollador también está allí. Al cambiar a este archivo, Git no debería estar al tanto de estos cambios. De esta forma, los cambios no pueden enviarse o enviarse al repositorio, sino que permanecen localmente.

Lo resolví usando el comando git: update-index --assume-unchanged . Hice un archivo bat que se ejecuta en la preconstrucción de los proyectos que contienen un archivo cuyos cambios Git debe ignorar. Aquí está el código que puse en el archivo bat:

IF NOT EXIST %2%/.git GOTO NOGIT set fileName=%1 set fileName=%fileName:/=/% for /f "useback tokens=*" %%a in (''%fileName%'') do set fileName=%%~a set "gitUpdate=git update-index --assume-unchanged" set parameter= "%gitUpdate% %fileName%" echo %parameter% as parameter for git "C:/Program Files (x86)/Git/bin/sh.exe" --login -i -c %parameter% echo Make FIleBehaveLikeUnchangedForGit Done. GOTO END :NOGIT echo no git here. echo %2% :END

En mi precompilación hice una llamada al archivo bat, por ejemplo:

call "$(ProjectDir)/../../MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"

Encontré en SO un archivo bat que copia el archivo de configuración correcto en web.config / app.config. También llamo a este archivo bat en prebuild. El código para este archivo bat es:

@echo off echo Comparing two files: %1 with %2 if not exist %1 goto File1NotFound if not exist %2 goto File2NotFound fc %1 %2 if %ERRORLEVEL%==0 GOTO NoCopy echo Files are not the same. Copying %1 over %2 copy %1 %2 /y & goto END :NoCopy echo Files are the same. Did nothing goto END :File1NotFound echo %1 not found. goto END :File2NotFound copy %1 %2 /y goto END :END echo Done.

En mi precompilación hice una llamada al archivo bat, por ejemplo:

call "$(ProjectDir)/../../copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config

Mi equipo guarda versiones separadas de los archivos de configuración para cada entorno (web.config.dev, web.config.test, web.config.prod). Nuestros scripts de implementación copian la versión correcta, renombrándola a web.config. De esta forma, tenemos un control de versión completo en los archivos de configuración para cada entorno, podemos realizar fácilmente un diff, etc.

No creo que haya una única solución que funcione para todos los casos, ya que puede depender de la sensibilidad de los datos en los archivos de configuración, o del lenguaje de programación que está usando, y muchos otros factores. Pero creo que es importante mantener los archivos de configuración para todos los entornos bajo el control de código fuente, para que siempre pueda saber cuándo fue cambiado y por quién y, lo que es más importante, podrá recuperarlo si las cosas van mal. Y lo harán.

Así que aquí es cómo lo hago. Esto es para proyectos nodejs por lo general, pero creo que funciona para otros marcos e idiomas también.

Lo que hago es crear un directorio configs en la raíz del proyecto, y bajo ese directorio mantener múltiples archivos para todos los entornos (y algunas veces también archivos separados para el entorno de cada desarrollador) que se controlan en control de fuente. Y existe el archivo real en el que el código usa la config nombre en la raíz del proyecto. Este es el único archivo que no se rastrea. Entonces parece que esto

Cuando alguien revisa el proyecto, copia el archivo de configuración que quiere usar en el archivo de config seguimiento y puede editarlo como lo desee, pero también es responsable de copiar estos cambios antes de comprometerse con los demás archivos de entorno según sea necesario.

Y en los servidores, el archivo sin seguimiento puede ser simplemente una copia (o referencia) del archivo rastreado correspondiente a ese entorno. En JS, simplemente puede tener 1 línea para requerir ese archivo.

Este flujo puede ser un poco complicado al principio, pero tiene grandes ventajas: 1. Nunca tiene que preocuparse de que un archivo de configuración sea eliminado o modificado en el servidor sin tener una copia de seguridad 2. Lo mismo si un desarrollador tiene alguna configuración personalizada en su la máquina y su máquina dejan de funcionar por algún motivo. 3. Antes de realizar una implementación, puede diferenciar los archivos de configuración para el development y la staging en staging por ejemplo, y ver si falta algo o está roto.

No versione ese archivo. Versión una plantilla o algo.

Siempre he mantenido todas las versiones de los archivos de configuración en control de fuente, en la misma carpeta que el archivo web.config.

Por ejemplo

web.config web.qa.config web.staging.config web.production.config

Prefiero esta convención de nombres (a diferencia de web.config.production o production.web.config) porque

Mantiene los archivos juntos cuando ordena por nombre de archivo
Mantiene los archivos juntos cuando ordena por extensión de archivo
Si el archivo se transfiere accidentalmente a producción, no podrá ver los contenidos en http porque IIS evitará que se publiquen los archivos * .config.

El archivo de configuración predeterminado debe configurarse de manera que pueda ejecutar la aplicación localmente en su propia máquina.

Lo más importante es que estos archivos deben ser casi 100% idénticos en todos los aspectos, incluso en el formateo. No debe usar pestañas en una versión y espacios en otra para sangrar. Debería poder ejecutar una herramienta diff contra los archivos para ver exactamente qué es diferente entre ellos. Prefiero usar WinMerge para diferir los archivos.

Cuando su proceso de creación crea los binarios, debe existir una tarea que sobrescriba el archivo web.config con el archivo de configuración apropiado para ese entorno. Si los archivos están comprimidos, los archivos no relevantes deben eliminarse de esa compilación.

Solo mantenemos el archivo de configuración de producción registrado. Es responsabilidad del desarrollador cambiar el archivo cuando lo sacan de la fuente segura para la puesta en escena o el desarrollo. Esto nos ha quemado en el pasado, así que no lo sugeriría.

Tenemos dos problemas aquí.

En primer lugar, debemos controlar el archivo de configuración que se envía con el software.
Es muy fácil para un desarrollador registrar un cambio no deseado en el archivo de configuración maestra, si están utilizando el mismo archivo en el entorno de devolución.
Por otro lado, si tiene un archivo de configuración separado que el instalador incluye, es muy fácil olvidarse de agregarle una nueva configuración, o dejar que los comentarios en él se desincronicen con los comentarios en la devolución. configurando el archivo.
Luego tenemos el problema de que los desarrolladores tienen que mantener actualizada la copia del archivo de configuración a medida que otros desarrolladores agreguen nuevas configuraciones. Sin embargo, algunas configuraciones, como las cadenas de conexión de la base de datos, son diferentes para cada desarrollador.
Hay un tercer problema que las preguntas / respuestas no cubren. ¿Cómo se fusiona con los cambios que un cliente ha realizado en su archivo de configuración cuando instala una nueva versión de su software?

Todavía tengo que ver una buena solución que funcione bien en todos los casos, sin embargo, he visto algunas soluciones parciales (que se pueden combinar en diferentes combinaciones según sea necesario) que reducen mucho el problema.

Primero, reduzca la cantidad de elementos de configuración que tiene en su archivo de configuración principal.
Si no necesita dejar que sus clientes cambien sus asignaciones, use Fluiber NHibernate (o de lo contrario) para mover la configuración al código.
Del mismo modo para la configuración de inyección de dependencia.
Divida el archivo de configuración cuando sea posible, por ejemplo, use un archivo separado para configurar lo que Log4Net registra.
No repita elementos entre muchos archivos de configuración; por ejemplo, si tiene 4 aplicaciones web que están todas instaladas en la misma máquina, tenga un archivo de configuración general al que apunta el archivo web.config en cada aplicación.
(Utilice una ruta relativa de forma predeterminada, por lo que es raro tener que cambiar el archivo web.config)
Procese el archivo de configuración de desarrollo para obtener el archivo de configuración de envío.
Esto se puede hacer teniendo valores predeterminados en los comentarios Xml que luego se configuran en el archivo de configuración cuando se realiza una compilación. O tener secciones que se eliminan como parte del proceso de creación del instalador.
En lugar de tener solo una cadena de conexión de base de datos, tenga una por cada desarrollador.
Por ejemplo, primero busque "database_ianr" (donde ianr es mi nombre de usuario o máquina) en el archivo de configuración en tiempo de ejecución, si no se encuentra, busque "base de datos"
Tener un segundo nivel "eg -oracle or -sqlserver" hace que los desarrolladores puedan acceder más rápidamente a ambos sistemas de bases de datos.
Por supuesto, esto también puede hacerse para cualquier otro valor de configuración.
Entonces, todos los valores que terminan en "_userName" se pueden rayar antes de enviar el archivo de configuración.

Sin embargo, al final, ¿qué es usted? Es un "propietario del archivo de configuración" que se responsabiliza de la administración de los archivos de configuración como se indicó anteriormente o de otro modo. Él / Ella también debe hacer una diferencia en el archivo de configuración de los revestimientos del cliente antes de cada envío.

No se puede eliminar la necesidad de una persona que se preocupe por este problema corto.

Usamos un archivo de configuración de plantilla que está registrado en el control de versiones y luego un paso en nuestra compilación automatizada para reemplazar las entradas específicas en el archivo de plantilla con configuraciones específicas del entorno. Las configuraciones específicas del entorno se almacenan en un archivo XML separado que también está bajo control de versión.

Estamos utilizando MSBuild en nuestra versión automatizada, por lo que usamos la tarea XmlUpdate de MSBuild Community Tasks para actualizar los valores.