Post escrito por Mariano Minoli (@marianominoli), Ana María García (@amgarciao) y Javier Garzás (@jgarzas)
Para este año, uno de los libros que nos habíamos planteado publicar, con la inestimable ayuda y apoyo de la empresa 233 grados de TI, trata sobre un tema tan hablado como incomprendido como es la… Integración Continua.
Tal aventura y viaje no podría ser completado sin la ayuda de grandes profesionales. Así que, para tal gesta, para la escritura de un libro de tal contenido práctico, fueron Mariano Minoli y Ana María García quienes se lanzaron a escribirlo, sin dudarlo, dando así un paso más para ayudar a la comunidad del desarrollo, gestión e ingeniería software y, además, en español.
Finalmente, después de muchos meses, el libro está casi listo, bajo el título:
“Cómo implantar un proceso de integración continua. Guía de supervivencia con casos prácticos en Jenkins”
Aquí está la web del libro, provisional de contenido, por si quieres estar atento a las evoluciones y noticias del mismo.
Mientras llega octubre, y con él su lanzamiento, cómo sabemos que no vas a poder esperar, te vamos a ir dejando en estas semanas algunos post con extractos del futuro libro. E aquí el primero…
¿Integración, despliegues o entrega continua?
A menudo nos encontramos con profesionales que han oído hablar de integración, entrega o “algo” continuo y no terminan de hacerse una idea de qué realmente se trata o cuales son las diferencias entre unos y otros.
Por similares que puedan parecer a primera vista, tienen significados diferentes. Comencemos con una primera aproximación (luego los explicaremos mejor):
- Integración Continua (Continuous Integration): práctica ágil propuesta inicialmente en el marco de eXtreme Programming a finales de los ‘90 (Beck, 1999) por la cual se propone que “cada desarrollador mantenga su código integrado continuamente con la rama principal del repositorio de código del proyecto”.
- Despliegue Continuo (Continuous Deployment): la idea principal de esta práctica puede resumirse en: “entrega el código a los clientes con la mayor frecuencia posible” (Ries, 2009).
- Entrega Continua (Continuous Delivery): Martin Fowler lo resume de la siguiente manera en su sitio web (Fowler, 2013) “es la construcción de software para que esté siempre en un estado en que pueda ser puesto en producción.”
Claramente están relacionados, pero se refieren a distintas cuestiones. En primer lugar veamos Integración Continua, que es una práctica elemental del mundo ágil.
Integración Continua
Fue propuesta a finales de los años 90, como parte de eXtremme Programming y pretendía servir como base para el cumplimiento de uno en los doce principios del manifiesto ágil:
“Entregamos software funcional frecuentemente, entre dos semanas y dos meses, idealmente, en periodos de tiempo lo más cortos posible.”
Esta práctica normalmente se asocia al equipo técnico y consiste en mezclar/integrar (lo que se conoce como merge en inglés) el trabajo de desarrollo, con la rama principal del repositorio de código constantemente para que los cambios puedan ser probados tanto de manera individual, como en su relación con otros cambios del resto de desarrolladores del equipo. Veamos la definición que propone Martin Fowler (Fowler, 2006):
“Integración continua es una práctica de desarrollo de software en la cual los miembros de un equipo integran su trabajo con frecuencia, por lo general cada persona integra su trabajo por lo menos una vez al día dando lugar a múltiples integraciones por día. Cada integración es verificada por una build automática (incluyendo pruebas) para detectar errores de integración lo más rápidamente posible. Muchos equipos encuentran que este enfoque conduce a la reducción de manera significativa de los problemas derivados de integración y permite a los equipos desarrollar software con mayor rapidez.”
Integración, no es despliegues o entregas continuas
Su diferencia con los últimos dos términos es clara: aquí hablamos “solo” de mantener un repositorio unificado (estable, consistente, probado automáticamente) todo el tiempo. Es decir, esta práctica se centra en el camino que recorre el código desde la máquina del desarrollador hasta el repositorio de código (y a veces su despliegue en entornos de prueba).
A pesar de que el concepto de Integración Continua ha estado dando vueltas desde las primeras versiones de eXtreme Programming, no fue sino hasta 2006, cuando la idea (y sobre todo las herramientas) terminaron de madurar y popularizarse.
Prueba de ello es el libro de Duvall titulado “Continuous Integration: Improving Software Quality and Reducing Risk” (Duvall, 2006). El libro presenta la idea en una versión más refinada, analizando su impacto dentro de la organización, además se proponen prácticas para llevar a cabo una implementación así como herramientas técnicas imprescindibles para su éxito.
Ahora bien, verás que existe una diferencia mucho más sutil entre Despliegue y Entrega continuos. Para complicar la situación, existe un ejército de bloggers intentando aclararlo con poco éxito (muchas veces complicando aún más su entendimiento). Según nuestra opinión, la mejor explicación es la que ofrece Martin Fowler en su sitio (Fowler, 2013):
“Ambos términos son similares y fueron acuñados en la misma época. Veo la diferencia como una decisión de negocio sobre la frecuencia de despliegue en producción. Entrega continua se trata de mantener la aplicación en un estado en el que siempre es capaz de desplegarse en producción. Por otro lado Despliegue Continuo consiste en desplegar todos los cambios en producción, todos los días o con mayor frecuencia.”
Despliegue Continuo es una práctica cercana al equipo de operaciones
Siguiendo el razonamiento de Fowler, Despliegue Continuo es una práctica cercana al equipo de operaciones TI, relacionada con el término DevOps, por medio de la cual se intenta implementar el patrón Fail Fast (Shore, 2004). Es decir, si un cambio o nueva característica ha sido desarrollado, debe ir a producción lo antes posible. La verdad es que no hay demasiados equipos utilizando esta práctica. Al menos no de manera pura.
Entrega Continua
Por último hablemos de Entrega Continua como una práctica asociada al negocio que ha cobrado mucha relevancia en los últimos tiempos. Significa disponer de una versión “siempre lista para ser entregada”, dando al product owner (departamento comercial o quien sea que maneje el aspecto comercial del producto) el poder de decisión sobre cuándo se despliegan nuevas características a los usuarios finales.
Este enfoque es diferente al anterior, donde decíamos “siempre se instala”. Aquí la idea es “siempre está lista para ser instalada”.
Esta diferencia que puede parecer trivial pero tiene enormes implicaciones organizaciones y estratégicas en empresas que desarrollan productos y que intentan mantenerse a la vanguardia en sus respectivos sectores.
La mayor parte de las empresas tecnológicas que compiten con productos en internet actualmente utilizan este enfoque. Se dice que Flickr (la plataforma social para compartir fotos) despliega diez versiones nuevas por día. También es conocido que Facebook insta a su programadores nóveles a escribir y desplegar una característica en los primeros días de trabajo. Aunque esto último sea una declaración de intenciones algo pretenciosa, es una muy potente.
Concluyendo…
Como te imaginarás, no es posible pensar en Entrega Continua sin antes haber implantado un sólido esquema de Integración Continua. Es por ello que siempre recomendamos la adopción de herramientas y técnicas de Integración Continua, antes de embarcarse en un proyecto de Entrega Continua. Sin una base de Integración Continua sólida, no tiene sentido pensar en Entrega Continua.
Nos gusta pensar que Integración Continua está más cerca del equipo técnico, mientras que Entrega Continua depende más del equipo comercial y la estrategia hacia los clientes de la organización.
La implantación de Integración y Entrega Continua en una organización implica un esfuerzo conjunto que implica a varios departamentos de la organización. En especial afectan a los departamentos de desarrollo de software (o programación), el departamento comercial y el departamento de TI (o sistemas u operaciones). En próximos post analizaremos más detalles sobre estas técnicas y las herramientas asociadas.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Yo creo que sería bueno hacer versión Early Access de los libros. Así los fans tenemos «acceso temprano» al libro y también podemos contribuir con comentarios desde el principio, dar ideas, etc. ¿Cómo lo ves? 🙂
Un libro sobre una temática fundamental en el desarrollo de «software» y se agradece mucho que se publiquen también en castellano.
Lo que no termino de entender es qué le veis a Jenkins. Considero que es una aplicación con una interfaz muy mediocre y convierte cualquier configuración en un batiburrillo de opciones. De acuerdo que Jenkins ofrece multitud de «plugins» y se instalan con relativa facilidad pero la configuración de todo sigue siendo un tostón, además el conjunto resulta bastante caótico. Personalmente me quedo con CruiseControl sin lugar a dudas. Configuro todo mediante ficheros XML que guardo en el repositorio y mantengo siempre un buen orden en la integración continua y los despliegues.
Gracias por el aporte Lázaro! La verdad es que no es el espíritu de esta publicación limitarse a explicar «la herramienta». El libro recorre todos los aspectos metodológicos, de equipo y organizacionales de la implantación de Integración Continua e intenta ejemplificar estos conceptos con Jenkins. ¿Por qué Jenkins y no Cruise Control, Team Foudation Server, Bamboo o Hudson? Sencillamente por que es la herramienta que se ha consolidado como más utilizada por la comunidad en los últimos tiempos. No decimos que sea la mejor, pero sí nos pareció indicado que era lo que más aportaba a la comunidad.
En http://www.infoq.com/research/ci-server puedes encontrar un análisis muy interesante sobre las herramientas que existen en este momento y cuáles son las tendencias de uso (al menos la de los lectores de esta publicación).
Hola Javier, sólo te informo que está roto el enlace del libro: http://www.233gradosdeti.com/2014/09/libro-integracion-continua-jenkins/
Hola a todos, desde Argentina. ¿El libro de Integración Continua se sigue consiguiendo en algún lugar para comprarlo? La web del libro está caída. Muchas gracias.
No llegó a salir, murió en la columna de Doing