miércoles, 22 de diciembre de 2010

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

9 comentarios:

  1. ¿Qué opinión te merece el libro?
    Le tengo ganas, pero así de primeras el resumen no me ha impresionado demasiado, parece en la línea del Continuous Integration, está muy bien cuando no tienes ni idea para introducirte en el mundillo, pero si no, meh...

    ResponderEliminar
  2. Pues no he leido mucho, la verdad :D Un par de capítulos... Pero tiene buena pinta. Prometo escribir algo más interesante cuando lleve más leido :P

    ResponderEliminar
  3. ?A que hora va a estar tu presentación mañana? Es posible que poderé venir por verle.

    ResponderEliminar
  4. I don't know yet when my presentation is going to be :S Maybe at 3 or 4 pm

    It would be really great to see you again before I leave :D

    ResponderEliminar
  5. La parte de guardar todo en el/algún repositorio de control de versiones me parece lo más complicado, pero en el fondo pensando un poco, si usamos maquinas virtuales se podría simplemente tener un repositorio de imágenes virtuales, incluso se podrían meter en un repo maven como una dependencia más, aunque no se si con archivos tan grandes habría problemas. Pero todo es ponerse, seguro que hay formas de hacerlo, lo realmente importante es saber que se puede hacer y que tu proceso tiene margen de mejora.

    Y suerte con el avíon!,

    ResponderEliminar
  6. La parte de control de versiones es buena ya que como decían en "Release it"? (creo que era ese) muchas veces se nos olvida que un VCS es un gestor de unidades de información, y no sólo de código fuente, así que todo tipo de información cabe en él y de hecho deberíamos poner todo lo necesario para que nuestro sistema de integración continua cree la release.

    En JavaPolis 2006, Erich Gamma hizo una presentación sobre como en Eclipse llevaban 5 años lanzando software sin el más mínimo retraso. No sólo eso, si has ido por eclipse.org sabes que estos tíos tienen nightly builds que funcionan a la perfección. Es decir, una release al día. Para conseguir hacer eso hay que ser muy metódico y tener todo automatizado y programado como un reloj.

    Dejo enlace al post donde yo escribía sobre esa presentación: http://brigomp.blogspot.com/2007/04/eclipse-5-aos-lanzando-software-tiempo.html

    Suerte con la presentación.

    ResponderEliminar
  7. Según lo entiendo creo que dice que tengas controladas las versiones de los distintos elementos del sistema en funcionamiento, como pej. la versión del tomcat. Pero no que tengas que tener el tomcat en el repositorio del proyecto. ¿No?

    Lo segundo para equipos que sólo llevan 1 proyecto también le veo su utilidad, pero para otros que llevamos un montón lo veo bastante complicado. Me obligaría a tener una máquina para ic por proyecto o a restringir el tamaño de la cola del servidor de integración contínua a 1 para evitar builds en paralelo.

    Un saludo y ánimo con la presentación. Encima en inglés uf, uf...

    ResponderEliminar
  8. A lo mejor llega tarde, pero siempre puedes echarle un ojo al propio Jez Humble: http://www.infoq.com/presentations/Continuous-Delivery
    ;-)

    ResponderEliminar
  9. Muchas gracias :D Me apunto la charla para esta tarde (o mañana :D )

    ResponderEliminar