visual studio - ¿Cómo manejar múltiples configuraciones en la gestión de versiones de VSTS?

visual-studio azure-devops (1)

Para nuestro proyecto, estamos utilizando Visual Studio Team Services para mantener el código y las compilaciones. Para este proyecto también quiero configurar la gestión de lanzamientos. ( https://www.visualstudio.com/en-us/features/release-management-vs.aspx )

Para el entorno de prueba, estadificación y producción, tenemos diferentes archivos de configuración web que se transforman para el entorno específico.

Lo configuré de la siguiente manera (pasos de compilación de MSBuild):

Hay una compilación casi en ejecución, que está creando los artefactos de compilación para la implementación del Servicio de Cloud ServiceConfiguration.cscfg y DeploymentPackage.cspkg ( / t: Publish ) y la prueba del entorno de destino ( / p: TargetProfile = Test )
Los artefactos se publican con una tarea de compilación VSTS para habilitar la implementación con Release Management.
Después de una compilación nocturna exitosa, se crea una versión, los artefactos se descargan y se implementan automáticamente en el entorno de Prueba.

La pregunta es, la versión se crea para el entorno de prueba junto con la prueba Web.config. ¿Cuál es el enfoque general para mover esta compilación al entorno de ensayo? Necesito el Staging Web.config para esto. ¿Debo siempre construir 3 veces y guardar estos artefactos? Eso significaría una gran cantidad de artefactos / espacio en disco para las compilaciones que no se implementarán la mayor parte del tiempo.

MSDN no parece darme una respuesta. ¿Algunas ideas?

Sé que ha pasado casi un año desde que se publicó, pero solo tuve que descubrir la respuesta a este mismo problema para mí, así es como lo hice. Estamos utilizando VSTS, por lo que puede diferir ligeramente de TFS local, no lo sé.

1. Configurar múltiples configuraciones en la definición de construcción

1.1 Abra su definición de compilación para editarla.

1.2 En la pestaña Variable, edite el valor de la variable BuildConfiguration (agregue esta variable si no existe) para que sea una lista delimitada por comas de las diversas configuraciones que desea construir. Cada uno de estos valores debe corresponder a una configuración en el código fuente. En mi ejemplo, tengo tres configuraciones: Dev, Test y Staging. En mi código, cada una de estas configuraciones tiene su propio archivo de transformación web.config que especifica diferentes cadenas de conexión de base de datos y así sucesivamente.

1.3 En la pestaña Opciones, habilite la configuración múltiple en el lado derecho.

1.4 En los ajustes de configuración múltiple, ingrese el nombre de la variable BuildConfiguration en el campo Multipliers . Debe coincidir exactamente con el nombre de la variable para la que estableció el valor en el paso 1.2. En mi ejemplo, puede ver que también he marcado la casilla Paralelo, y eso funciona bien. Supongo que si tienes problemas puedes desmarcar esto.

1.5 En la pestaña Tareas, seleccione la tarea Generar.

1.6 En las opciones para la tarea de compilación, debe actualizar el campo MSBuild Arguments para que el directorio de salida incluya la variable BuildConfiguration . De esta manera, la tarea de compilación creará un directorio de salida separado para cada configuración. En este contexto, la variable BuildConfiguration se especifica como $(BuildConfiguration) .

1.7 Todavía en la pestaña Tareas, seleccione la tarea Publicar artefacto.

1.8 Agregue la variable BuildConfiguration a la ruta especificada en el campo Path to Publish . De nuevo, esto significa que cuando los artefactos se colocan listos para que el proceso de Liberación los recoja, cada configuración tiene su propia subcarpeta. Nuevamente, en este contexto, la variable BuildConfiguration se especifica como $(BuildConfiguration) .

1.9 Cambie el valor del campo Artifact Name a la variable BuildConfiguration : una vez más, es $(BuildConfiguration) aquí.

2. Configurar la definición de versión para múltiples configuraciones

Dependiendo de sus requisitos, este bit puede no ser necesario, pero lo incluiré de todos modos. Así es como creé múltiples entornos en mi Definición de versión, cada uno usando una configuración diferente del proceso de compilación.

2.1. Abra su definición de versión para editar.

2.2. En la pestaña Entornos, seleccione el entorno que desea configurar. Este ejemplo me muestra la configuración del entorno Dev.

Estoy usando la tarea Copiar archivos para publicar mi aplicación web. Es posible que esté utilizando un método diferente, pero esperamos que esto sea suficiente para que apunte en la dirección correcta si está utilizando un método diferente.

2.3. Seleccione la tarea Copiar archivos.

2.4. Modifique el valor del campo Source para que incluya la subcarpeta que contiene la configuración construida adecuada para el entorno que está configurando.

2.5. Continúe y configure el resto de la configuración del entorno según sus requisitos: la máquina (el servidor en el que va a publicar los archivos), etc. El campo Destination Folder será necesariamente diferente para cada uno de sus entornos. El campo de Machines también puede variar.

Sabrá que su proceso de compilación está creando múltiples configuraciones correctamente si se ve así cuando hace una nueva compilación. Tenga en cuenta las múltiples configuraciones en el lado izquierdo:

¡Espero que esto ayude a alguien más a hacer que esto funcione!

ACTUALIZACIÓN La solución descrita anteriormente parece funcionar perfectamente bien. Sin embargo, a medida que la cantidad de entornos en los que estoy implementando una de nuestras aplicaciones ha aumentado (actualmente en 10 y contando), comencé a buscar una forma alternativa de transformar el Web.config para cada entorno, dado que el único La diferencia entre los entornos era la cadena de conexión de la base de datos.

Esto me ha llevado a abandonar la solución descrita anteriormente. En su lugar, nuestro proceso de compilación ahora funciona con solo una transformación de Web.config (en lugar de una para cada entorno) que elimina el atributo de depuración y reemplaza la cadena de conexión de la base de datos con una versión tokenizada, donde el servidor de la base de datos, el nombre, etc. son tokens que será poblado por el proceso de implementación.

Esto es mucho más ordenado. Nuestro código ahora contiene solo una transformación Web.config , nuestro proceso de compilación ahora es mucho más rápido ya que no estamos produciendo una compilación para cada entorno, y las contraseñas de la base de datos, etc., se almacenan, se cifran, como variables en la configuración de la versión.

La idea de lo que he hecho se detalla here , pero mientras que el autor de ese artículo usa una herramienta llamada Tokenizer instalada en su caja de TFS local, he usado la muy buena Tarea de Tokenización del Mercado en mi configuración de Versión para Transformar los tokens que he usado en mi archivo Web.config.