Principios detrás de "Continuous Delivery"

Mañana tengo que hacer la presentación sobre "Continuous Delivery" y todavía no se muy bien que contar, así que voy a ensayar un poco con esta entrada :P Os voy a contar los principios que guían a los autores en esto de la entrega continua.

Create repeatable, reliable process for releasing software
Para los autores, liberar software debe ser fácil. ¿Alguna vez os habéis tenido que quedar una tarde o un fin de semana preparando una puesta en producción? ¿Os ponéis nerviosos con cada entrega al cliente? Si eso pasa es porque no confiais en vuestro proceso de entrega de software, os crea incertidumbre porque no es repetible. Depende demasiado de las personas que realizan esa tarea.
Según los autores, habremos triunfado si conseguimos que entregar software sea aburrido (común).

Automate almost everything
¿Cómo conseguimos que entregar software sea aburrido? Según los autores, automatizando todo lo que podamos el proceso. Eso sí, nos avisan de que no es necesario que automaticemos todo de golpe. Podemos ser un poco más conservadores e ir resolviendo solo nuestro mayor problema.

Yo estoy de acuerdo con ellos, aunque a mi me gusta hacerlo de golpe :D Cualquier proceso manual puede ser propenso a errores, por lo que prefiero minimizarlos :P

Keep everything in version control
Se refieren a todo, desde el código fuente, por supuesto, hasta las máquinas virtuales que utilizas para montar los entornos de test, pasando por los compiladores que necesitan para crear los entregables...

En realidad, no se refieren a que lo tengas todo dentro del sistema de control de versiones, se refieren a que cada entregable y el entorno en el que se construyó debe poder ser reconstruido a partir de un número de versión. Por ejemplo, si usas maven, tener todas las librerías externas que usas anotadas con la versión, de forma que cuando reconstruyas el artefacto no uses nuevas versiones. O, si tu aplicación la van a desplegar en un Tomcat 6, tener un entorno de test asociado a la versión a reconstruir que tenga ese Tomcat 6.

Todo esto me parece un autentico pasote y no se muy bien que pensar de todo ello. Veo que, algunas cosas sí que son sencillas (código fuente, librerías externas, documentación, etc) pero no tengo ni idea de como asociar hardware a versiones de artefactos. Creo que muchas del movimiento devops está relacionado con esa parte (mencionan puppet en algún lado), pero hablo desde la ignorancia :D

If it hurts, do it more frequently, and bring the pain forward
La integración continua se basa en este principio. ¿Integrar el código de los desarrolladores cada semana duele? Pues hazlo cada minuto. Es curioso, porque es muy poco intuitivo, pero funciona: D ¿Por qué no aplicarlo al resto? Cada vez que tenemos que desplegar la aplicación en el entorno de pruebas las pasamos canutas. Despliégala con cada commit, verás como al final no duele.
Es una forma de obligarnos a mejorar nuestro proceso de desarrollo.

Build quality in
Este lo toman prestado de lean (pero lo dicen, ¡eh!) :D Cuando suene una alarma, actua en consecuencia. ¿Se rompe el build? La prioridad es arreglarlo. ¿La aplicación falla en producción? Volvemos a la versión anterior y arreglamos el error (Eso sí, para volver a la versión anterior de una forma fácil y rápida más nos vale haber cumplido el primer y segundo principio).

Done means released
Algo terminado es algo que tiene el cliente. El resto está sin terminar. Puede parecer un poco radical, pero es cierto. La solución que plantean los autores es minimizar el tiempo que pasa entre el inicio del desarrollo y la entrega al cliente.

Everybody is responsible for the delivery process
Al igual que en el Agile Testing nos dicen que las pruebas son responsabilidad de todo el equipo, aquí nos dicen que la entrega de software debe ser responsabilidad de todo el equipo también.

Continuous improvement
Este también lo toman prestado de lean y, basicamente, significa que hay que reflexionar sobre lo que hacemos y mejorar :)


Y eso es todo. Como veis, es un libro bastante ambicioso. Estoy deseando ver como se las apañan para acercarse a estos ideales :D Un saludo

Continuous Delivery

Aunque parezca mentira, ya casi ha pasado un mes desde que llegué a Eden. Hoy comienza mi última semana como interno y, como todos los lunes, ya tengo mi tarea semanal. Tengo que leerme el "Continuous Delivery" y hacer un resumen durante mi presentación :) Tenía ganas de leerlo, ahora ya tengo excusa :P

Continuous delivery está escrito por Jez Humble y David Farley, ambos thoughtworkers, y el libro entra dentro de la serie firmada por Martin Fowler. Tal y como ellos cuentan al principio, el titulo lo han sacado directamente del Manifiesto Ágil, concretamente del primero de sus principios:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Lo primero que me ha venido a la cabeza cuando he empezado a leer el libro ha sido ¿por qué necesito leer este libro? Jez y David me han dado la respuesta:

Only when you have control over the progression of every change from introduction to release can you begin to optimize and improve the quality and speed of software delivery.

Solo cuando tengas el control sobre la progresión de cada cambio desde que lo introduces hasta que lo liberas, podrás empezar a optimizar y mejorar la calidad y velocidad de tus entregas de software

Aunque acabo de empezarlo y aún no he podido leer mucho, la idea central del libro es lo que ellos llaman el patrón "deployment pipeline" que, tal y como lo definen, es una implementación automatizada de las fases de build, deploy, test y release de la aplicación sobre la que se trabaja, es decir, automatizar al máximo todo el proceso a partir del commit.

El libro promete bastante, ya os iré contando. Un saludo.

PS: Hoy es el cumpleaños de Todd, felicitadle por twitter :D

Pair Programming Cara a Cara

Hace poco he empezado a tomarme más en serio mi relación con la Software Craftsmanship.
He decidido andar "El Largo Camino" (The Long Road).

Mi largo camino
En el Coderetreat que organizó Agilismo.es (patrocinado por Autentia y Eden Development ¡Gracias!) tuve la suerte de desvirtualizar a Enrique Comba el cual me regaló una copia del "Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman". Si os interesa la Software Craftsmanship tenéis que leer este libro. Entre otras muchas cosas, algo que deja claro es lo importante que es relacionarse con otros, aprender de otros y enseñar a otros.

A su vez, hace poco que un grupo de españoles (vale, también había un argentino) fuimos a la conferencia SC 2010 en Bletchley Park. El mensaje que Jason Gorman quiso transmitirnos allí fue:

Enseñad vuestro código, enseñad lo que hacéis, difundid la palabra

Así pues, he decidido que, en esta parte del camino, voy a intentar relacionarme con la gente para enseñarles lo que hago y aprender lo que ellos hacen. Voy a compartir con otros mis experiencias.

Compartir con otros
Tras volver de Londres escribí un twitt ofreciendome a programar con gente con una sola condición, tenía que ser cara a cara. A aquel twitt contestarón varios apasionados del software. Aún tengo pendiente quedar con varios de ellos (no os he olvidado :P), pero ya he tenido mis dos primeras experiencias.

Apasionados
Mi primera vez (sé como suena) fue con @jjballano. Nos reunimos para hacer la kata "StringCalculator" en Java. No llegamos a acabarla (¿es una kata muy larga o solo me lo parece a mi?) pero sí que avanzamos bastante en la solución. Creo que, aunque empezamos haciendo ping-pong programming, no dejé participar demasiado a Jesús (no se como lo vio él, pero hice un refactor demasiado largo). Habrá que repetir y "arreglar" eso.

La segunda vez hice un trío (sé como sigue sonando) con @GermanDZ y @reemplazable :P Nos decantamos por esta kata en Ruby. Tras intentar instalar RSpec (sin éxito), acabamos usando Test::Unit y terminando la kata. Aprendimos un poquito de Ruby, @GermanDZ nos enseñó como afronta él las refactorizaciones y @reemplazable hizo una linea de código que nos dejó locos :). Creo que fuimos un poco rápido y 13'' no es lo mejor para tres personas, pero estuvo muy bien. Después nos tomamos las debidas cañas, que molaron igual o más :P

Futuro
Lo próximo que quiero hacer es grabar una de estas sesiones y subirla al internet para que la podáis ver todos.

Si os apetece programar una tarde conmigo no tenéis más que avisarme. Eso sí, daos prisa porque el próximo 30 de noviembre me marcho a Eden Development. Me han ofrecido hacer un internship y, si todo va bien, convertirlo en un apprenticeship :D Ya os iré contando.

Estoy muy contento y féliz :)

Libros: Agile Testing (Parte 1)

Desde que volví del Agile Open Spain he intentado practicar el agilismo de guerrilla de Xavi Gost y, de momento, he conseguido que nos compren todos estos libros ¡Yuju! Algunos ya los he leido, pero me pareció buena idea tenerlos en la oficina por si, algún día, alguien se interesa y lee alguno. De entre los que aún tengo pendientes de leer me decidí por Agile Testing de Lisa Crispin y Janet Gregory (Si no os dicen nada estos nombres os recomiendo ojear sus twitters y blogs. Además, por si hace falta vender un poco más el libro, sabed que contiene un prefacio escrito por Mike Cohn y otro escrito por Brian Marick ¡ahí es nada!). Les pedí permiso para hacer un pequeño resumen en castellano de su libro y me lo dieron, así que... ¡Allá vamos!

Para empezar, el libro está dividido en 6 partes, así que dedicaré un post (mínimo) a cada una de las partes. Este, como ya os imagináis, está dedicado a la primera :D

Parte I: Introducción
En esta primera parte se hace un resumen de las principales diferencias entre el enfoque ágil y el enfoque tradicional basado en fases (algo que deberíamos tener todos bien claro ya). También se explora la idea del equipo multidisciplinar ágil desde el punto de vista de la calidad y las pruebas. Además, se define lo que debe ser la "mentalidad ágil para testing" y que hace que un tester tenga éxito en un equipo ágil.

Capítulo 1: De todos modos, ¿Qué es testing ágil?

Para ser ágil es necesario ser un equipo, y es necesario que todo el equipo sea consciente de la importancia que tienen las pruebas para alcanzar una calidad alta. Pero, si todo el equipo está preocupado de probar el desarrollo ¿Cómo cuadra un tester en un equipo ágil? Debe ser consciente de su situación. Cuando un equipo es ágil, los programadores prueban los casos límite (mediante TDD). Dado que el tester queda libre del trabajo de grano fino, puede centrarse en otro tipo de problemas que aporten un mayor valor al cliente (Exploratory testing, usabilidad de la aplicación, etc).

En un equipo ágil los testers no se sientan a esperar el trabajo, dan un paso adelante y buscan formas de contribuir durante todo el ciclo de desarrollo. Estas contribuciones pueden ir desde la automatización de las pruebas (en la medida de lo posible) hasta opiniones en las charlas de diseño para que el código sea más sencillo de testear.

Al ser un equipo ágil la colaboración con el cliente es la norma. El tester debe beneficiarse de esa colaboración para definir los test de aceptación de cada funcionalidad. Cuando los test demuestran que un mínimo de funcionalidad está completo el equipo puede considerar la historia terminada.
El tester de un equipo ágil debe conocer tanto el negocio como la tecnología. Debe ser el "traductor" entre negocio y tecnología.

Conclusiones del capítulo 1

• Un tester ágil debe seguir el manifiesto ágil (Individuos e interacciones, software funcionando, colaboración con el cliente y respuesta al  cambio).
• El testing ágil se centra en añadir valor al negocio y en entregar la calidad que el cliente solicita, diferenciándose así del testing tradicional, centrado en cumplir unos requisitos.
• Todos los miembros del equipo es responsable de entregar software de alta calidad.
• En caso de duda, volver a los valores y principios ágiles.

Capítulo 2: Diez principios para testers ágiles

¿Que es un tester ágil? Es un tester que acepta el cambio, sabe colaborar tanto con la gente de negocio como con la gente técnica y entiende como utilizar los test para documentar los requisitos y dirigir el diseño.

Un tester ágil no debe verse a si mismo como un policía de la calidad que protege al cliente de código inadecuado. Debe estar preparado para reunir y compartir información, para trabajar con el cliente y ayudarle a expresar sus requisitos de forma adecuada para que pueda conseguir las características que necesita y para proveer el feedback sobre el progreso del proyecto a todo el mundo.
Un tester ágil, al igual que sus compañeros de equipo, disfruta adquiriendo nuevas habilidades y no se limita a resolver únicamente problemas sobre testeo. Como cualquier otro miembro del equipo ayuda a la mejora continua tanto del proyecto como de dicho equipo.
Los 10 principios que debe seguir un tester ágil son:

1. Provee feedback de forma continua. Dado que las pruebas dirigen el diseño, es importante que el tester se centre en expresar los requisitos del cliente en forma de tests y que trabaje de la mano del cliente para que cualquier cambio en los requisitos llegue de forma rápida y clara al equipo de desarrollo.
2. Entrega valor al cliente. Un tester ágil permanece centrado en la visión global del proyecto. Si una característica se vuelve demasiado compleja debe analizar si conviene realizarla completa o simplemente hacer que funcione el camino normal (dejando los casos raros para otra iteración).
3. Posibilita la comunicación cara a cara. Si hay dudas sobre una cierta funcionalidad el tester debe reunir al experto de negocio y al programador para que lo discutan. Dado que el tester entiende el negocio pero también comprende la parte técnica, puede ayudar a crear un lenguaje común entre ambos mundos.
4. Ten coraje. Cualquier miembro de un equipo ágil debe tener coraje. Además, un tester ágil lo necesita porque, al ponerse en la situación del cliente, puede tener que decirle al equipo que algo no es correcto.
5. Mantenlo simple. Debe hacer las pruebas más simples posibles que verifiquen que una funcionalidad satisface las exigencias del cliente respecto a la calidad del producto. Esto no quiere decir que la funcionalidad esté implementada y que funcione, eso se presupone. Se refiere a temas como el rendimiento, la seguridad, etc.
6. Practica mejora continua. Debe buscar nuevas formas de ayudar al equipo (herramientas de automatización, unirse a listas de correo sobre testing, mejorar en el test exploratorio, leer artículos, libros y blogs para obtener nuevas ideas, etc).
7. Responde al cambio. Mediante la automatización de las pruebas es más sencillo responder al cambio. Si todas las pruebas que realiza son manuales será imposible adaptarse a los cambios a la velocidad que exige un equipo ágil.
8. Auto-organízate. Debe compartir con el equipo los problemas que encuentre de forma que el equipo se auto-organice para solucionar dicho problema.
9. Céntrate en las personas. En un equipo ágil todos sus miembros son igual de importantes y los tester no están infravalorados. Un tester ágil sabe que está ayudando al equipo de una forma única.
10. Disfruta. Trabajar en un equipo donde todos sus miembros colaboran, donde el tester está involucrado desde el principio del proyecto hasta el fin del mismo, donde los responsables de negocio trabajan junto al equipo de desarrollo y donde todo el equipo toma la responsabilidad tanto de las pruebas como de la calidad es un bonito lugar de trabajo para un tester.

¿Cómo añade valor un tester a un equipo ágil? Se está hablando de que, en un desarrollo ágil, las pruebas dirigen el desarrollo, pero se necesitan las pruebas correctas. El tester, con su capacidad para entender tanto el negocio como el lado técnico es capaz de aportar al equipo dichas pruebas.

Conclusiones del capítulo 2

• La mentalidad de un tester ágil está centrada en el cliente, es orientada a resultados, es colaborativa y tiene muchas ganas de aprender.
• La actitud es importante y difumina las fronteras entre los roles en un equipo ágil.
• Los testers ágiles aplican los valores y principios ágiles (feedback, comunicación, simplicidad, entrega de valor, etc) para ayudar al equipo a identificar y entregar los requisitos del cliente.
• Los testers ágiles añaden valor a sus equipos y organizaciones gracias a su punto de vista único.