configuraciones específicas de la máquina web.config y app.config en git

Question

Tenemos varios equipos de desarrolladores en diferentes oficinas, y necesitan diferentes valores para varios ajustes de configuración en los proyectos web.config y app.config.

Nos gusta mantener estos archivos de configuración controlados con un conjunto razonable de valores predeterminados, de modo que al verificar la rama troncal/maestra tiene algo que funciona sin necesidad de buscar archivos de configuración.

Históricamente hemos utilizado Subversion, y específicamente TortoiseSVN, y esto proporcionó una manera fácil de administrar cambios locales: simplemente agregamos estos archivos a la lista de cambios automática ignore-on-commit de TortoiseSVN. Esto evita el registro accidental de estos archivos, ya que luego debe seleccionarlos específicamente para incluirlos en un check-in (y puede asegurarse de que está comprobando cambios significativos, no ruido de configuración local). La principal desventaja de este enfoque es que los archivos de configuración siempre se ven "modificados", por lo que no es posible saber de un vistazo si tiene algún cambio local.

Estamos buscando cambiar a Git, y estoy tratando de encontrar el mejor enfoque.

En primer lugar, lo que ya existe en otras respuestas StackOverflow:

Opción 1: Llegada archivos xxx.sample y .gitignore los archivos de configuración reales: Esto se recomienda, por ejemplo, en this answer. El problema principal que veo con esto es que los cambios en el archivo de configuración se olvidan fácilmente, en dos puntos diferentes: el committer puede perder fácilmente los cambios que necesitan agregar al archivo .sample, y los consumidores (especialmente el servidor de integración continua) pueden fácilmente pierda los cambios que necesitan incorporar desde el archivo .sample en su archivo de configuración local. Entonces, básicamente, esa no parece una muy buena solución.

Opción 2: Tener un facturado en el archivo xxx.defaults y un archivo de configuración xxx.local .gitignored que anula cualquier configuración que define: Este es ofrecido, fr ejemplo, here. El problema es que estamos trabajando con proveedores de configuración de .Net estándar. Realmente no quiero que implementemos un marco de carga de configuraciones completamente nuevo cuando Mirosoft ya ha hecho todo el trabajo. ¿Alguien sabe cómo obtener los archivos app.config y web.config para hacer referencia a los archivos de anulación local opcionales?

Opción 3: Tener los desarrolladores de mantener las ramas locales, y luego tenerlas siempre comprobar en cereza-picks o restablecen las ramas en maestro, a bypass/evitar siempre las confirmaciones no deseados en su rama local: Esto se ofrece como una posible flujo de trabajo here, y si bien aprecio la limpieza en términos de seguimiento de cambios (todo registrado), introduce una cantidad significativa de requiere de gastos generales en cada registro; es un gran dolor!

Opción 4: Tener archivos de configuración registramos, pero ellos han marcado con --assume-unchanged: Esto se ofrece como una opción posible here; por lo que puedo decir, es muy similar en espíritu a la lista de cambios ignore-on-commit en TortoiseSVN, excepto que no tiene visibilidad para estos archivos cambiados "ocultos" en un proceso de confirmación; TortoiseGit, por ejemplo, muestra el archivo con una superposición de iconos "modificada", pero en el cuadro de diálogo de confirmación el archivo no aparece en absoluto. Esto parece un poco aterrador, nuevamente es muy fácil olvidarse de verificar los cambios en.

Dadas estas opciones, que son todas las que he encontrado, realmente estoy esperando una manera de "incluir" opcionalmente un archivo de configuración local en/sobre un archivo app.config/web.config registrado y vaya con opción 2; ¿Alguien sabe de una manera de hacer esto u otras opciones que me estoy perdiendo? (Estoy un poco tentado de considerar un paso personalizado de precompilación Xml-fusión ...)

Debería haber mencionado antes, todavía estamos en VS2008, por lo que las Transformaciones de configuración no están disponibles.

---

ACTUALIZACIÓN: (suprimido, estaba mal llano)

ACTUALIZACIÓN 2: He eliminado mi actualización y la respuesta anterior, que era una estupidez/no funcionó. No me di cuenta de que después de una fusión "nuestra", la siguiente fusión en la otra dirección lleva las versiones "originales" de esos archivos (sobrescribe los cambios de la sucursal local); ver el historial de edición si estás interesado. Esta pregunta es tan abierta como siempre.

Answer 1

Me gustaría echar un vistazo a this answer for Managing complex Web.Config files between deployment environments por Dan para una posible solución. Utilizo mercurial y uso este mismo proceso para tener un archivo web.config genérico registrado y utilizar las transformaciones web para cambiar la ubicación de configSource para apuntar a mi material específico de implementación.

La ventaja de utilizar esta ruta es que está completamente integrada en el marco, no requiere código adicional y funciona con la implementación web.

registramos en web.config:

<?xml version="1.0"?> 
<configuration> 
    <!-- snip --> 
    <connectionStrings configSource="config/connectionStrings.config" /> 
</configuration> 

registramos en web.debug.config:

<?xml version="1.0"?> 
<configuration> 
    <connectionStrings 
     configSource="config/dev.connectionStrings.config" 
     xdt:Transform="Replace(configSource)" /> 
</configuration> 

Tengo un config/connectionStrings.config registramos con valores por defecto, pero los servidores de desarrollo config/dev.connectionStrings.config no ha sido controlada en y no se reemplaza en una nueva implementación.

Answer 2

Me gustaría sugerirle que mire ConfigGen. Lo usamos en todos nuestros proyectos, y funciona de maravilla para todos los desarrolladores y también para todos nuestros entornos. Básicamente se ejecuta en una hoja de cálculo que indica el nombre de la máquina y el archivo de configuración de salida, y luego tokeniza una plantilla App.Config o Web.Config, sustituyendo los valores de la hoja de cálculo en ella. Agregue un paso simple de preconstrucción a sus proyectos para ejecutar configgen, y antes de que la compilación comience, usted tiene un archivo de configuración a medida para su máquina. También es compatible con la configuración predeterminada.

Eche un vistazo al sitio y haga su propia opinión, pero definitivamente puedo responder por ello.

EDIT: Vale la pena señalar que puede ignorar todos sus archivos Web.config y App.config (en términos de .git). Pero necesita agregar sus plantillas y hojas de cálculo al repositorio. Además, estoy seguro de que hay una actualización en el camino que bien puede incluir un reemplazo xml para las hojas de cálculo, que tiene su propio editor, por lo que es eminentemente más adecuado para DVCS.

Edit2: También eche un vistazo a la publicación de Daniel aquí: https://stackoverflow.com/a/8082937/186184. Él da un ejemplo muy claro de la plantilla y la hoja de cálculo, y cómo hacer que funcione en su solución.

Answer 3

Nos encontramos con un dilema similar en nuestra empresa. Terminamos creando ramas de configuración separadas que complementan la rama principal. Como por ejemplo - develop-config, master-config, etc. Luego tenemos un pequeño script que volverá a establecer una base de esas ramas con la rama fuente correcta en función del entorno de despliegue. Entonces, por ejemplo, en la máquina de desarrollo, rebase el desarrollo-config con el desarrollo. Si está trabajando en una máquina local, obtendrá la configuración predeterminada (acordada por todos los desarrolladores) que se registra en la rama principal (como el nombre de la BD local, la contraseña, etc.). Por supuesto, la desventaja es que siempre debe mantener actualizadas esas * ramas configuradas o ponerlas al día en el momento de la implementación.

Desde la implementación de este flujo de trabajo, he encontrado algunas herramientas de implementación como whiskey_disk que tienen un enfoque similar. De hecho, me gusta mucho más su solución ya que es mucho más segura y flexible. Aunque probablemente no sea una buena opción para ustedes, ya que se orientó más hacia una pila de desarrollo LAMP/RoR.

Aparte de eso, también hay algunas soluciones comerciales por ahí que es posible que desee echar un vistazo a como Beanstalk

Answer 4

¿Consideró un content filter driver?

Eso significaría, en cada git checkout, el guión mancha sería generar el archivo de configuración real basado en:

• un archivo de plantilla de configuración (con el valor de configuración del marcador de posición como @@A_PARAM_VALUE@@)
• uno del archivo de valores de configuración (cada desarrollador puede mantener la versión de sus propios valores de archivo de configuración)

Eso evita cualquier problema de fusión y configuraciones de gitignore: cada "archivo de valores de configuración" es diferente y permanece separado.
Esto también es compatible con otra solución de generación de configuración como ConfigGen mencionado en pms1969 's answer.

Answer 5

Un poco ha cambiado desde 2012 y en estos días, y ahora sugeriría su herramienta de compilación/implementación (VS Team Services, TeamCity, Octopus Deploy) administrando configuraciones específicas del entorno.

Si trabaja en azul, puede definir la configuración de la aplicación y las cadenas de conexión como parte de la definición de su aplicación.