.net - example - Configuraciones específicas de la máquina web.config y app.config en git

wcf endpoint configuration

Question

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

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

Históricamente, hemos usado Subversion, y específicamente TortoiseSVN, y esto proporcionó una manera fácil de administrar los cambios locales: simplemente agregamos estos archivos a la lista de cambios automática de ignore-on-commit TortoiseSVN. Esto evita el registro accidental de estos archivos, ya que luego debe seleccionarlos específicamente para incluirlos en un registro (y puede asegurarse de que esté verificando cambios significativos, no ruido de configuración local). La principal desventaja de este enfoque es que los archivos de configuración siempre parecen "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 está allí en otras respuestas de StackOverflow:

Opción 1: Incorpore los archivos xxx.sample y .gitignore los archivos de configuración reales : Esto se recomienda, por ejemplo, en esta respuesta . El principal problema que veo con esto es que los cambios en el archivo de configuración se olvidan fácilmente, en dos puntos diferentes: el .sample puede pasar por alto fácilmente los cambios que necesitan agregar al archivo de .sample , y los consumidores (especialmente el servidor de integración continua) pueden .sample fácilmente los cambios que necesitan incorporar del archivo .sample en su archivo de configuración local. Básicamente, eso no parece ser una muy buena solución.

Opción 2: tener un archivo xxx.defaults registrado y un archivo de configuración xxx.local .gitignored que anula cualquier configuración que defina : Esto se ofrece, fr ejemplo, here . El problema es que estamos trabajando con proveedores de configuración de .Net estándar. Realmente no quiero que implementemos un nuevo marco de carga de configuración cuando Mirosoft ya haya hecho todo el trabajo. ¿Alguien sabe una manera de obtener los archivos app.config y web.config para referirse a los archivos de reemplazo locales opcionales?

Opción 3: haga que los desarrolladores conserven las sucursales locales, y luego pídales que siempre comprueben los establecimientos seleccionados o rebasados ​​en master, para evitar / evitar los compromisos no deseados en su sucursal local : esto se ofrece como un posible flujo de trabajo here , y mientras aprecian la limpieza de la misma en términos de seguimiento de cambios (todo lo registrado), introduce una cantidad significativa de gastos generales requeridos en cada registro individual; ¡Es un gran dolor!

Opción 4: haga que los archivos de configuración --assume-unchanged registrados, pero --assume-unchanged marcados con --assume-unchanged : esto se ofrece como una posible opción here ; por lo que puedo decir, es muy similar en espíritu a la lista de ignore-on-commit en TortoiseSVN, excepto que no tiene visibilidad de estos archivos modificados "ocultos" en un proceso de confirmación; TortoiseGit, por ejemplo, muestra el archivo con una superposición de iconos "modificados", pero en el cuadro de diálogo de confirmación el archivo no se muestra en absoluto. Esto parece un poco aterrador, una vez más, 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 e ir con la opción 2 ; ¿Alguien sabe de una manera de hacer esto, u otras opciones que me estoy perdiendo? (Estoy ligeramente tentado de considerar un paso de precompilación de fusión de XML personalizado ...)

Debería haberlo mencionado anteriormente, todavía estamos en VS2008, por lo que las Transformaciones de Configuración no están disponibles.

ACTUALIZACIÓN: (eliminado, estaba claramente equivocado)

ACTUALIZACIÓN 2: He eliminado mi actualización anterior y la respuesta, fue estúpido / 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 rama local); Ver el historial de edición si estás interesado. Esta pregunta es tan abierta como siempre.

Answer 1

¿Consideraste un controlador de filtro de contenido ?

Eso significaría que, en cada git checkout , el script de borrado generaría el archivo de configuración real basado en:

• un archivo de plantilla de configuración (con marcador de posición de valor de configuración como @@A_PARAM_VALUE@@ )
• uno de los archivos de valores de configuración (cada desarrollador puede mantener versionados sus propios valores de archivos de configuración)

Eso evita cualquier problema de combinación y configuración 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 mencionada en la answer .

Answer 2

Me gustaría sugerirte que mires 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 muestra una plantilla App.Config o Web.Config, sustituyendo los valores de la hoja de cálculo en ella. Agregue un paso de precompilación simple a sus proyectos para ejecutar configgen, y antes de que comience la compilación, tendrá un archivo de configuración personalizado 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.

EDITAR : vale la pena señalar que luego puede ignorar todos sus archivos Web.config y App.config (en términos de .git). Pero sí necesitas agregar tus plantillas y hojas de cálculo al repositorio. Además, estoy seguro de que hay una actualización sobre la forma en que puede incluir un reemplazo xml para las hojas de cálculo, que tiene su propio editor, por lo que es mucho más adecuado para DVCS.

Edit2 : También eche un vistazo a la publicación de Daniel aquí: https://.com/a/8082937/186184 . 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 clasificar esas sucursales con la rama fuente correcta en función del entorno de implementación. Así, por ejemplo, en la máquina de desarrollo se volvería a desarrollar con la configuración de desarrollo. Si está trabajando en una máquina local, obtendría la configuración predeterminada (acordada por todos los desarrolladores) que se verifica en la rama principal (como el nombre de la base de datos local, la contraseña, etc.). Por supuesto, el inconveniente es que siempre tiene que mantener actualizadas las sucursales * -config o actualizarlas en el momento de la implementación.

Desde la implementación de este flujo de trabajo, he encontrado un par de 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 está más orientado hacia una pila de desarrollo LAMP / RoR.

Aparte de eso, también hay algunas soluciones comerciales por ahí que quizás quieras echar un vistazo a Beanstalk

Answer 4

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

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

Answer 5

Daría una mirada a esta respuesta para la administración de archivos complejos de Web.Config entre entornos de implementación por Dan para una solución potencial. Uso mercurial y uso este mismo proceso para tener un archivo web.config genérico registrado y uso las transformaciones web para cambiar la ubicación de configSource para que apunte a mis cosas específicas de implementación.

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

Comprobado en web.config:

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

Comprobado 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 registrado con los valores predeterminados, pero los servidores de desarrollo config/dev.connectionStrings.config no están registrados y no se reemplazan en una nueva implementación.