A estas alturas ya debería estar claro para que sirve la integración continua y sus ventajas: el tener un sitio donde se corran todas las compilaciones y tests, el evitar “en mi maquina funciona”, reducir el tiempo de despliegue, el tener una buena gestión de los diversos entornos ¿no?

Bueno, en esta ocasión quiero referirme a la gestión de los diversos entornos en que va a correr nuestra aplicación durante su ciclo de vida: Desarrollo, QA, Staging, PreProducción, Certificación, Producción, etc, como quieran llamarle, pero el caso es que mal que bien (aun cuando no se usen practicas Agiles, DevOps o Integración Continua) al menos hay un reconocimiento en las organizaciones de que no se puede pasar las aplicaciones directamente de la máquina del desarrollador a Producción, bueno, salvo el caso de un sitio donde trabaje en el que los entornos de PreProducción estaban tan desactualizados que no quedaba otra que hacer los pases “en caliente”.

Pero como ya sabemos, cuando trabajamos en múltiples entornos, debemos asegurarnos que cada entorno tenga un conjunto de parámetros separado, de tal manera que no vaya a ser que al entorno de Producción se le dé por escribir en el entorno de QA, o a QA buscar la máquina del ultimo desarrollador que hizo el pase de entorno, de ahí que en buena parte de los despliegues (manuales) se dedique buen tiempo a verificar que estamos copiando los archivos de configuración en el entorno adecuado, y claro esta tarea es pequeña pero estresante.

Soluciones hay muchas y una de las que nos brinda desde hace buen tiempo Visual Studio son las “transformaciones” que básicamente consiste que en adición a nuestro Web.config y app.config incluyamos en nuestro proyecto archivos de nombre web.EntornoObjetivo.config como se ve en el gráfico, siendo que cada uno de estos archivos contiene fragmentos XML donde se indican que atributos de configuración serán alterados en el entorno destino y que valores se colocaran en reemplazo de los que habían en Web.config.

Ahora bien ¿Cómo se decide que transformaciones aplicar? Para eso se utilizan los perfiles de publicación (Publish Profiles) que se pueden crear para efectuar el despliegue de nuestras aplicaciones al entorno correcto en el mecanismo elegido (WebDeploy, FTP, FileSystem, archivos empaquetados), estos perfiles pueden ser invocados manualmente desde VS (no es lo óptimo, pero a veces es necesario, pero al menos ya es mucho más automático que el compilar, copiar archivos y luego cruzar los dedos) o mediante un servidor de Integración Continua como Visual Studio Online lo cual nos permite configurar los despliegues (o simple ejecución de tests) a fin de que se ejecuten cada vez que se suba o actualice un archivo, periódicamente o manualmente desde el entorno de VSO, corresponde a cada organización definir sus políticas y calendarios.

Este proceso tiene sus particularidades (y quedan para otro artículo) especialmente al momento de preparar un entorno OnPremise a fin de que esté listo para recibir despliegues automáticos vía Web Deploy, pero aun cuando hayamos llegado al muy deseable grado de poder hacer despliegues con un solo clic (o con un commit) no es raro que nos encontremos con una situación algo peculiar:

Supongamos que los desarrolladores integran continuamente y el motor de IC publica en el entorno de QA cada 5 días (si, es algo exagerado, pero es para dejar clara la idea), dependiendo del ok del equipo de QA para efectuar un pase a producción:

1. Desarrollo pasa al entorno QA una nueva Historia de Usuario (ABC1) y una corrección de bug al cierre del martes.
2. El equipo QA empieza las revisiones el miércoles en la mañana.
3. Desarrollo empieza el desarrollo de dos nuevas Historias de Usuario (DEF1, PQR2) ese mismo miércoles en la mañana.
4. El jueves en la tarde, QA avisa que tanto el bug como la nueva HU ABC1 están ok, y como el cliente está muy interesado se pide que se efectué el pase a Producción el viernes en la mañana.

La situación ya cobra dimensiones de problema ¿no? al momento que ocurre 4 Desarrollo ya ha empezado la codificación de las nuevas funcionalidades (DEF1, PQR2) por lo que si se efectúa el pase a producción (automatizado claro esta) con el contenido del repositorio vigente el jueves se pasaría una aplicación incompleta y muy potencialmente inestable.

Tenemos varias forma de enfocar la situación:

1. Usar características apagables, de manera tal que a pesar de que el código fuente ya incluye una nueva funcionalidad, esta no es visible en el entorno destino porque se han editado los archivos de configuración, para que el código ante ciertos valores haga disponible o no dicha funcionalidad, enfoque muy necesario (y que vale la pena tener siempre en cuenta) pero a veces insuficiente sobre todo si se tiene que manipular componentes comunes entre la funcionalidad nueva y las ya existentes.
2. Trasladar los compilados del entorno QA al entorno de Producción, y claro asegurarnos de que no se copien los archivos de configuración propios del entorno QA.
3. Recompilar, testear y desplegar la versión del repositorio vigente al cierre del martes.

Descartemos la opción 1, las otras opciones requieren manipulación manual de archivos (con la consiguiente pérdida de las ventajas de los despliegues automatizados) o aplicar procesos que permitan recuperar versiones históricas ya sea de los compilados o el código fuente, estos procesos existen desde hace tiempo (lo sé porque participe en el desarrollo de uno de ellos para TFS 2005) pero son mucho muy tediosos de implementar, así que si podemos encontrar una forma de gestionar esto de manera mas simple, pues bienvenida sea.

En ese sentido la disponibilidad desde el año pasado de los Azure Websites Slots (primero solo para staging y ahora para múltiples definiciones) viene a facilitar esto de los despliegues porque permite tener varios entornos de despliegue (slots) y mover fácilmente los contenidos entre cada slot, manteniendo cada entorno su propio conjunto de configuraciones sin tener que recurrir a las transformaciones arriba comentadas.

De esto tratara lo que viene, como he intentado experimentar esto con las nuevas Azure API Apps, generar mis Websites haciendo uso de los slots, y claro, todo esto integrado con Visual Studio Online.

Quedo a la espera de sus comentarios.