¿Cómo se manejan los archivos de configuración en el control de código fuente?

No verifiques ese archivo. Versión una plantilla o algo así.

Configuration es code, y usted debe 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 mientras estos sean únicos para el proyecto, está bien. Incluso puede anular esto en el entorno, pero debería controlar todo.

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

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

Actualmente tengo el archivo de configuración "template" 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.

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

Hay secciones LOCAL, DEV, QA, PRODUCTION cada una 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 llamado xxx. Environment al que se hace referencia en todas nuestras aplicaciones (winforms y webforms) que indica a la aplicación en qué entorno está operando.

El ensamblaje xxx.Environment lee una sola línea de información de la máquina .config de la máquina dada 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.

+1 en el método de plantilla.

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

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

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

Ahora, los desarrolladores / probadores pueden ajustar el archivo de configuración a su corazón contenido, y solo confirme estos cambios localmente en uno privado prueba rama (por ejemplo, B ' = B + personalizaciones). Cada vez línea principal avances, sin esfuerzo lo fusionan en pruebas, lo que resulta en merge commits como D' (=D + versión combinada de las personalizaciones de B).

Este esquema realmente brilla cuando se actualiza el archivo de configuración" template": los cambios de ambos lados se fusionan, y es muy probable que dar lugar a conflictos (o fallos de prueba) si son incompatibles!

He usado la plantilla antes, es decir, web.dev.config, web.prod.config, etc, pero ahora prefieren la técnica' override file'. Web.el archivo de configuración contiene la mayoría de los ajustes, pero un archivo externo contiene valores específicos del entorno, como conexiones de base de datos. Buena explicación en El blog de Paul Wilson .

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

@Grant tiene razón.

Estoy en un equipo con cerca de otros 100 desarrolladores, 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.

Ha funcionado bastante bien para nosotros.

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

Por ejemplo

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

Prefiero esta convención de nomenclatura (a diferencia de web.config.producción o producción.web.config) porque

• Mantiene los archivos juntos cuando ordena por nombre de archivo
• Mantiene los archivos juntos cuando se ordena por extensión de archivo
• Si el archivo se envía accidentalmente a producción, no podrá ver el contenido sobre http porque IIS evitará*.archivos de configuración de ser servidos

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, estos archivos deben ser casi 100% idénticos en todos los aspectos, incluso el formato. No debes usar pestañas en una versión y espacios en otra para sangrar. Usted debe ser capaz de ejecutar una herramienta de diferencias contra los archivos para ver exactamente lo que es diferente entre ellos. Me prefiere usar WinMerge para diferenciar los archivos.

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

Yo lo controlo, pero nunca lo envio a los otros servidores. Si el servidor de producción requiere un cambio, realizo ese cambio directamente en el archivo de configuración.

Puede que no sea bonito, pero funciona bien.

La versión estándar de app/web.la configuración debe ser lo suficientemente genérica como para funcionar en todas las máquinas de desarrollo, y mantenerse al día con cualquier nuevo cambio de configuración, etc. Si necesita un conjunto específico de configuraciones para la configuración de desarrollo/prueba/producción, verifique archivos separados con esas configuraciones, como dijo GateKiller, con algún tipo de convención de nomenclatura, aunque generalmente voy con "web.prod.config", para no cambiar la extensión del archivo.

Utilizamos un archivo de configuración de plantilla que se comprueba en el control de versiones y luego un paso en nuestra compilación automatizada para reemplazar entradas específicas en el archivo de plantilla con configuraciones específicas del entorno. La configuración específica del entorno se almacena en un archivo XML separado que también está bajo control de versiones.

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

Durante mucho tiempo, he hecho exactamente lo que Bcwood ha hecho. Guardo copias de web.dev.config, web.prueba.config, web.prod.configuración, etc. bajo control de código fuente, y luego mi sistema de compilación / implementación los cambia de nombre automáticamente a medida que se despliega en varios entornos. Se obtiene una cierta cantidad de redundancia entre los archivos (especialmente con todos los asp.net cosas allí), pero generalmente funciona muy bien. También debe asegurarse de que todos en el equipo recuerden actualizar todos el archivos cuando hacen un cambio.

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

En cuanto a las versiones de desarrolladores locales del archivo de configuración, siempre hago todo lo posible para animar a la gente a usar 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 o algo así.

En nuestro proyecto tenemos la configuración almacenada en archivos con un prefijo, luego nuestro sistema de compilación extrae la configuración apropiada basada en el nombre de host del sistema actual. Esto funciona bien para nosotros 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 se escala a proyectos de código abierto con un número ilimitado de desarrolladores.

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

Tenemos dos problemas aquí.

• En primer lugar tenemos que controlar el archivo de configuración que se envía con el software.

  Es todo dos fácil para un desarrollador para comprobar en un no deseado para cambiar al archivo de configuración maestro, 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 incluye el instalador, es muy fácil olvidarse de agregar un nuevo ajuste a él, o dejar que el los comentarios en él no se sincronizan con los comentarios en el archivo de configuración de devolución.

• Entonces tenemos el problema de que los desarrolladores tienen que mantener allí una copia del archivo de configuración actualizada a medida que otros desarrolladores agregan nuevos ajustes de configuración. Sin embargo, algunas configuraciones como las cadenas de conexión a la base de datos son diferentes para cada desarrollador.

• Hay un 3er problema que la pregunta / respuestas no cubren. ¿Cómo se fusionan los cambios que un cliente ha realizado en su archivo de configuración al instalar una nueva versión de su software?

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

• Primero reduzca el número de elementos de configuración que tiene en su archivo de configuración principal.

  Si usted no tiene la necesidad de dejar que su los clientes cambian sus asignaciones, usan Fluent NHibernate (o de otro modo) para mover la configuración al código.

  Lo mismo para la configuración de inyección de depencia.

• Divida el archivo de configuración cuando sea posible, por ejemplo, use un archivo separado para configurar qué registros de Log4Net.

• No repita elementos entre muchos archivos de configuración, por ejemplo, si tiene 4 aplicaciones web que están instaladas en la misma máquina, tiene un archivo de configuración general que la web.config archivo en cada aplicación apunta a.

  (Use una ruta relativa por defecto, por lo que es raro tener que cambiar la web.archivo de configuración)

• Procesa el archivo de configuración de desarrollo para obtener el archivo de configuración de envío.

  Se podría hacer por tener valores predeterminados en los comentarios Xml que luego se establecen 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 su lugar de solo tener una cadena de conexión de base de datos, tener una por desarrolladores.

  Por ejemplo, primero busque " database_ianr "(donde ianr es mi nombre de usuario o nombre de máquina) en el archivo de configuración en tiempo de ejecución, si no se encuentra, entonces busque" database "

  Tienen un 2do nivel "por ejemplo-oracle o-sqlserver" que sea más rápido para los desarrolladores llegar a ambos sistemas de base de datos.

  Por supuesto, esto también se puede hacer para cualquier otro valor de configuración.

  Entonces todos los valores que terminan en "_userName" puede ser rayado antes de enviar el archivo de configuración.

Sin embargo, al final lo que eres es un "propietario del archivo de configuración" que toma la responsabilidad de la gestión de la archivo(s) de configuración como arriba o de lo contrario. Él / Ella también debe hacer un diff en los revestimientos del cliente archivo de configuración antes de cada embarque.

No se puede eliminar la necesidad de una persona cariñosa algunos de este corto de problema.

No creo que haya una sola 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 el lenguaje de programación que esté utilizando, y muchos otros factores. Pero creo que es importante mantener los archivos de configuración para todos los entornos bajo control de código fuente, para que siempre pueda saber cuándo se cambió y por quién, y lo más importante, ser capaz de recuperarlo si las cosas salen mal. Y lo harán.

Así que así es como lo hago. Esto es para proyectos nodejs por lo general, pero creo que funciona para otros marcos y lenguajes también.

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

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

Cuando alguien comprueba el proyecto, copia el archivo de configuración que desea usar en el archivo config sin seguimiento y es libre de editarlo como desee, pero también es responsable de copiar estos cambios antes de comprometerse con los otros archivos de entorno según sea necesario.

Y en los servidores, el archivo no rastreado 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 tendrá que preocuparse de que un archivo de configuración se elimine o modifique en el servidor sin tener una copia de seguridad 2. Lo mismo si un desarrollador tiene alguna configuración personalizada en su máquina y su máquina deja de funcionar por cualquier motivo 3. Antes de cualquier implementación, puede comparar los archivos de configuración para development y staging por ejemplo y ver si falta algo o está roto.

Me enfrenté a ese mismo problema y encontré una solución para él. Primero agregué todos los archivos al repositorio central (también los del desarrollador).

Entonces, si un desarrollador obtiene los archivos del repositorio, la configuración del desarrollador también está allí. Cuando se realiza un cambio en este archivo, Git no debe ser consciente de estos cambios. De esta manera los cambios no pueden ser enviados/confirmados al repositorio, sino que permanecen localmente.

Resolví esto usando el comando git: update-index --assume-unchanged. Hice un archivo bat que se ejecuta en la precompilación de los proyectos que contienen un archivo cuyos cambios deben ser ignorados por Git. 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 prebuild haría 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 a la web.config / app.config. También llamo a este archivo bat en el 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 prebuild haría una llamada al archivo bat, por ejemplo:

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