Gestión automática de entornos de despliegue con Azure (tercera parte ¡desplegando!)

Luego de que el camino de usar las Azure API Apps no fuera el mas adecuado para la prueba de concepto (lo cual no quita que sea una tecnología muy prometedora para desarrollar con REST) de nuestro entorno de despliegue, toca proceder a usar los ya conocidos Azure Websites para el ejemplo, en ese sentido repasemos lo que tenemos hasta el momento:

  • Un Team Project en Visual Studio Online, bajo modelo Git (por cierto ¿sabían que está en camino la posibilidad de renombrar los proyectos?)
  • Ya sabemos cómo subir nuestros cambios de nuestro repositorio local de Git a VSO
  • Ya sabemos cómo crear un entorno de despligue en Azure desde Visual Studio, lo hemos visto con API Apps, pero el proceso es básicamente similar para Azure Websites, y claro también hemos aprendido a desplegar desde Visual Studio.
  • Hemos entrado al Portal de Azure y revisado lo que hemos instalado desde Visual Studio.

Con estas bases regresemos a nuestro problema inicial, gestionar los despliegues en entornos separados de QA, Staging, Preproducción, Integración, etc.., en ese sentido debo mencionar que las practicas usuales y conocidas respecto a Integración Continua se basan en el versionamiento de : Código fuente, scripts, datos de prueba, archivos de configuración, siendo lo de Infraestructura como Código un paso más allá en ello (algo en lo que tengo que ponerme cuanto antes); dicho esto el enfoque asumido por Microsoft en los web slots consiste en dejar que el entorno (Azure en este caso) se haga cargo de la gestión de ciertos atributos críticos (definidos por los usuarios, claro está) como las cadenas de conexión a BD de producción, lo cual permite copiar todo el contenido versionado con la seguridad de que no habrá forma de que se hagan públicos esos datos sensitivos, probablemente este enfoque (que personalmente me reduce la cantidad de Perfiles de Publicación que debo de crear en mi proyecto) sea chocante para algunos, pero yo lo veo como una apuesta muy seria y con bastante lógica especialmente cuando ya se trabaja con entornos muy sensitivos, recordemos que los archivos de transformación, que vimos en la primera parte de esta serie, obligan a tener una copia de los atributos variables de cada entorno a fin de luego poder regenerar un .config mezclado.

(Muchas gracias a Scott Hunter quien en el último DevDays me conto estos detalles y permitió que le diera un nuevo vistazo a los slots que es el que comparto con ustedes)

Ya sabemos a que vamos a enfrentarnos, así que manos a la obra.

Como primer paso agregamos a nuestra solución un nuevo proyecto ASP.NET Web que llamaremos WebSlots02SimpleWeb, en este caso lo estamos agregando dentro de la estructura de solución WebSlots01 que ya teníamos.

slots25 Finish Reading: Gestión automática de entornos de despliegue con Azure (tercera parte ¡desplegando!)

Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)

Visto el contexto del problema y la solución potencial, decidí verificar si era posible aplicar esta solución dentro de los nuevos Azure API Apps, nueva tecnología agregada a la oferta de Azure que permite generar APIs REST a nuestra aplicación de manera sencilla, evolucionando lo que ya conocíamos de las Web API.

De primera entrada fijemos los objetivos y características de lo que trataremos de demostrar:

  1. Gestionar nuestro respositorio en Visual Studio Online, usando Git como modelo de repositorio.
  2. Efectuar despliegues automatizados a cada vez que hagamos un commit y sincronización hacia VSO.
  3. Que cada entorno desplegado utilice distintos valores de configuración, que la aplicación sea capaz de “leer” dichos valores y actuar acorde a ello.
  4. Efectuar Intercambios (swaps) entre nuestro entorno de QA, hacia Producción, verificando que si bien la aplicación se actualiza, los valores de configuración se mantienen.

Nuestro primer paso es crear un proyecto en Visual Studio Online, asi que vamos a ello:

Slots01Creado nuestro proyecto vamos a Visual Studio 2013 y nos conectamos a nuestro servidor eligiendo al Team Project que acabamos de crear:

Slots02Hecho esto, nos corresponde “clonar” (esto es terminología Git) el repositorio para empezar a trabajar

Slots03

Finish Reading: Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)

Gestión automática de entornos de despliegue con Azure (Introducción)

510af5389e0b9b98decb66e3b5fd6577e3f73032a4e336aeb523b1c836901341   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.

Entornos

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 proyClipboard01ecto 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. Finish Reading: Gestión automática de entornos de despliegue con Azure (Introducción)

Los “equipos” QA en la ecuación DevOps

Puede que en el nombre del movimiento este el problema: Dev y Ops, desarrollo y operaciones, lo cual tiene a poner a nuestras amigas QA(*) fuera del radar de esta tendencia, pero a poco de pensarlo bien debemos darnos cuenta de que ya están ahí… si es que hacemos las cosas adecuadamente, me explico.

Se espera que el software que desarrollamos y que se entregue tenga calidad (y ojo, no nos olvidemos que la calidad no es negociable) así que entra en acción el proceso de QA, tests, ratificación o ya en plan sofisticado “certificación”, pero lamentablemente en la gran mayoría de los casos estas pruebas se efectúan al final de cada etapa de desarrollo, a veces en un entorno dedicado, a veces en preproducción y otras (felizmente muy pocas) en el propio entorno de desarrollo, volviéndose un ejercicio incremental, pues como en cada ciclo o iteración de desarrollo se añaden nuevas funcionalidades (con suerte Historias de usuario) el equipo QA tiene que probar todo, incluyendo lo que se probo hace unas semanas, no vaya a ser que se caiga en una de las temidas “regresiones” y algo ya validado deje de funcionar.

Ah, ¿y se han percatado que dije “equipo QA”?, ¿no les causa ruido? pues esto es indicativo de que ese proceso esta vinculado a personas diferentes a la labor de desarrollo, asi que de generar sinergias ni hablar.

Pues si, lo usual, incluso en equipos que se denominan “agiles”, pero como bien nos recuerda Javier Garzas no se puede ser agil si se prueba en cascada, pues lo que hemos descrito anteriormente es efectivamente un proceso en cascada lo cual nos lleva a algo que tenemos asumido desde hace tiempo (y es parte de la raíz de este modo de trabajar en QA): el “ritual” del pase a entornos: descarga de ultima versión (si es que todo esta bien sincronizado), separar los archivos modificados, asegurarse de que los archivos de configuración este Ok, copia de archivos, reiniciar entornos… etc, y si el pase es a producción ya mejor ni hablar: gran amanecida bailable con desayuno incluido.

¿ Y del lado de QA esta forma de trabajar como les afecta? Simple: el entorno donde probar no esta actualizado de manera frecuente, asi que hay un gran delay entre el tiempo en que Desarrollo entrega nueva funcionalidad o corrige bugs y el que QA puede “verlos”, eso de manera evidente. Pero aun hay mas, como mencionaba al principio la validación es manual e incremental dándose el caso que vi de una QA que en cada iteración debía validar la aplicación contra una tabla de valores para verificar que los resultados siguieran siendo los esperados ¿no habría una forma de reducir el trabajo repetitivo de tal manera que el esfuerzo de las pruebas inevitablemente manuales se centre en las nuevas funcionalidades y lo que respecta a la validación de usuario?

Si que la hay, y ya hemos hablado frecuentemente de ello, tender a la Integración y Entrega Continua, buenas practicas (vitales del movimiento DevOps a fin de entregar valor constantemente) que facilitan y a la vez requieren el tener pruebas automatizadas que se ejecuten frecuentemente, acotando lo manual a lo necesario, pero mas aun: facilitando el que se caigan las barreras entre QA y Dev al generar (¡al fin!!!) equipos multidisciplinarios (y no bandos en pugna **) que se den feedaback periódicamente.

Pero aun hay mas, y esto nos lleva al titulo de este post, el escenario DevOps abre una gran oportunidad para QA de asumir liderazgo en este proceso, pero para lo cual algunas cosas deben de cambiar (como nos indica el enlace anterior):

Empoderar a QA para que recomiende o determine las herramientas (de automatización y pruebas)
Que QA migre a una mayor estrategia de tests
Dar a QA una mayor visibilidad dentro de la hoja de ruta
Cambiar QA a un enfoque mas productivo que reactivo
Permitir a QA evangelizar y educar en DevOps

devops_01Pero si, este cambio no es fácil, estamos hablando de una “cultura” ya establecida, que si ya nos esta costando evolucionar en tanto a la adopción del agilismo, por el lado de la forma de trabajar con QA existen retos diferentes:uno el trabajar como departamento separado, lo cual como recordamos anteriormente nos aleja del desarrollo de sinergias, pilar de lo que es DevOps;  por otro lado el hecho de que buena parte de quienes trabajan en QA se acercaron a dicha área porque de esa manera no tendrían que programar, si, esa es la verdad y es una pena, pero buena parte de la automatización de pruebas requiere habilidades de programación y esto es algo que ha venido para quedarse; y finalmente el factor económico, se asume erróneamente que introducir a QA desde la concepción del proyecto es un error por el costo que esto implica (asumiendo de partida que las pruebas se harán “al final”), siendo que el costo de tratar de corregir la falta de calidad en estadíos tardíos es mucho mayor que el que involucra trabajar con pruebas y alcances claros desde el principio.

El reto esta puesto, QA es totalmente necesario para lograr sinergias y entregar valor desde el principio, tal vez el propio nombre “DevOps” no ayuda a recordar que QA es parte del proceso, pero si que lo es, sin esa vital pieza no tenemos la figura completa. Espero sus opiniones para ver como podemos mejorar este proceso.

Referencias adicionales:
Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad
Cuándo deberías hacer los pasos a producción dentro de un Sprint o iteración

(*)Si, en esta profesión tan bonita que es la informática se da el fenómeno que el sector de QA es terreno femenino en su gran mayoría, pero eso da para otra historia.

(**) Un QA tenia en su estatus la siguiente frase “Todo QA debe tener un corazón de desarrollador, guardado en un frasco”