Get your binaries versioned automatically in less than 5 minutes with TFS Build 2013

By now, we all agree that we should be versioning everything, aren’t we? For software we are delivering to production, it is the easiest way to assure that we can always determine without any doubt which source code was used to build any of the binaries being run. Fixes to production binaries should be applied over the code first used to generate them and released from there; otherwise we can be delivering not only the fix, but also half-baked features, yet-to-discover bugs and all sort of unfinished items.

The default build template in TFS 2013 has a nice new feature that allows us to run scripts (PowerShell or batch files) before or after the actual build is performed. This is useful in so many ways, and one of them is to version the assemblies being generated by preparing a script that embeds the proper version number into the AssemblyInfo.* files prior to having them built.

Fortunately, the folks maintaining the Community TFS Build Extensions have already prepared such a script for us. The script not only modifies the AssemblyInfo.* files for us, but also gets the version number to be applied from the build number. This is great because by default, each build being triggered in TFS labels the source code with the build number. And this means that we will be able to pick any assembly and trace it back to the source code that generated it by that label.

So the work of having a build definition update the version number automatically for the generated assemblies and label the code accordingly, now takes less than the time you’ll spend in reading this post:

  1. Download the Community TFS Build Extensions which include the ApplyVersionToAssemblies.ps1 script (after unzipping the package, look for it inside the Scripts subfolder.) Check-in the script somewhere into your source control.1
  2. Edit or create a TFS build definition based in the 2013 default template. Inside the Build – Advanced section of the build process parameters, you’ll find that you can specify scripts to be run before or after the actual building operation takes place. For the Pre-build script path parameter, specify the path in the source control where you uploaded the ApplyVersionToAssemblies.ps1 script.2
  3. Change the Build number format parameter so it contains a substring that can be parsed to a version number in the form Major.Minor.Build.Revision (the actual regular expression being used for parsing it is d+.d+.d+.d+) It can be anything that suits your versioning scheme; in the example below I’m just forcing everything but the revision number, which will be automatically incremented each time you trigger a build for this definition. But you can use any other scheme (for example something adhering to semantic versioning,) and take advantage of some of the provided macros.3
  4. That’s all! The next time you trigger a build, the generated binaries should have the corresponding version number embedded in them.4

Now you’ve got no excuses! Go and set up versioning for your builds before it is too late.

Configura el versionado automático de tus binarios en menos de 5 minutos con TFS Build 2013

A estas alturas, estamos de acuerdo en que deberíamos versionar todo, ¿no es así? Para software que despleguemos en producción, es la forma más fácil de asegurar que siempre podremos determinar sin lugar a dudas el código fuente que fue usado para construir cualquiera de los binarios que se están ejecutando. Las correcciones sobre los binarios de producción deberían aplicarse sobre el código que se utilizó para generarlos; de otro modo, podríamos estar distribuyendo no sólo la corrección, sino otras características a medio hacer, nuevos bugs aun no descubiertos y todo tipo de elementos no finalizados.

La planitlla de build por defecto en TFS 2013 tiene una nueva característica muy interesante que nos permite ejecutar scripts (PowerShell o batch files) antes o después de que la operación de build se lleve a cabo. Esto puede ser útil en muchos escenarios, y uno de ellos es versionar los ensamblados que se generan, preparando un script que incruste el número de versión adecuado en los ficheros AssemblyInfo.* antes de que sean construidos.

Afortunadamente, los amigos que mantienen las Community TFS Build Extensions ya han preparado un script así para nosotros. Este script no sólo modifica los ficheros AssemblyInfo.*, sino que además obtiene del build number el número de versión a aplicar. Esto es muy conveniente porque, por defecto, cada build lanzada en TFS etiqueta el código fuente con el build number. Y esto quiere decir que seremos capaces de coger cualquier ensamblado y trazarlo hasta el código fuente que lo generó, mediante esa etiqueta.

Por lo tanto, el trabajo de hacer que una definición de build actualice el número de versión automáticamente para los ensamblados generados y que ponga la etiqueta correspondiente en el control de versiones, ahora lleva menos tiempo del que vas a emplear en leer este post:

  1. Descarga las Community TFS Build Extensions, las cuales incluyen el script ApplyVersionToAssemblies.ps1 (al descomprimir el paquete, búscalo en la carpeta Scripts). Sube y protege (check-in) el script en alguna ruta de tu control de versiones.1_thumb[1]
  2. Edita o crea una definición de build de TFS basada en la versión 2013 de la plantilla por defecto. En la sección Build – Advanced de los parámetros del proceso de build, verás que puedes especificar scripts que serán ejecutados antes o después de la operación de build propiamente dicha. Para el parámetro Pre-build script path, especifica la ruta en el control de versiones donde subiste el script ApplyVersionToAssemblies.ps1.2_thumb[1]
  3. Cambia el parámetro Build number format de modo que contenga una subcadena que pueda ser parseada a un número de versión de la forma Major.Minor.Build.Revision (la expresión regular que se usa para el parseo es d+.d+.d+.d+) Puede ser cualquier cosa que cuadre con tu esquema de versionado; en el ejemplo de abajo simplemente estoy forzando todo menos el número de revisión, que será incrementado automáticamente cada vez que se lance una build con esta definición. Pero puedes usar cualquier otro esquema (por ejemplo algo acorde con semantic versioning), y aprovechar las macros disponibles.3_thumb[1]
  4. ¡Eso es todo! La próxima vez que ejecutes una build, los binarios generados deberían llevar incrustado el correspondiente número de versión.4_thumb[1]

¡Ya no hay excusas! Ve y configura el versionado para tus builds antes de que sea demasiado tarde.

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.

Materiales del evento de lanzamiento de Visual Studio 2013 ALM

El pasado día 14 desde Plain Concepts organizamos un evento en Madrid para presentar todas las novedades de Visual Studio 2013 en relación a ALM. Fue una mañana en la que mi compañero Vicenç y yo tuvimos la oportunidad de compartir un buen rato con los asistentes y también con los que nos seguían a través de streaming.

Aquí tenéis las presentaciones correspondientes a mis sesiones y la grabación completa del evento para los que no tuvisteis la oportunidad de asistir.

Sobre Agile, Scrum y Kanban con TFS 2013:

 

Sobre gestión de la entrega con la nueva herramienta de Release Management de Visual Studio 2013:

 

Sobre monitorización, telemetría, recuperación de errores, análisis de rendimiento y profiling con Visual Studio 2013:

 
Y la grabación completa de todo el evento incluyendo las sesiones de Vicenç sobre herramientas de colaboración y pruebas:
 
 

Evento: novedades de Visual Studio y TFS 2013 en Madrid

Como ya sabréis el próximo miércoles 13 de noviembre es el lanzamiento mundial de la nueva versión de Visual Studio y herramientas asociadas, incluyendo Team Foundation Server. Se podrá seguir en directo desde http://events.visualstudio.com/.

Y justo al día siguiente, el jueves 14, desde Plain Concepts hemos preparado un evento en el que haremos un recorrido por todas las novedades relacionadas con la gestión del ciclo de vida (ALM). Y para los que no estéis en Madrid y/o no hayáis podido asistir en otras ciudades en las que hemos estado, estamos intentando que se retransmita todo en streaming.

Más información, agenda y registro en http://t.co/9AZVkO6E3w.

Nos vemos por allí!

ALM Moderno: Modernice la gestión del ciclo de vida de sus aplicaciones

Charles Darwin and Continuous Delivery

 

Charles Darwin published On the Origin of Species in 1859. It is somewhat remarkable that some of the theories enunciated in this work can be verified over 150 years later, in human knowledge fields such different from biology as software development.

In order to set the context of the subjects discussed below, and before addressing how are we are affected by Darwin’s statements, let’s take a little trip, visiting some of the most successful Internet companies, whose websites have astronomical numbers of users, millions of pages served per day, and countless amounts of completed transactions.

 

The voyage aboard the Beagle

What is dangerous is not to evolve – Jeff Bezos, CEO & President of Amazon.com

Darwin embarked on a journey of nearly five years aboard the HMS Beagle, which allowed him to study many animal species and to obtain valuable information to support the theories that later showed in his work. It’s much easier for us to study the species that we are interested in, since we only need a few glimpses to some content that can be found online, publicly available.

We are going to start at Seattle, where a small online bookstore founded in a garage back in the 90’s, has ended up becoming a global bazaar where you can buy anything from the mythical t-shirt of three wolves howling at the full moon (if you did not know about the product, I recommend you to read the customers’ evaluations), to genuine uranium.

Amazon serves 137 million customers per week and has an annual revenue of 34 billion dollars. If all of its active users came together in a country, it would have twice as many people as Canada. You can imagine that, with such amazing figures, introducing new features in the website should be something that they consider thoroughly, and that it would be something that they can’t afford to do so often because of the risk of bugs and unexpected errors showing up, which could lead to huge losses.

Right?

No. Nothing further from the truth. By 2011, Amazon was releasing changes in production every 11.6 seconds on average, involving up to 30,000 servers simultaneously. I’m lacking more recent numbers, but from the evolution of the business, anyone could work out that these figures must only have become even more striking.

The biggest risk is not taking any risk… In a world that changing really quickly, the only strategy that is guaranteed to fail is not taking risks. – Mark Zuckerberg, CEO & Chairman of Facebook

800 miles south, at Menlo Park (California), what began as a social experiment for a group of undergraduates, is serving more than one billion active users, who upload 250 million images a day and view one thousand billion pages per month. The figures are dizzying. The effect is so strong that even some parents have named their children Facebook, literally.

The source code for Facebook is compiled into a binary weighing 1.5 GB and is maintained by more than 500 developers. Stakes are high for each change and deployment. Anyone would expect that any change is made after thorough verification of a strict QA team, and never without the explicit approval from an horde of managers, armed to the teeth with the most inflexible bureaucracy.

Or maybe not?

In fact, whoever imagines it that way, is completely mistaken. Minor changes are released into production at least once a day, and a major version is deployed once a week. Almost all the code is modified directly on the main line; they don’t use branches to protect its integrity. Everyone does testing and can file bugs. Everything is automated to the maximum.

In 100 years people will look back on now and say, ‘That was the Internet Age.’ And computers will be seen as a mere ingredient to the Internet Age. – Reed Hastings, CEO of Netflix

Not far from there, also in California, NetFlix does business from a town called Los Gatos. It is the largest online service for movies and television shows, which are offered by streaming to its subscribers, who sum more than 25 million.

NetFlix services receive frequent attacks that put them at risk, and even lead to failures in specific nodes, making it necessary to perform interventions in order to prevent further problems. So far, it’s not that different from any other big company providing Internet services. What makes it extraordinary in the case of NetFlix, is that most of these attacks are caused… by themselves!

How can it be possible? Have they gone nuts? Are there disgruntled employees trying to sabotage the company from within?

Not really. These attacks are perfectly orchestrated by the Simian Army, the horde of little nuisances developed by Netflix to push the boundaries of their own infrastructure and applications. The Chaos Monkey randomly disables instances to ensure that they can survive this type of failure. The Latency Monkey simulates delays and loss of connectivity. The Conformity Monkey shuts down instances not adhering to a defined set of best practices, immediately and without remorse. And so on… there’s even a Chaos Gorilla, the Chaos Monkey’s bodyguard, who causes an outage across the entire cloud availability zone where it monkeys around. The consequence is that, when these problems occur unexpectedly, all their systems are already prepared to deal with them, since the team has been able to test the procedures, and the code has already been modified to mitigate the consequences. If it sounds interesting for you, you can even take a look at how it is implemented.

In this business, by the time you realize you’re in trouble, it’s too late to save yourself. Unless you’re running scared all the time, you’re gone. – Bill Gates, Co-fundador de Microsoft

Now we return to our first stop, Seattle. Nearby, at Redmond, Team Foundation Service Team serves many other development teams worldwide, providing a tool to support the complete application lifecycle: planning, collaboration, version control, testing, automated builds, etc. With a worldwide-distributed user base, working in all time zones, availability is critical; anyone working in software development knows about the hassle of losing access to version control or not being able to use the build server. The usual approach in these cases, is to focus on a stable set of features, that allows to provide an adequate service to the users, and with minimum changes over time; that way they can guarantee that the availability of the service is not affected by defects introduced by the release of new features.

Do you agree with this approach?

They don’t! The trend since the product launch has been to introduce new features continuously, with a cadence of about three weeks. And we’re not talking about minor or cosmetic changes; those updates have included such important features as automated deployment to Azure, Git integration, or customizable Kanban boards. The few service outages so far have been mostly predictable, and for many of them the user has been alerted so she could be prepared.

Just the same way as Darwin did aboard the Beagle, we could indefinitely continue with our journey in search of peculiar species, in search of many other organizations working in a way that seems to defy common sense and established rules:

  • Flickr deploys ​​several times a day, and until recently, they reported on their website on the time of the last deployment, and how many changes were included in it.
  • At Spotify, where they maintain over 100 different systems between clients, backend services, components, etc., any of the 250 developers is authorized to modify any of these systems directly if it is needed in order to implement a feature.
  • Etsy experiments with new features directly into production, a technique known as A / B testing, to identify those changes that attract more interest from customers.

What conclusions can be drawn at the light of all this information?

Are they all gone completely mad?

Or are we discovering a new way to do work, that breaks with many of the preconceived ideas considered valid so far in software development?

For example, it may seem counter-intuitive to think that the more deployments you do, the less problems you’ll have while deploying. We’ve all had that fateful release on a Friday (you know, if it’s not on Friday, you can’t call it a real deployment…), which forced us to spend all weekend struggling to put the fuc#$@& application up. And the natural reaction is to avoid doing more deployments with all our strength, and postpone it as much as possible, because we know that it will hurt again. After all, if there are many more attempts, it is also much more likely to fail, isn’t it?

Well, usually not. In fact, the effect is that repetition leads to more predictable and controllable deployments, with less uncertainty and much smaller and manageable issues. The underlying philosophy is that if something hurts, rather than avoid it, you should do it more often, and that way you’ll make the pain more bearable. Or putting it another way, it is more acceptable a succession of small pains, than a large, concentrated traumatic pain.

Is it feasible that any single developer has the power to release any changes she deems ready to deliver? Yes, if that change is subjected to a verification process that ensures that it will not break anything once it has been released.

Is it reckless to remove from this verification process a whole chain of bureaucracy, requests, approvals, meetings between departments and a comprehensive control of the process by adequately trained roles?

It is not reckless, as long as all or most of these verifications have been coded and are run in the form of acceptance, regression and smoke automated tests, and unattended deployments, and with the ability of checking the status of all the process in an easy way. Not only it is not reckless, but it will far exceed the reliability of a group of humans doing the same process manually (or even worse, a random variation of it), often in a state of boredom and under a poor concentration. I am not talking about completely eliminating manual steps, which is usually impossible: at least there will be a manual first run of acceptance tests for the user to verify that the development team has understood whatever was intended to be addressed with the particular requirement. Or there might be some special device in our environment for which we can not set up a fully automated deployment. But we always can deal with the rest of our process, and aim to reduce these manual steps as much as possible.

Continuous Delivery is a discipline, a way to work, or a set of patterns and practices, that bears in mind all these factors and takes advantage of them to the maximum. We’re going to rely on techniques such as test automation and deployment, continuous integration, transparency and visibility throughout the entire process, the detailed scrutiny of all dependencies and configuration parameters that affect the delivery of our software, the detection and early addressing of problematic changes, and many others, to enable the possibility that any slight change in our code, committed to version control, is a candidate to be released as soon as possible, and indeed it will, if nothing makes us (automatically) discard it along the way.

It is not only about continuous deployment, as many mistakenly assume, as you can be deploying crap and still do it automatically and continuously. Nor is it just continuous automated testing. It is comprised of these practices but also of many others; all of those which are needed to be confident when assuring that a change is ready for use and the user can benefit from it.

Of course, for this to be successful, close collaboration between whoever is involved is needed, in an environment where barriers and departmental silos have been removed. It is something that movements like DevOps are also addressing.

What is the benefit?

If we stick to the results, the figures from these companies, we could say that the benefit is huge. But in order to avoid falling into the ’Correlation implies Causation’ fallacy, we should be more specific and focus on the context of the software development process.What we find then is:

  • A transparent and predictable delivery process. For each change, we always go through the same sequence of steps, and these are automated as far as possible. No surprises.
  • Fewer defects in production. The defects appear and are addressed in earlier stages, even automatically. The standardized delivery process prevents any of these defects from ending up in production because of a misunderstanding, or because of the work being done in a different way. It also provides traceability of the origin of these problems.
  • Flexibility to undertake changes. Changes are addressed in smaller, more manageable pieces. They are implemented and delivered promptly.
  • Immediate and useful feedback about changes, even from the production environment: whether they are running smoothly, how are users accepting them, or the impact on the business.
  • Less time required to deploy and release into production, since everything has been automated as much as possible.
  • Empowered teams, motivated by the confidence that has been put in them, and the continued feeling of delivering increments of tangible value.

All of this sounds great, but it’s not for me

The adoption of Continuous Delivery practices can be worth it, even if you do not need or do not want to release your software so frequently. Overall, the aforementioned benefits should be the same, so any team willing to improve could consider adopting this approach.

There are very special cases where Continuous Delivery might not be the best option, or even be counterproductive. I, for one, have found very few of them. Most times, these are scenarios where the effort to adopt the practices will not justify the results: legacy systems, outdated technologies, lack of adequate tools to set up the environment, designs not prepared for automation or testing, etc.

But the real problem, which unfortunately appears quite often, comes when the team or the organization itself does not adopt an open attitude to change and improvements. We could say that deep inside, even unconsciously, they do not want a transparent delivery process, they don’t need fewer defects in production, or they don’t want flexibility to cope with changes. Externally this manifests itself as the decision of not to invest in the necessary improvements. The most common example is the typical argument of the kind ‘our case is very unusual,’ ‘our system is very complex,’ ‘we deal with a very delicate business,’ ‘our users are very special,’ ‘my boss would never let me,’ ‘my mom won’t let me’ or ‘insert your favorite excuse here.’ Among these, it is quite frequent to hear ‘we can’t afford to invest in it,’ when in fact, as we will see in a moment, is thatvwhat for sure you can’t afford is not to invest in it.

Is your system bigger than Team Foundation Service?

Do you deal with a more complex business than Amazon?

Are your users more demanding than those from Facebook? Do they have more special requirements?

Do you have to serve a bigger volume of data than NetFlix?

If you’re among the vast majority, those who would respond negatively to these questions, chances are that you are just feeling lazy about addressing the transition to a Continuous Delivery model. In that case, my advice is to be careful, because your organization can suffer the same fate as the dodo or the thylacine.

Natural selection

We had left Darwin aboard the Beagle, sailing the seven seas in search of unique species. At the end of his voyage, he felt perplexed about the variety of wildlife and fossils he had found, so he began an investigation that led him to enunciate the theory of natural selection in his book «On the Origin of Species».

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.

In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed.

Charles Darwin, English naturalist

Natural selection states that those members of a population which have the characteristics that are better adapted to their environment, are more likely to survive. What about the others? Well, sooner or later they’ll end up disappearing.

It is a law that applies to living organisms, but if you think about it for a moment, what is an organization but a big living organism? Of course natural selection applies to companies and organizations, as any list of extinct companies demonstrates.

In the constantly changing environment in which most businesses operate, it is no longer enough to offer nice and cheap products. You have to deliver them sooner, and evolve them quickly in response to the demands of the users. Keeping track of metrics such as team velocity or defect rate is insufficient. The metrics that are making a difference between those who succeed and those who get stuck on the way are others:

  • Cycle time: the time elapsed on average since we start working on a feature, until we have it released in production.
  • Mean time to failure (MTTF): how long it takes, on average, for my system to suffer from a big issue or an outage.
  • Mean time to recover (MTTR): how long it takes, on average, for my system to be fully functional again after a big problem or an outage.

Natural selection will favor those who are able to hold these values as small as possible, and this is exactly one of the areas where Continuous Delivery can help better.

OK, I don’t want to become extinct. Where should I start?

Throughout this article we have focused on showing the benefits of Continuous Delivery and what could happen if we ignore it. But we have not covered in any depth how to implement it, and given the large number of patterns and practices to consider, it can end up being a process that is far from trivial.

Undoubtedly, there is a cultural side, which will demand from us to work within our organization to remove barriers and silos, and improve collaboration as much as possible.

There are lots of available resources that can help us to get started, but without any doubt the most valuable one is the excellent book by Jez Humble and David Farley, Continuous Delivery.

If your environment is based on Microsoft technologies, fortunately we have great tools available that can support most of the aforementioned practices. Visual Studio and Team Foundation Server, and related tools, will help us to implement the whole Continuous Delivery ‘pipeline’, from automating all kinds of testing and deployment, to more specific topics such as static code analysis or continuous integration. It is true that these tools require customization work and some tweaking in order to be suited for the model we are proposing, but here at Plain Concepts we can help you to prepare the environment that best suits your project; it’s something that we’ve done before for many organizations, and seems that still none of them have become extinct.

Also, if you want to get an overall idea about how Team Foundation Server can be customized in order to support Continuous Delivery, you can have a look at my presentation on this topic at ALM Summit 3.

And if you can afford to wait a bit longer, right now I’m working with the Microsoft Patterns & Practices team in a new book about the subject that will be available in a few months, where we will cover in depth whatever is needed to put these ideas into practice in an effective way. More news about it very soon!

Charles Darwin y la Entrega Continua

 

Charles Darwin publicó El Origen de las Especies en 1859. No deja de ser admirable que algunas de las teorías que enunció en esta obra se pueden verificar más de 150 años después, en campos del conocimiento humano tan dispares a la biología como puede ser el desarrollo de software.

Para establecer el contexto de los temas que veremos a continuación, antes de abordar cómo nos afectan los enunciados de Darwin, vamos a hacer un pequeño viaje, en el que visitaremos algunas de las empresas más exitosas de Internet, cuyas webs cuentan con cifras astronómicas de usuarios, millones de páginas servidas al día, e incontables cantidades de transacciones completadas.

 

El viaje del Beagle

Lo peligroso es no evolucionar – Jeff Bezos, CEO & Presidente de Amazon.com

Darwin se embarcó en un viaje de casi cinco años a bordo del buque HMS Beagle, que le permitió estudiar multitud de especies animales y obtener información valiosa para soportar las teorías que posteriormente reflejó en su obra. Para estudiar las especies que nos interesan a nosotros, lo tenemos mucho más fácil, pues nos basta con un par de vistazos a algunos contenidos que podemos encontrar en la red, disponibles públicamente.

Empezamos en Seattle, donde una pequeña librería online fundada en un garaje en los años 90, ha acabado convirtiéndose un bazar global donde se puede comprar desde la mítica camiseta de los tres lobos aullando a la luna llena (si no conocías el producto, te recomiendo que leas las evaluaciones de los clientes), a verdadero uranio.

Amazon sirve a 137 millones de clientes por semana y tiene unos beneficios de 34.000 millones de dólares anuales. Si todos sus usuarios activos se juntasen en un país, éste tendría el doble de habitantes que Canadá. Os podéis imaginar que con semejantes cifras, introducir nuevas funcionalidades en el sitio web debe ser algo que se piensen muy mucho, y no se puedan permitir hacer con demasiada frecuencia por el riesgo de aparición de bugs y errores inesperados, que podrían conllevar pérdidas millonarias.

¿Correcto?

No. Nada más lejos de la realidad. En 2011 Amazon estaba liberando cambios en producción cada 11,6 segundos de media, que podían estar afectando hasta a 30.000 servidores a la vez. No dispongo de datos más actualizados, pero por la evolución del negocio, todo hace pensar que estas cifras no habrán hecho más que volverse aún más sorprendentes.

El mayor riesgo es no asumir ningún riesgo… En un mundo que está cambiando realmente rápido, la única estrategia con garantías de fallar es no asumir riesgos. – Mark Zuckerberg, CEO & Chairman de Facebook

1.300 kilómetros al sur, en Menlo Park (California), lo que empezó como el experimento social de un grupo de universitarios, está dando servicio a más de mil millones de usuarios activos, que suben 250 millones de imágenes al día y consultan un billón de páginas al mes. Las cifras que se manejan son simplemente mareantes. La repercusión es tal que incluso hay padres que ponen a sus hijos el nombre de Facebook, literalmente.

El código fuente de Facebook es compilado en un binario que pesa 1,5 GB y es mantenido por más de 500 desarrolladores. En cada modificación y despliegue, hay mucho en juego. Es de esperar que cualquier cambio se haga tras la verificación exhaustiva de un estricto equipo de QA, y nunca sin la aprobación expresa de un ejército de gerentes armados hasta los dientes con la más inflexible burocracia.

¿O quizás no?

La verdad es que, el que se lo imagine así, está muy equivocado. Se sale a producción un mínimo de una vez al día con cambios menores, y una vez a la semana se despliega una versión mayor. Casi todo el código se modifica directamente sobre la línea principal; no usan ramas para proteger la estabilidad de la misma. Todo el mundo hace pruebas y puede reportar defectos. Todo está automatizado al máximo.

En 100 años, la gente echará la vista atrás y dirá: “Eso fue la Era de Internet”. Y los ordenadores se verán como simples ingredientes de esta Era de Internet. – Reed Hastings, CEO de Netflix

No muy lejos de allí, desde un pueblo de California llamado Los Gatos, opera NetFlix. Se trata del mayor servicio de películas y series de televisión online ofrecidas por streaming a sus suscriptores, que suman más de 25 millones.

Los servicios de NetFlix reciben de forma frecuente ataques que hacen peligrar el correcto funcionamiento de los mismos, e incluso provocan caídas en nodos concretos que hacen necesarias intervenciones para evitar problemas mayores. Hasta aquí no es diferente de cualquier otra gran empresa que proporcione servicios en Internet. Lo particular del caso de NetFlix es que gran parte de estos ataques están provocados… ¡por ellos mismos!

¿Cómo es posible? ¿Han perdido la cabeza? ¿Hay empleados descontentos intentando sabotear la compañía desde dentro?

En realidad no. Los ataques están perfectamente orquestados por la Simian Army, el ejército de pequeños incordios desarrollado por NetFlix para llevar al límite su propia infraestructura y aplicaciones. El Chaos Monkey se ocupa de deshabilitar instancias aleatoriamente para asegurarse de que se puede sobrevivir a este tipo de fallo. El Latency Monkey simula retardos y pérdida de conectividad. El Conformity Monkey cierra instancias que no cumplen un conjunto definido de buenas prácticas, directamente y sin mayores contemplaciones. Y así sucesivamente… incluso hay un Chaos Gorilla, el primo de zumosol del Chaos Monkey, que corta de un plumazo el servicio en toda la zona de disponibilidad de la nube en la que desempeña sus monerías. El resultado es que cuando este tipo de problemas aparecen de forma inesperada, todos sus sistemas y equipos ya están preparado para tratar con ellos, puesto que han podido ensayar los procedimientos y el código se ha protegido para mitigarlos. Si la idea te parece interesante, incluso puedes echar un vistazo a cómo está implementado.

En este negocio, para cuando te has dado cuenta de que tienes problemas, ya es demasiado tarde para salvarte. A no ser que te estés preocupando continuamente, estás acabado. – Bill Gates, Co-fundador de Microsoft

Volvemos a nuestra primera parada, Seattle. Justo al lado, en Redmond, el equipo de Team Foundation Service da servicio a muchos otros equipos de desarrollo a nivel mundial, proporcionando una herramienta completa para dar soporte al ciclo de vida de las aplicaciones: planificación, colaboración, control de versiones, ejecución de pruebas, construcciones automatizadas, etc. Con una base de usuarios a nivel mundial, trabajando en todas las zonas horarias, los requisitos de disponibilidad son críticos; todos los que trabajamos en desarrollo de software sabemos el fastidio que supone quedarse sin acceso al control de versiones o que el servidor de construcciones automatizadas no esté disponible. El enfoque usual en estos casos es centrarse en una base estable de características que permitan dar un servicio adecuado a los usuarios y que cambien poco en el tiempo, de esa forma garantizamos que la disponibilidad del servicio no se ve afectada por defectos derivados de la introducción de características nuevas.

¿Estás de acuerdo con este enfoque?

¡Pues ellos no! La tendencia desde el lanzamiento del producto ha sido la de introducir nuevas funcionalidades de forma continua, con cadencias de aproximadamente tres semanas. Y no estamos hablando de cambios menores o estéticos; en esas actualizaciones han entrado características de tanta entidad como el despliegue automatizado a Azure, la integración con Git, o la personalización de tableros Kanban. Las mínimas caídas de servicio acontecidas hasta la fecha han sido en su mayoría previsibles, y en muchas de ellas el usuario es alertado para que pueda estar listo.

De la misma forma que hizo Darwin a bordo del Beagle, podríamos seguir indefinidamente con nuestro periplo en busca de especies peculiares, de otras muchas organizaciones que usan un modo de trabajo que parece desafiar el sentido común o las reglas establecidas:

  • Flickr realiza varios despliegues al día, y hasta hace poco informaba en su web de la hora del último despliegue, y de cuántos cambios había incluido.
  • En Spotify, donde se mantienen más de 100 sistemas distintos entre clientes, servicios de backend, componentes, etc., cualquiera de los 250 desarrolladores está autorizado a modificar cualquiera de estos sistemas directamente si lo necesita para implementar una característica.
  • Etsy experimenta con características nuevas directamente en producción, una técnica conocida como A/B testing, para identificar aquellos cambios que atraen un mayor interés de los clientes.

¿Qué conclusiones podemos sacar a la vista de toda esta información?

¿Se han vuelto todos completamente locos?

¿O estamos ante un nuevo modelo de trabajo, que rompe con muchas de las ideas que considerábamos válidas hasta ahora en desarrollo de software?

Por ejemplo, puede parecer anti-intuitivo pensar que hacer más despliegues te lleve a tener menos problemas al desplegar. Todos hemos tenido esa salida a producción fatídica un viernes (ya se sabe que si no es en viernes, no es un verdadero despliegue…), que nos ha obligado a estar todo el fin de semana luchando para poner la jod$#@ aplicación en marcha. Y la reacción natural es resistirse a volver a desplegar con todas nuestras fuerzas, demorarlo al máximo, ya que sabemos que nos va a doler otra vez. Al fin y al cabo, al haber muchos más intentos, hay también muchas más posibilidades de fallar ¿no es así?

Pues por lo general no. En realidad, el efecto es que la repetición nos lleva a que los despliegues son más predecibles, más controlados, con menos incertidumbre y con problemas mucho más pequeños y controlables. La filosofía subyacente es que si algo duele, en lugar de evitarlo deberías hacerlo más frecuentemente, y así harás el dolor más llevadero. O dicho de otra forma, es más asumible una sucesión de dolores pequeños que un gran dolor traumático concentrado.

¿Es viable que cualquier simple desarrollador tenga el poder de poner en producción cualquier cambio que él considere listo para entregar? Sí, si dicho cambio es sometido a todo un proceso de verificación que asegura que no se va a romper nada si lo liberamos.

¿Es imprudente eliminar de ese proceso de verificación toda una cadena de burocracia, solicitudes, aprobaciones, reuniones entre departamentos y control exhaustivo del proceso por parte de los roles adecuadamente capacitados?

No es para nada imprudente, si todas o la mayoría de esas verificaciones han sido codificadas y se ejecutan en la forma de pruebas de aceptación, de regresión y de humo automatizadas, de despliegues desatendidos, y con la posibilidad de visualizar fácilmente el estado de todo el proceso. No sólo no es imprudente, sino que va a superar con creces la fiabilidad de un grupo de humanos que hagan el mismo proceso (o lo que es peor, una variación aleatoria del mismo) de forma manual, muchas veces en un estado de aburrimiento absoluto y con la concentración bajo mínimos. No me estoy refiriendo a eliminar por completo los pasos manuales, lo cual es por lo general imposible: al menos habrá una primera ejecución manual de las pruebas de aceptación para que el usuario pueda verificar si el equipo de desarrollo ha entendido bien lo que se pretendía conseguir con el requisito concreto. O quizá pueda haber algún dispositivo especial en nuestro entorno para el que no podamos configurar un despliegue totalmente automatizado. Pero sí podemos abordar el resto de nuestro proceso, y tender a minimizar estos pasos manuales en la medida de lo posible.

La Entrega Continua (Continuous Delivery) es una disciplina, un modo de trabajo, o un conjunto de patrones y prácticas, que tiene en cuenta todos estos factores posibles de optimización y los explota al máximo. Nos vamos a basar en técnicas como la automatización de las pruebas y despliegues, la integración continua, la transparencia y visibilidad a lo largo de todo el proceso, el control exhaustivo de todas las dependencias y parámetros de configuración que afectan a la entrega de nuestro software, la detección y tratamiento temprano de cambios problemáticos, y otras muchas, para habilitar la posibilidad de que cualquier mínimo cambio en nuestro código, que se suba al control de versiones, sea candidato a acabar en producción en el mínimo tiempo posible, y de hecho acabe allí si nada nos hace desecharlo (a ser posible automáticamente) en el transcurso todo este proceso.

No se trata tan sólo de despliegue continuo, como muchos erróneamente asumen, ya que puedes estar desplegando basura y aun así hacerlo de forma automatizada continuamente. Tampoco se trata sólo de pruebas automatizadas continuas. Se trata de esas prácticas pero también de otras muchas más; todas aquellas que necesitemos para poder afirmar con garantías que un cambio está listo para que el usuario lo utilice y pueda sacar provecho de su uso.

Por supuesto, para que esto tenga éxito es necesaria una colaboración estrecha entre todos los involucrados, y un entorno en el que se han eliminado barreras y silos departamentales. Algo muy relacionado con lo que movimientos como DevOps se están ocupando de promulgar.

¿Qué ganamos con todo esto?

Si nos guiamos por las cifras que manejan las empresas que trabajan así, podríamos decir directamente que mucho. Pero para evitar caer en la falacia de “correlación implica causalidad”, habría que concretar más, y enfocarnos en el contexto del proceso de desarrollo de software. Lo que nos encontramos entonces es:

  • Un proceso de entrega transparente y predecible. Para todo cambio siempre pasamos por la misma secuencia de pasos, y éstos están automatizados en la medida de lo posible. No hay sorpresas.
  • Menos defectos en producción. Los defectos aparecen y son abordados en fases más tempranas, incluso de forma automática. El proceso de entrega estandarizado evita que ninguno de estos defectos pueda acabar en producción por un malentendido o por formas distintas de hacer las cosas. Además nos aporta trazabilidad sobre el origen de estos problemas.
  • Flexibilidad para asumir cambios. Los cambios se abordan en trozos más pequeños y manejables, se implementan y se entregan lo antes posible.
  • Información más inmediata y útil acerca de los cambios, incluso en el propio entorno de producción: si están funcionando sin problemas, cómo son acogidos por los usuarios o cómo afectan al negocio.
  • Menos tiempo empleado para desplegar y liberar en producción, ya que tenemos todo automatizado al máximo.
  • Equipos motivados por la confianza depositada en ellos y la sensación continuada de estar contribuyendo con incrementos de valor tangibles.

Todo esto suena muy bien, pero no es para mí

La adopción del tipo de prácticas que propone la Entrega Continua puede ser interesante incluso si no necesitamos o si no queremos salir a producción de forma tan frecuente. Los beneficios enumerados en general serán los mismos, por lo que cualquier equipo con afán de mejorar podría plantearse seguir este modo de trabajo.

Hay casos muy especiales en los que la Entrega Continua podría no ser la mejor opción, o incluso sea contraproducente. Yo la verdad es que me he encontrado bien pocos. La mayoría de las ocasiones suelen ser escenarios en los que el esfuerzo de adoptar todas estas prácticas no va a justificar los resultados obtenidos: sistemas legados, tecnologías obsoletas, falta de herramientas adecuadas para montar el entorno necesario, diseños que no favorecen la automatización o las pruebas, etc.

Pero el verdadero problema, que además desafortunadamente suele aparecer con frecuencia, viene cuando el propio equipo o la organización no adoptan una actitud abierta al cambio y a posibles mejoras. Podríamos decir que en el fondo, de modo inconsciente, no quieren un proceso de entrega transparente, no necesitan menos defectos en producción o no buscan flexibilidad ante cambios. De cara al exterior esto se manifiesta como la decisión de que no quieren invertir en las mejoras necesarias. El ejemplo más común es el típico argumento del tipo “nuestro caso es muy singular”, “nuestro sistema es muy complejo”, “el negocio en el que nos movemos es muy delicado”, “nuestros usuarios son muy especiales”, “mi jefe nunca me dejaría”, “mi mamá no me deja” o “inserta tu excusa preferida aquí”. Es especialmente frecuente el de “no podemos permitirnos invertir en eso”, cuando en realidad, como veremos en un momento, lo que seguramente no te puedes permitir es dejar de invertir.

¿Es tu sistema más complejo que Team Foundation Service?

¿Te mueves en un negocio más complejo que Amazon?

¿Son tus usuarios más exigentes y con demandas más variadas que los de Facebook?

¿Tienes que servir más volumen de información que NetFlix?

Si estás entre la gran mayoría de los que responderían negativamente a todas esas preguntas, es muy probable que simplemente te sientas perezoso ante la perspectiva de la transición al modelo de Entrega Continua. En ese caso, mi recomendación es que tengas cuidado, porque a tu organización puede esperarle el mismo destino que al dodo o al tilacino.

Selección natural

A todo esto, nos habíamos dejado a Darwin a bordo del Beagle, navegando por los siete mares en busca de especies singulares. Al final de su viaje estaba perplejo con la variedad de fauna y fósiles que había encontrado, y comenzó una investigación que le llevó a enunciar la teoría de la selección natural en su obra “El origen de las especies”.

No es la especie más fuerte la que sobrevive, ni la más inteligente. Es la que se adapta mejor al cambio.

En la larga historia de la humanidad (y de los animales, también), aquellos que han aprendido a colaborar y a improvisar son los que han prevalecido de forma más efectiva.

Charles Darwin, naturalista inglés

La selección natural nos dice que los miembros de una población con características mejor adaptadas a su entorno, son los que sobreviven con mayor probabilidad. ¿Qué ocurre con los demás? Pues que tarde o temprano acaban desapareciendo.

Es una ley que se aplica a organismos vivos, y si nos paramos a pensar un poco, ¿qué es una organización sino un gran organismo vivo? Por supuesto que la selección natural se aplica a empresas y organizaciones, como cualquier lista de compañías extintas se encarga de demostrarnos.

En el entorno en constante cambio en el que se mueven la mayoría de los negocios, ya no sirve con tener productos buenos, bonitos y baratos. Hay que tenerlos antes, y hacer que evolucionen rápidamente según las demandas de los usuarios. Ya no basta con mantener métricas como la velocidad del equipo o la tasa de defectos. Las métricas que están marcando la diferencia entre los que triunfan y los que se quedan en el camino son otras:

  • Tiempo de ciclo (cycle time): el tiempo que transcurre desde que empiezo a trabajar en una funcionalidad, hasta que la tengo en producción.
  • Tiempo medio entre fallos (MTTF, mean time to failure): lo que tarda mi sistema de media en tener una caída o un corte de servicio.
  • Tiempo medio de recuperación (MTTR, mean time to recover): lo que tardo de media en poner en marcha mi sistema después de una caída.

La selección natural favorecerá a aquellos que sean capaces de mantener estos tiempos en valores lo más pequeños posibles, y es precisamente una de los aspectos en los que la Entrega Continua puede ayudarnos mejor.

Vale, ¡no quiero extinguirme! ¿Por dónde empiezo?

A lo largo de este artículo nos hemos centrado en ver los beneficios de la Entrega Continua y qué puede ocurrir si la ignoramos. Pero no hemos entrado mucho en ver cómo llevarla a la práctica, y dado el gran número de patrones y prácticas a tener en cuenta puede ser un proceso que diste de ser trivial.

Sin lugar a dudas hay una parte del proceso que es cultural, y en la que tendremos que trabajar dentro de nuestra organización para eliminar barreras y silos y mejorar la colaboración en la medida de lo posible.

Para ir guiándonos en los pasos necesarios hay muchos recursos disponibles en los que encontrar ayuda, pero sin lugar a dudas el mejor y más completo es el excelente libro de Jez Humble y David Farley, Continuous Delivery.

Si tu entorno está basado en tecnologías Microsoft, afortunadamente tenemos disponibles herramientas magníficas que pueden dar soporte a la mayoría de las prácticas que hemos mencionado. Visual Studio y Team Foundation Server, y otras herramientas relacionadas, van a servirnos para implementar toda la “pipeline” de Entrega Continua, desde la automatización de todo tipo de pruebas y despliegues, hasta temas más concretos como el análisis estático de código o la integración continua. Es verdad que dichas herramientas necesitan personalización y ajustes para adaptarlas a la forma de trabajar que estamos proponiendo, pero desde Plain Concepts podemos ayudaros a preparar el entorno que mejor se ajuste a vuestro proyecto; es algo que ya hemos hecho para montones de organizaciones, y parece que aún no se ha extinguido ninguna de ellas.

Para hacerte una idea de cómo puede personalizarse Team Foundation Server para dar soporte a la Entrega Continua, también puedes echar un vistazo a mi presentación sobre este tema en el ALM Summit 3.

Y si te puedes permitir esperar, en pocos meses estará disponible un libro en el que estoy colaborando con el equipo de Microsoft Patterns & Practices, y en el que contaremos con todo lujo de detalles qué se necesita para poner en práctica todas estas ideas de forma efectiva. ¡Más noticias acerca de esto en breve!

Enabling TFS 2012 new features for upgraded 2010 projects

If you follow the steps outlined in one of the upgrade procedures for TFS 2012, you’ll end up with a collection containing working projects, including all the historical data. But these projects will keep the old TFS process template, and so they will lack some of the exciting new features which are present in new projects that have been created with one of the new templates. If you went through the upgrade having in mind to use any of these features, at this point you may look like this:

annoyed

For example, in this upgraded Visual Studio Scrum 1.0 PBI work item, you can see that one of the new features (storyboarding) is missing:

image

Fortunately, it’s possible to upgrade the process template in these projects so it becomes the matching new one. This is how the former PBI looks once its template has been converted to the new Visual Studio Scrum 2.0 (notice the ‘Storyboards’ tab):

image

The procedure is supported for all the Microsoft TFS process templates (Sorry, no support for third party templates such as Scrum for Team System):

  • Visual Studio Scrum 1.0 projects get upgraded to Visual Studio Scrum 2.0
  • MSF Agile 5.0 projects get upgraded to MSF Agile 6.0
  • MSF CMMI 5.0 projects get upgraded to MSF CMMI 6.0

And after applying it you’ll get:

  • Teams
  • Code reviews
  • Feedback tool
  • My Work
  • Agile planning tools
  • Storyboards
  • Hidden work item types (such as code review and feedback WIs, or shared steps)

Once any TFS 2010 project has been upgraded and is already available in TFS 2012, just open the Web Access site, go to the configuration section:

image

And click on the available link at the left.

image

You’ll get a wizard that analyzes the current process template, finds the matching new one and upgrades it, so all these new features are available. Couldn’t be easier.

Enjoy!!!

Habilitando las características nuevas de TFS 2012 para proyectos actualizados desde 2010

Si sigues los pasos detallados en alguno de los procedimientos de actualización a TFS 2012, obtendrás una colección con proyectos funcionales que incluyen además todos los datos históricos. Pero esos proyectos conservarán la antigua plantilla de proceso de TFS, por lo que no dispondrán de algunas de las interesantes características nuevas que están presentes en los proyectos creados con las nuevas plantillas. Si habías hecho la actualización a TFS 2012 con la idea de usar alguna de estas características, en este punto estarás en una situación similar a ésta:

annoyed

Por ejemplo, en este elemento de trabajo de tipo PBI actualizado desde la plantilla Visual Studio Scrum 1.0, se puede ver que una de las características nuevas (storyboarding) no está disponible:

image_thumb[3]

Afortunadamente, es posible actualizar también la plantilla de proceso en esos proyectos para que se convierta en la plantilla nueva correspondiente. Así es como aparece el anterior PBI una vez que su plantilla ha sido convertida a la nueva Visual Studio Scrum 2.0 (ahora se puede ver la sección ‘Storyboards’):

image_thumb[5]

El procedimiento está soportado para todas las plantillas de TFS de Microsoft (Por el momento no hay soporte para plantillas de terceros como Scrum for Team System):

  • Los proyectos con Visual Studio Scrum 1.0 son actualizados a Visual Studio Scrum 2.0
  • Los proyectos con MSF Agile 5.0 son actualizados a MSF Agile 6.0
  • Los proyectos con MSF CMMI 5.0 son actualizados a MSF CMMI 6.0

Y después de ejecutar el procedimiento, obtendrás:

  • Equipos
  • Revisiones de código
  • Herramienta de Feedback
  • Trabajo en curso (My Work)
  • Herramientas de planificación Ágil
  • Storyboards
  • Elementos de trabajo ocultos (como los work items de code review y feedback, o los shared steps)

Una vez que cualquier proyecto de TFS 2010 ha sido actualizado y ya esté disponible en TFS 2012, simplemente hay que abrir el acceso web para el proyecto e ir a la sección de configuración:

image_thumb[7]

Y hacer click en el enlace disponible a la izquierda:

image_thumb[8]

Se abrirá un asistente que analiza la plantilla de proceso actual, encuentra la correspondiente plantilla nueva y la actualiza, de modo que todas esas nuevas características van a estar disponibles. No podría ser más fácil…

A disfrutar!!!