BDD y Continuous Delivery en la XGN

Este fin de semana estaré en la XGN de Santiago de Compostela y voy a intentar picaros un poco para que os animéis a venir. Como ya os conté, tengo tres sesiones junto con Alfredo Casado, pero hoy os voy a hablar de Teo crea su primera aplicación web (con Rails, Git y Heroku). La idea para esta sesión es hacer un taller en el que crearemos una aplicación web en Heroku utilizando Rails. Sin embargo, para hacerlo un poco más interesante, lo vamos a hacer al estilo Software Craftsmanship, lo vamos a hacer usando BDD y Continuous Delivery. ¿Os hace?

Continuous Delivery
Vamos a aprovechar lo fácil que nos pone las cosas Heroku para practicar (y entender) un poco eso de Continuous Delivery. Veremos lo que mola desplegar con cada commit y el nos daremos cuenta del cuidado que hay que tener cuando desarrollamos software (y no solo mientras escribimos el código).

BDD
Dado que vamos a desplegar la aplicación en el entorno de producción prácticamente con cada commit, necesitamos definir exactamente cada feature que vamos a desplegar. Para ello utilizaremos BDD (Utilizaremos Cucumber) de forma que cada vez que todas nuestras features ejecutables estén verdes podamos desplegar la aplicación sin ningún temor :D
Una pequeña cuña aquí. Nos vamos a dar cuenta de la importancia que tiene definir buenas historias de usuario de forma que nos sea sencillo crear features pequeñas y deployables. Por eso, os recomiendo el dojo de historias de usuario de los agilismo.es

Entorno
Si os apetece participar en el taller tenéis un par de opciones, podéis traer vuestro ordenador con git y ruby instalado o podéis traer vuestro ordenador con VirtualBox instalado y yo me encargo de daros una máquina virtual con todo instalado (Eso sí, esa máquina será un Linux con Vim como editor, ya os aviso :P).
Si os da tiempo, nos ahorraríamos algo de tiempo si os hacéis una cuenta en Heroku antes de asistir al taller.
Otra opción es que vengáis a cotillear, que también vale, pero es un poco más aburrido.

Ya sabéis, si quereis darle caña al continuous delivery no os podéis perder esta sesión. ¡Os espero!

PS: Por cierto, la aplicación que vamos a crear nos va a servir para sortear un par de Apprenticeship Patterns en la sesión sobre Software Craftsmanship, así que no podemos fallar :P

ACTUALIZACIÓN: Os cuento un poco las versiones de ruby y de las gemas que vamos a utilizar:

La versión de ruby será la 1.8.7
La versión de Rails será la 3.0.3.
Necesitamos también la gema de heroku, claro.
Después usaremos cucumber-rails y capybara. También le daremos al haml (haml-rails es la gema) y al Sass :D

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

Principios Ágiles #1

Cuando uno entra en esto del agilismo lo primero que le cuentan es el Manifiesto Ágil. Conocer el manifiesto ágil es importante, pero no basta con quedarse ahí. Los autores originales del manifiesto se tomaron muchas molestias para redactar los 12 principios detrás del manifiesto y es necesario que nos los tomemos tan en serio como al propio manifiesto.
He decidido dedicar un post a cada principio. Empecemos por el primero:

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

Nuestra prioridad más alta es satisfacer al cliente mediante entregas continuas y tempranas de software valioso.

¿Por qué la prioridad más alta?
Es importante destacar que los firmantes del manifiesto ágil tienen un objetivo por encima del resto. Además, dicho objetivo no es negociable. Siempre debe estar presente y siempre debe cumplirse. Si no se cumple es un fracaso.Dicho objetivo es satisfacer al cliente.

¿Qué significa satisfacer al cliente?
A la hora de realizar un desarrollo es importante tener un cliente que lo demande (Cuando hablo de cliente me refiero a quien demanda dicho desarrollo. Por ejemplo, un cliente puede ser el propio desarrollador que necesita una nueva librería para un proyecto más grande. No tiene porque ser siempre un cliente que firma un contrato). Si no existe el cliente no existe el desarrollo. El cliente es el leitmotiv del desarrollo. Esto, que parece tan simple, se pierde muchas veces de vista a lo largo del desarrollo, provocando que se tomen decisiones sin contar con el cliente con lo que el desarrollo se va alejando de las necesidades de dicho cliente.

¿Por qué con entregas continuas y tempranas?
Por varios motivos. Deben realizarse entregas tempranas porque es una forma de involucrar al cliente en el desarrollo (Puede validar la usabilidad del desarrollo, puede opinar sobre el entregable, etc...). A su vez, deben realizarse entregas continuas porque de esa forma se es capaz de adaptarse a lo que el cliente quiere en cada momento. Los requisitos del cliente no son inmutables, por eso, cuanto antes se le enseñe software funcionando antes se podrá modificar de acuerdo a las nuevas necesidades del cliente.
Mediante este tipo de entregas se consigue un feedback del cliente que permite que el rumbo del desarrollo siempre apunte hacía donde el cliente desea.

¿Qué es software valioso?
Es software que funciona y que hace lo que el cliente necesita. Es fácil decirlo, pero no es nada sencillo conseguirlo.
Software que hace lo que el cliente necesita se puede conseguir mediante entregas continuas y tempranas, tal y como se ha explicado antes.
Conseguir software que funcione es mucho más complicado pero es condición necesaria para conseguir la satisfacción del cliente. Esto, que puede parecer algo obvio, se suele olvidar en la mayoría de los desarrollos. La "industria del software" (clientes y proveedores) está acostumbrada a rebajar las exigencias y a permitir errores en la mayoría de los proyectos que se realizan (ya sea por los tiempos de entrega, por la pobre formación de los desarrolladores, etc). A un desarrollo hay que exigirle que funcione y en eso es en lo que se centra el agilismo, en el software que funciona. Cualquier otra cosa dejará al cliente insatisfecho. Probablemente algún bug aparezca (ya sabéis, cualquier código contiene al menos un bug) pero se debe reducir la tasa de errores al mínimo (sobre todo en las funcionalidades principales). Es cierto que no todos los desarrollos tendrán la misma calidad (Siempre habrá desarrolladores mejores y desarrolladores peores, pero eso solo puede tener influencia en el tiempo que se tarde en realizar el proyecto, en lo fácil o difícil que sea mantener dicho proyecto, etc), pero es necesario exigirnos que funcionen (Un Seat y un Ferrari funcionan, la diferencia está en el proceso de montaje, en la calidad de los materiales, etc).

Conclusiones

El primer principio ágil:

• se basa en el la satisfacción del cliente.
• muestra como obtener un feedback periódico del cliente.
• indica la necesidad de entregar lo que el cliente necesita.
• avisa de la importancia que tiene el entregar software que funciona.