Visual Studio Release Management: toma el control de tus entregas

Lunes por la tarde. Armando Broncas, el gerente, entró en la sala y caminó lentamente entre las cajas vacías de pizza, los montones de latas abolladas de bebidas energéticas y los vasos de café a medias. Los tres miembros del equipo de desarrollo y alguien de sistemas yacían dormitando sobre sus teclados. Tuvo que emitir hasta cuatro veces una tos forzada, cada vez a más volumen, hasta que el primero de ellos abrió parcialmente un ojo, cual oso al que acabaran de sacar del letargo invernal.

― Marchaos a casa. No hay mucho más que se pueda hacer por hoy. Os necesito a todos mañana a primera hora en la sala de reuniones; si la próxima entrega no sale bien, todos nosotros seremos los que saldremos. Muy posiblemente hasta en las noticias.

Concha Puzas y Arístides Bordamiento cruzaron unas miradas cansadas mientras se arrastraban lentamente en dirección al ascensor. No habían dormido prácticamente nada desde el viernes, cuando comenzó la salida a producción de los últimos cambios. Pero eso era lo que menos les preocupaba ahora. El verdadero problema era que no recordaban ni una sola entrega sin problemas en todo el proyecto, y ambos sabían que la advertencia de Armando iba muy en serio. No tenían más margen de error, todo el mundo había perdido la confianza en ellos.

El tercer integrante del equipo, Manolo Heprobado, siguió doblado sobre su mesa, ahora ya emitiendo sonoros ronquidos. Asier Vidores, el de sistemas, se dirigió a su departamento tan rápido como pudo, visiblemente enfadado.

Al día siguiente los cuatro decidieron quedar un poco antes en la cafetería, para intentar preparar una explicación creíble de lo que había ocurrido durante el fin de semana. Se sorprendieron un poco al llegar a la sala de reuniones, donde les esperaba una chica que trabajaba con otro de los equipos de desarrollo. ¿Se había equivocado de reunión? Antes de que ninguno de ellos pudiese abrir la boca para preguntárselo, Armando se materializó junto a ella (¿de dónde había salido? ¡En ese lado de la sala no hay ninguna puerta!) y comenzó a hablar en un tono un poco más alterado que de costumbre.

― Os presento a Mamen Trega, está haciendo de release manager para un par de proyectos, y hasta ahora no han tenido problemas para salir a producción en ninguno de ellos. No tengo ni la menor idea de qué es lo que lo hace, pero quiero que vosotros empecéis a hacer lo mismo. Ya.

Y se esfumó tan rápidamente como había aparecido.

Los cuatro miraron a Mamen con desconfianza; no creían que ella fuese a solucionar en las pocas semanas que había hasta la próxima entrega los problemas que el proyecto llevaba meses arrastrando. Pero no tenían muchas más opciones, así que después de unas frías presentaciones intentaron con desgana escuchar lo que Mamen empezaba a contarles:

― No sé si habéis oído alguna vez hablar de algo que se llama DevOps

― Sí ―dijo Manolo― es otra de esas modas que han inventado unos gurús con pocos proyectos que terminar y mucho tiempo para enredar. Ya nos han asignado a Asier para que nos ayude con los despliegues.

Asier miró a Mamen con resignación, como si le estuviese pidiendo que le sacase de allí lo antes posible.

― Pero no basta con que llaméis a Asier para que os ayude el mismo día de la entrega. Tenéis que trabajar juntos a diario, preparando las entregas e incluso ensayándolas antes de hacerlas en el entorno real.

Asier emitió un profundo suspiro, como si hubiese perdido toda esperanza.

― Sí claro ―dijo Concha― siempre que hubiese tiempo de sobra para dedicarse a eso en vez de a programar.

― En realidad ―respondió Mamen― tendríais más tiempo para programar y hacer pruebas, y podríais hacerlas más fácilmente, si mejoraseis vuestro proceso de entrega. Me apostaría una cena a que incluso haríais menos horas extra. Pero vamos al grano, porque hay mucho en lo que trabajar. ¿Podéis contarme alguno de los problemas que habéis tenido en las últimas salidas a producción?

Tras un breve silencio y un intercambio de miradas, Arístides tomó la palabra.

― Bueno, este viernes empezaron los problemas cuando Asier se saltó uno de los pasos en el despliegue y dejó la base de datos en un estado inservible. Y lo peor es que habíamos olvidado hacer backup.

― Vamos que la base de datos quedó más inútil que el codo de un playmobil ―añadió Manolo.

carteles triste vida los playmobil desmotivaciones

― Eso no habría ocurrido si el documento de despliegue hubiese estado actualizado ―respondió Asier, bastante nervioso por las risas de los demás.

― ¿Y si en lugar de un documento de despliegue tuvieseis el proceso de despliegue automatizado en una herramienta? Ahí no habría posibilidad de olvidarse de ningún paso, ni de cometer errores al seguirlo. Os voy a mostrar cómo lo tenemos nosotros en la herramienta que estamos usando, Visual Studio Release Management ―dijo Mamen, mientras conectaba su portátil al proyector y hacía doble click en el icono del cliente de la herramienta.

image

Como veis tenemos el despliegue perfectamente definido en un workflow. Es lo que se llama Release Template en la herramienta. Incluso tenemos pasos concretos para comenzar haciendo una copia de seguridad automáticamente, y restaurarla al final si algo va mal. De hecho, seguramente tengáis varias etapas por las que va pasando la aplicación con los cambios en el código, usando distintos entornos cada vez, para hacer validaciones. La típica promoción de desarrollo a integración, de ahí a pruebas, después a pre-producción, y por último a producción. O lo que tengáis en vuestro caso. Es lo que últimamente todo el mundo llama pipeline; pues bien, en la herramienta también podemos definir una pipeline o Release Path, y cada etapa o stage en el Release Path tiene su propia Release Template asociada. De ese modo, podemos definir todo el proceso, desde que introducimos un cambio hasta que éste se libera en producción, e incluso tenerlo todo automatizado si así lo deseamos. Por ejemplo, nosotros ahora tenemos un proceso simple con sólo tres etapas llamadas Dev, QA y Prod, y en cada una de ellas podemos definir los entornos destino donde se ejecutan los despliegues y validaciones, y qué pasos se siguen para cada una de estas operaciones.

image

― Uf, pero nosotros nunca podríamos llegar a automatizar todo lo que hacemos durante un despliegue ―se quejó Manolo. Es demasiado complejo, tendríamos que emplear un montón de tiempo en escribir esas automatizaciones, y lo que menos nos sobra ahora mismo es tiempo. Tardamos menos si seguimos haciéndolo a mano y arreglamos los posibles errores sobre la marcha.

― Bueno, eso es muy discutible. ¿Lo has intentado alguna vez? ¿has sumado las horas extra, noches y fines de semana que empleáis en cada entrega? El tiempo que empleas en las automatizaciones puede ser grande, pero lo haces una vez y ya te sirve de ahí en adelante, con mínimos cambios. Además, Release Management viene con un montón de utilidades que cubren las actividades más frecuentes que se hacen durante los despliegues y validaciones. Son las llamadas Tools y Actions.

image

 

image

Ahí tienes de todo ―continuó Mamen― desde desplegar una base de datos o un sitio web, a arrancar o parar máquinas en Azure. Y no sólo despliegues, también puedes lanzar pruebas automatizadas de todo tipo y recoger los resultados. Basta con arrastrarlas al workflow de la Release Template y especificar los parámetros necesarios.

image

Nosotros hasta ahora nos hemos apañado perfectamente con las que vienen de serie, no hemos necesitado escribir ninguna nueva, y nuestro proyecto no es que sea trivial precisamente. Y en cualquier caso si lo necesitas, puedes añadir tus propias automatizaciones y usarlas junto a las existentes.

Asier llevaba un rato moviéndose en su asiento, bastante inquieto. Finalmente no pudo contenerse:

― ¿Y crees que es seguro dejar que se ejecuten cosas arbitrariamente en los servidores? Yo no estoy tranquilo si no lo hago yo mismo a mano, paso a paso. Quiero saber lo que se está haciendo sobre la máquina en todo momento. Son entornos demasiado costosos y caros de mantener, como para dejar que se lancen scripts sobre ellos despreocupadamente. Sobre todo viendo el cuidado que ponen todos éstos en mantener los entornos funcionando de forma óptima. Ya hacen barbaridades a mano, pues imagínate si pudiesen hacerlas automáticamente.

image

― Ya Asier ―replicó Mamen―, no te ofendas, pero detrás de tus palabras veo el típico miedo a perder el control sobre tus dominios, a ceder parte del poder que te ha costado tanto conseguir. La verdad es que los servidores no van a distinguir si eres tú el que tiene las manos sobre el teclado, o si las órdenes vienen de un agente de despliegue automatizado que se ejecuta siguiendo las directrices del Release Path que has definido en el servidor. Y lo bueno es que el agente, o Deployer que es el nombre que tiene en la herramienta dentro de Release Management, no comete errores por estar cansado o aburrido. No omite pasos por olvidos o distracciones. No cambia el proceso a criterio propio, o para tomar atajos. Tú sigues manteniendo todo el control, porque tú defines lo que se acaba ejecutando. Bueno, idealmente tú, en colaboración con todo el equipo de desarrollo, ahí es donde entra la filosofía DevOps.

image

― Mamen, pero eso implicaría dar acceso a todo el mundo para que pudiese ejecutar las automatizaciones. Confieso que algo de miedo a perder el control sí que tengo, pero es que si doy acceso a todo el mundo, por muy cuidadosos que me prometan ser, o por mucho que confíe en ellos, al final alguna acabarán liando aunque sea involuntariamente, y entonces aparte del control lo que voy a perder es mi empleo. Porque en mi departamento me acusarán de negligencia.

― Nadie ha dicho que tengas que dar acceso a todo el mundo. El Deployer es ejecutado por una cuenta de servicio de la que sólo tú tendrías la contraseña, si así lo deseas. Y por lo tanto, en cada servidor puedes ajustar los permisos de esa cuenta para que sólo esté autorizada a las operaciones que sean necesarias, y sólo sobre los elementos definidos, y ningún otro. De hecho podrías utilizar cuentas distintas para servidores distintos si así lo crees conveniente. Y aparte de eso puedes configurar para cada etapa o stage validaciones y aprobaciones previas o posteriores a cada automatización, para que nada sea ejecutado automáticamente si no es revisado previamente, o para asegurarse de que todo ha ido bien antes de pasar al siguiente stage.

image

Como veis ―continuó Mamen tras mostrar la configuración de seguridad establecida para su Release Path― estas validaciones y aceptaciones pueden asignarse para que sean realizadas por personas concretas o por grupos de ellas, para no tener que depender de alguien individualmente, lo cual nunca es bueno. Sobre todo cuando ese alguien se va de vacaciones o decide pillar la gripe.

― Además Asier ―interrumpió Concha― mucha preocupación por tener tú el control, y luego ejecutas las cosas en el servidor equivocado, como aquella vez durante la salida a producción de la campaña de navidad. Esa sí que fue sonada.

Asier se ruborizó visiblemente ante las carcajadas de los demás por el comentario de Concha. Pero Mamen se apresuró a apaciguar los ánimos:

― Bueno, quizá si vosotros hubieseis definido claramente los entornos y servidores involucrados, en lugar de dejar un montón de ficheros en una carpeta de red para ser desplegados, esperando a que el que haga el trabajo tenga dotes adivinatorias, la cosa hubiese ido mejor para todos. Seguramente el cabreo de vuestro gerente, Armando, no hubiese sido menor si se hubiese enterado de quién cometió el error. Precisamente ahí está el cambio de mentalidad que necesitáis; la responsabilidad es de todos, y si la entrega va mal, todos acabáis haciendo horas extra para solucionarlo. Así que ganaríais más si colaboraseis para preparar todo el proceso, en lugar de estar pasando la pelota de unos a otros. En cualquier caso es algo en lo que la herramienta también os ayuda: podéis especificar qué entornos utilizáis, de qué servidores consta cada uno de ellos, qué servidores se pueden utilizar en qué entornos, y a través de las Release Templates que os mostré hace un momento, qué automatizaciones se ejecutan en cada servidor.

image

image

image

― Pero nuestros entornos de pre-producción  y producción ―dijo Arístides― están en una red externa. Aunque los demos de alta en la herramienta, ésta nunca podría conectarse con ellos para ejecutar los despliegues y validaciones.

― En realidad eso también está previsto. El sistema funciona con un modo pull, de modo que los Deployer que se ejecutan en cada servidor son los que se conectan con el servidor de Release Management, y no al revés. Si os gusta el cine, podríamos decir que se ciñen al principio Hollywood: «don’t call us, we’ll call you». Periódicamente consultan si hay algo que desplegar y validar, y si reciben una respuesta afirmativa del servidor, proceden a ejecutar el workflow definido en la Release Template para el stage correspondiente. De este modo no hay que abrir puertos en las máquinas destino, que suelen estar en entornos con restricciones de seguridad mucho más críticas. La comunicación se realiza por HTTP, ó por HTTPS si es que necesitamos encriptación.

― Pero hay algo que no me queda claro ―intervino Manolo, casi pensando en alto. Si todo está tan automatizado, ¿cómo sabe cada deployer qué versión de la aplicación tiene que desplegar y validar, y de dónde obtenerla? Sin ir más lejos, en la penúltima entrega la liamos parda. Nos confundimos con la carpeta donde dejamos los binarios, porque tenemos todo el histórico de entregas del proyecto almacenado en distintas carpetas. Acabamos saliendo a producción con una versión antigua, con montones de errores de regresión y menos funcionalidad.

― Y lo que es peor ―confirmó Arístides―, nos dimos cuenta varios días después, cuando un cliente se quejó de que le estaba volviendo a aparecer un bug que él ya había notificado hace semanas, y nosotros solucionado. Y entre nosotros, esperemos que Armando no se entere nunca, o nos descontará del sueldo todo el dinero perdido durante los días que parte de la funcionalidad no estuvo accesible en producción.

Los demás miembros del equipo miraron a Arístides con los ojos como platos, como a punto de estrangularle para que cerrase la boca. Mamen se limitó a fruncir los labios y levantar las cejas, antes de proseguir con sus recomendaciones:

― En fin, eso también tiene fácil solución. Para cada Release Path podéis especificar de dónde se obtienen los binarios y otros elementos a desplegar, así no hay confusión posible. Incluso puede ser el resultado de una construcción automatizada de TFS, con lo que la posibilidad de error es ínfima.

― Ah, pues ya puestos ―sugirió Manolo― sería prodigioso si la misma construcción automatizada desencadenase todo el proceso definido en la Release Path ¿no? Sería lo más grande desde que sacaron el Duke Nukem Forever. Nos podríamos librar para siempre de los pesaos de sistemas― dijo a la vez que soltaba una carcajada y un codazo a Asier en la boca del estómago, que le dejó veinte segundos sin respiración.

Mamen negó con la cabeza, como dudando de que algunos estuviesen escuchando nada de lo que había estado diciendo.

― Creo que ya hemos dejado claro que nunca podremos hacer entregas de forma óptima si no colaboramos de forma cotidiana los de sistemas y los de desarrollo. Pero en fin, respondiendo a tu pregunta, sí, sería sumamente útil. Por eso ya han pensado en ello y también lo tienes disponible.

Cambió un momento a Visual Studio y les mostró a todos la nueva plantilla de construcciones automatizadas desde la que es posible desencadenar todo el proceso de entrega de forma automática.

image

Llegados a ese punto, todos se quedaron un momento callados, pensativos. Parecía que empezaban a darse cuenta de todas las posibilidades que les ofrecía aquella forma de trabajar y el hecho de soportarla en una herramienta como Visual Studio Release Management. Concha rompió de repente el silencio y planteó una duda:

― ¿Tendríamos que desplegar siempre toda la aplicación en bloque? Estoy pensando que la mayoría de nuestros cambios afectan sólo al front-end web o a los clientes móviles. A estas alturas del proyecto, es mucho menos frecuente que tengamos que meter mano a los servicios o a la base de datos. De hecho, como ahora no tenemos trazabilidad de lo que se ha cambiado en una versión,  acabamos desplegando siempre todos los componentes por si acaso. Y más de una vez nos ha provocado problemas, aparte de la pérdida de tiempo que supone.

― Podéis configurar los componentes de los que consta vuestra aplicación ―respondió Mamen―. Para cada componente podéis definir un Release Path distinto. O podéis configurar un Release Path que gestione varios componentes. Para cada uno indicáis de dónde se obtiene, por ejemplo de una construcción automatizada como os decía antes. O de una ruta de red, lo cual podría ser útil por ejemplo si es un componente que no desarrolláis vosotros.

image

Además, como veis cada componente tiene una sección llamada Configuration Variables donde puedo definir variables de configuración asociadas. Esto es muy útil; si tengo un sitio web, puedo indicar que la URL de los servicios que usa va a cambiar en cada entorno. O si tengo un servicio web, podría tener como variable de configuración la cadena de conexión a la base de datos. La herramienta se encargará de sustituir la variable por el valor correcto para cada entorno, en el momento del despliegue.

― Y todo este proceso, ¿se puede ir siguiendo de alguna forma? ―preguntó Arístides― ¿Puedo ver en qué punto está, si ha fallado algo…?

― ¿… si hay aprobaciones o validaciones pendientes, qué pasos concretos se han ejecutado en cada servidor y con qué parámetros…? ―continuó Mamen, completando la pregunta de Arístides― Por supuesto, tienes monitorización del proceso, logs de ejecución, alertas y todo tipo de información útil.

image

image

Y la mayoría no sólo está disponible usando la aplicación cliente de Release Management, sino que además dispones de un cliente web desde el que se puede consultar sin necesidad de instalar nada.

image

― Oye Mamen ―interrumpió Manolo― ya que parece que tienes respuesta para todo, ¿puedes decirme cuándo vamos a parar para hacer un descanso? Esperaba que la reunión fuese más corta, y tengo más hambre ya que el perro de Chocapic.

― Sí, ya termino… por supuesto que hay muchas más cosas que contar, pero creo que me vais a ver mucho por aquí los próximos días. Armando me ha pedido que os ayude con todo esto para que la próxima entrega no sea otra catástrofe. Por ahora, os voy a pedir que descarguéis la máquina virtual de evaluación de TFS, que viene con Visual Studio Release Management instalado y configurado. Y que echéis un vistazo al lab que hay disponible para empezar a familiarizaros con la herramienta. O a un tutorial más corto si no tenéis mucho tiempo disponible. Si tenéis dudas avisadme, pero quizá podáis solventarlas en la web de la herramienta.

Unas semanas más tarde, Armando Broncas, el gerente, había quedado para comer con Unai Nomás, el director de proyectos. Desde el principio Armando tenía muy claro cuál iba a ser el tema de conversación principal, y no tardó en confirmar sus sospechas. Justo después de que el camarero hubo tomado nota, Unai fue directamente al grano:

― Bueno, ¿cómo ha ido la entrega de nuestro equipo de élite? ―dijo, mientras añadía unas comillas virtuales con un gesto de sus dedos a la última palabra― ¿Tengo que ir preparando los finiquitos? Al menos parece que si algo ha ido mal, no han causado tanto revuelo como de costumbre ¿no?

Armando vaciló un momento, como buscando las palabras adecuadas.

― Si te soy sincero, la entrega ha sido un completo desastre. Una vez más.

― ¿Pero no asignamos a Mamen, sacándola de un proyecto más crítico, para ayudarles? ―gritó Unai, casi atragantándose con el sorbo de buen vino que acababa de tomar―. ¿No les hemos proporcionado también la herramienta de Release Management? ¿Por qué siguen cagándola sistemáticamente en las salidas a producción?

― La verdad es que, lo que es la salida de producción, ha ido como la seda. Ningún problema en ese sentido. Y la nueva versión estuvo disponible en tiempo récord.

― ¿Entonces qué narices ha ocurrido esta vez?

― Digamos simplemente que no entendieron las especificaciones. Y han entregado algo completamente distinto a lo que se esperaba. Pero ésa es otra historia, y me temo que ninguna herramienta va a poder ayudarnos.

Por un momento, sin darse cuenta de que el camarero gesticulaba pidiéndoles permiso para servirles los primeros platos, se escrutaron con la mirada el uno al otro, en silencio, sintiéndose completamente superados por todo aquel asunto.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *