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

StackOverflow https://stackoverflow.com/questions/6009

  •  08-06-2019
  •  | 
  •  

Pregunta

Digamos que usted tiene una típica web de la aplicación y con un archivo de configuración.lo que sea.Cada desarrollador que trabaja en el proyecto tendrá una versión para su dev cajas, habrá un dev, prod y la etapa de versiones.¿Cómo lidiar con este en control de código fuente?No se busque en este archivo, compruebe con diferentes nombres o hacer algo de fantasía en total?

¿Fue útil?

Solución

Lo que he hecho en el pasado es tener un fichero de configuración por defecto que se comprueba en el control de código fuente.Luego, cada desarrollador tiene su propia reemplazar archivo de configuración que se excluye de control de código fuente.La primera aplicación que se carga el valor predeterminado y, a continuación, si el archivo override está presente, cargas y utiliza la configuración de la invalidación en la preferencia para el archivo predeterminado.

En general, el más pequeño es el archivo override la mejor, pero siempre pueden contener más información de la configuración para un desarrollador con una muy no-estándar de medio ambiente.

Otros consejos

No la versión de ese archivo.Versión de una plantilla o algo.

Configuración es código, y usted debería versión.Basamos nuestros archivos de configuración de nombres de usuario;en UNIX/Mac y Windows, puede acceder a la conexión del usuario, nombre, siempre y cuando éstos sean únicos en el proyecto, están bien.Usted puede incluso reemplazar este en el medio ambiente, pero debe control de versiones de todo.

Esto también permite que usted examine demás configuraciones, que pueden ayudar a diagnosticar construir y plataforma de problemas.

Mi equipo mantiene separadas las versiones de los archivos de configuración para cada entorno (de la web.config.dev, web.config.la prueba, en la web.config.prod).Nuestra implementación de secuencias de comandos de copia de la versión correcta, cambiando el nombre a la web.config.De esta manera, tenemos pleno control de versiones de los archivos de configuración para cada entorno, puede realizar fácilmente un diff, etc.

Actualmente tengo la "plantilla" config archivo con una extensión, 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 uso es tener sólo el único archivo de configuración (web.config/app.config), pero añadimos una sección especial para el archivo que contiene la configuración para todos los entornos.

Hay un LOCAL, DEV, CONTROL DE CALIDAD, PRODUCCIÓN las secciones de cada uno de los que contiene la configuración de claves relevantes para el medio ambiente en nuestro fichero de configuración(s).

Lo que hacen que todo esto funcione es un ensamblado con nombre xxx.Medio ambiente la que se hace referencia en todas nuestras aplicaciones (winforms y webforms) que indica la aplicación del entorno que se está operando.

El xxx.Medio ambiente de la asamblea lee una sola línea de información de la de la máquina.config de la máquina que dice que está en la DEV, control de calidad, etc.Esta entrada está presente en todas nuestras estaciones de trabajo y servidores.

Espero que esto ayude.

+1 en la plantilla de enfoque.

Pero esta cuestión ya tiene la etiqueta de Git, distribuido alternativa viene a la mente, en que las personalizaciones se mantiene en una evaluación privada rama:

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

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

Ahora, los desarrolladores y probadores pueden modificar el archivo de configuración para su corazón contenido, y sólo cometen estos cambios localmente en uno privado rama "testing" (por ejemplo,B' = B + personalizaciones).Cada vez que la línea principal avances, que sin esfuerzo en combinar en la prueba, que se traduce en mezcla comete tales como D' (= D + fusionado versión de B personalizaciones).

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

He utilizado la plantilla antes, es decir,web.dev.configuración web.prod.config, etc, pero ahora prefiero el 'archivo override' técnica.La web.archivo de configuración contiene la mayoría de las opciones de configuración, pero un archivo externo que contiene el medio ambiente de los valores específicos tales como db conexiones.Buena explicación sobre Paul Wilson blog.

Creo que esto reduce la cantidad a la duplicación entre los archivos de configuración que puede causar dolor cuando se añaden nuevos atributos de valores.

Yo siempre he tenido 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

Yo prefiero esta convención de nomenclatura (en contraposición a la web.config.de producción o de producción.web.config) porque

  • Mantiene los archivos junto al ordenar por nombre de archivo
  • Mantiene los archivos junto al ordenar la extensión del archivo
  • Si el archivo accidentalmente se inserta en la producción, usted no será capaz de ver el contenido a través de http, porque IIS evitará *.los archivos de configuración de los servicios

El fichero de configuración por defecto debe ser configurado de tal manera que usted puede ejecutar la aplicación de forma local en su propia máquina.

Lo que es más importante, estos archivos deben ser de casi el 100% idénticos en todos los aspectos, incluso el formato.Usted no debe usar pestañas en una versión de espacios y en otro para la sangría.Usted debe ser capaz de ejecutar una herramienta de comparación contra los archivos para ver exactamente lo que es diferente entre ellos.Yo prefiero usar WinMerge para la distinción de los archivos.

Cuando el proceso de generación crea los archivos binarios, no debería ser una tarea que sobrescribe la web.config con el archivo de configuración apropiada para el medio ambiente.Si los archivos están comprimidos de arriba, a continuación, la no relevante archivos deben ser eliminados de que construir.

@Subvención a la derecha.

Estoy en un equipo con cerca de 100 otros desarrolladores, y nuestros archivos de configuración no se comprueban en el control de código fuente.Tenemos versiones de los archivos en el repositorio que se tira con cada salida pero no cambio.

Ha funcionado bastante bien para nosotros.

Yo de control de versiones, pero nunca empujar a los otros servidores.Si el servidor de producción requiere un cambio, puedo hacer que el cambio directamente en el archivo de configuración.

Puede que no sea bonito, pero funciona muy bien.

El check-in, vestidos de vainilla versión de la app/web.config debe ser lo suficientemente genérico para trabajar en todos los equipos de desarrollador, y se mantiene hasta la fecha con todos los nuevos cambios de configuración, etc.Si usted requiere un conjunto específico de opciones de configuración para dev/prueba/producción de la configuración, consulte en archivos separados, con los valores de configuración, como GateKiller dijo, con una especie de convención de nomenclatura, aunque yo suelo ir con la web".prod.config", como no cambie la extensión del archivo.

Utilizamos una plantilla de archivo de configuración que está activado en la versión de control y, a continuación, un paso en nuestra generación automatizada para reemplazar entradas específicas en el archivo de plantilla con el medio ambiente de los ajustes específicos.El entorno específico de la configuración se almacena en un archivo XML independiente que también está bajo el control de versiones.

Estamos usando MSBuild en nuestra generación automática, así que usar el XmlUpdate tarea de MSBuild De La Comunidad Tareas para actualizar los valores.

Durante mucho tiempo, he hecho exactamente lo que bcwood ha hecho.Yo guarde copias de la web.dev.configuración web.prueba.configuración web.prod.config, etc.bajo control de código fuente y, a continuación, mis crear/implementar el sistema cambia automáticamente a medida que se despliega en diversos entornos.Usted consigue una cierta cantidad de redundancia entre los archivos (sobre todo con todo el asp.net cosas), pero en general funciona muy bien.Usted también tiene que asegurarse de que todos en el equipo, recuerda actualizar todos los archivos cuando se realice un cambio.

Por cierto, me gusta mantener ".config" en el extremo de la extensión, por lo que las asociaciones de archivo no se rompen.

Tan lejos como desarrollador local de versiones del archivo de configuración, siempre me a intentar mi mejor esfuerzo para animar a la gente a utilizar la misma configuración local tanto como sea posible, de modo que no hay necesidad de tener su propia versión.Esto no siempre funciona para todos, en cuyo caso la gente suele reemplazar sólo a nivel local como necesario e ir de allí.No es demasiado doloroso o nada.

En nuestro proyecto hemos de configuración se almacenan en archivos con un prefijo y, a continuación, nuestro sistema de construcción tira en la configuración adecuada se basa en el actual sistema del nombre de host.Esto funciona bien para nosotros en un equipo relativamente pequeño, lo que nos permite aplicar los cambios de configuración a la gente de otros archivos si/cuando añadimos un nuevo elemento de configuración.Obviamente, esto definitivamente no escala a proyectos de código abierto con un número ilimitado de los desarrolladores.

Tenemos dos problemas aquí.

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

    Todo es dos fácil para un desarrollador de verificación en un no deseado para cambiar a la maestra archivo de configuración, si está usando el mismo archivo en el entorno de desarrollo.

    Por otro lado, si usted tiene un archivo de configuración independiente que se incluye en el instalador, es muy fácil olvidarse de agregar una nueva configuración, o para dejar comentarios en salir de la sincronización con los comentarios en el desarrollo de la configuración de archivo.

  • Luego tenemos el problema de que los desarrolladores tienen que mantener allí copia del archivo de configuración para arriba-a-fecha como otros desarrolladores añadir nuevas opciones de configuración.Sin embargo, algunos ajustes de la base de datos como cadenas de conexión son diferentes para cada desarrollador.

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

Todavía tengo que ver un buen soluciones que funciona bien en todos los casos, sin embargo He visto algunos soluciones parciales (que pueden ser combinados en diferentes combinaciones como sea necesario) que reduce el problema de muchos.

  • En primer lugar, reducir el número de elementos de configuración que tiene en su archivo de configuración principal.

    Si usted no tiene una necesidad de dejar a sus clientes cambiar su asignación, uso Fluido de NHibernate (o no) para mover la configuración en el código.

    De la misma manera por depency inyección de instalación.

  • Dividir el archivo de configuración cuando sea posible, por ejemplo,utilización de un archivo para configurar lo que Log4Net registros.

  • No repetir los elementos entre un montón de archivos de configuración, p. ej.si tiene 4 aplicaciones web que están instalados en la misma máquina, tiene un archivo de configuración de la web.archivo de configuración en cada uno de los puntos de aplicación para.

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

  • Proceso de la elaboración del archivo de configuración para obtener la configuración de envío de archivos.

    La que se podría hacer por tener valores por defecto en los comentarios Xml que luego se establezca en el archivo de configuración cuando una compilación se lleva a cabo.O tener secciones que se eliminan como parte del proceso de crear el instalador.

  • En lugar de sólo tener una base de datos de cadenas de conexión, tienen uno por los desarrolladores.

    E. g, busque primero "database_ianr" (donde ianr es mi nombre de usuario o nombre de la máquina) en el archivo de configuración en tiempo de ejecución, si no se encuentra, a continuación, busque "base de datos"

    Tienen un "nivel 2", p. ej.-oracle o -sqlserver" que sea más rápido para los desarrolladores para llegar a la base de datos de ambos sistemas.

    Por supuesto, también puede ser hecho por cualquier otro valor de configuración.

    A continuación, todos los valores que terminan en "_userName" puede ser rayado a cabo antes de enviar el archivo de configuración.

Sin embargo, al final lo que es usted es un el "titular del archivo de configuración" que toma el responsable de la gestión de la archivo de configuración de la(s) como el anterior o de lo contrario.Él/Ella también debe hacer un diff en el cliente revestimientos archivo de configuración antes de cada el envío.

Usted no puede eliminar la necesidad de una persona que cuida un poco este corto de problema.

Creo que no hay 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 el lenguaje de programación que se está utilizando, y tantos otros factores.Pero creo que es importante mantener los archivos de configuración para todos los entornos bajo control de código fuente, por lo que siempre se puede saber cuando fue cambiado y por quién, y lo que es más importante, ser capaz de recuperar si las cosas van mal.Y lo harán.

Así que aquí está cómo lo hago.Esto es para nodejs proyectos por lo general, pero creo que funciona para otros frameworks y lenguajes también.

Yo lo que hago es crear un configs directorio en la raíz del proyecto, y en virtud de que el directorio de mantener varios archivos para todos los entornos (y algunas veces archivos separados para cada desarrollador del medio ambiente así) que son de todos los cambios en el control de código fuente.Y no es el archivo real que utiliza el código llamado config en la raíz del proyecto.Este es el único archivo que no se realiza el seguimiento.Así que parece que esta

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

Cuando alguien se verifica que el proyecto se copia el archivo de configuración que desea utilizar en el sin marcar config archivo y él es libre de editarlo como se desea, pero también es responsable para copiar estos cambios antes de que él se compromete a que el otro ambiente archivos según sea necesario.

Y en los servidores, el sin marcar archivo puede ser simplemente una copia (o de referencia) de las marcas de archivo correspondiente a ese entorno.En JS puede tener simplemente 1 de la línea de exigir ese archivo.

Este flujo puede ser un poco complicado al principio, pero que tiene grandes ventajas:1.Usted nunca tiene que preocuparse acerca de un archivo de configuración para ser eliminado o modificado en el servidor sin tener una copia de seguridad 2.De la misma manera si un desarrollador tiene algunos personalizada configuración de su máquina y la máquina deja de funcionar por cualquier razón 3.Antes de cualquier implementación puede diff los archivos de configuración para development y staging por ejemplo y ver si hay algo que falta o está rota.

Podemos mantener el fichero de configuración de producción registrado.Es la responsabilidad del desarrollador para cambiar el archivo cuando se tire de ella fuera de la fuente segura de ensayo o de desarrollo.Esto ha quemado nosotros en el pasado, así que no lo recomendaría.

Me enfrenté a ese mismo problema y he encontrado una solución para ello.Primero me agrega todos los archivos en el repositorio central (también el desarrollador queridos).

Así que si un desarrollador recupera los archivos desde el repositorio del desarrollador de configuración también está ahí.Al cambiar realizadas a este archivo, Git no debe ser consciente de estos cambios.De esa manera los cambios no puede ser empujado/comprometidos con el repositorio, pero la estancia localmente.

Lo resuelto mediante el comando git: update-index --assume-unchanged.He hecho un archivo bat que se ejecuta en la anterior a la compilación de los proyectos que se contiene un archivo cuyos cambios se deben ignorar por Git.Aquí está el código que he puesto 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 anterior a la compilación me hizo una llamada al archivo bat, por ejemplo:

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

He encontrado en por LO que un archivo bat que copie el fichero de configuración correcto de la web.config/app.config.Yo también llamar a este archivo bat en la anterior a la compilación.El código de 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 anterior a la compilación me hizo una llamada al archivo bat, por ejemplo:

call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top