Pages Menu
Categories Menu

Posted by on Sep 6, 2017 in General | 3 comments

Más sobre Continuous Delivery (y unos apuntes gráficos)

En el post de ayer te contaba sobre el Agile 2017 en Orlando, y a raíz de aquello quiero volver a refrescar el tema del Continuous Delivery. Cuando este agosto estuve en Orlando una de las Keynotes la daba Jez Humble, que podríamos decir que fue, con su libro, del 2010, quien popularizó el movimiento del Continuous Delivery (que, obviamente, viene de mucho antes).

Curioso, que un tema con ya sus tantos años de para una Keynote en un congreso tan destacado en el año 2017. Fíjate que ya en 2012 hay aquí en el blog post que tratan el tema del Continuous Delivery y relacionados, como ¿Tardaríais mucho en pasar a producción un cambio en sólo una línea de código? Aprende entrega continua) o Agilidad y DevOps… ¿Son lo mismo? y ¿Qué es DevOps?.

Mi personal resumen de la Keynote de Jez Humble lo fui dibujando mientras escuchaba y te lo dejé casi en directo por varios sitios, Twitter, Linkedin, etc., y también te lo comparto aquí. Está en inglés porque me era más fácil escuchar y escribir directamente, pero no debes tener problema para entenderlo. Si en el post ves el dibujo un poco raro bájate la imagen, o ábrela sola en una pestaña nueva, en el post puede que no se vea bien por la diferencia entre el ancho de columna del post y del dibujo.

jgarzas_jezz_humble_keynote_agile20017_

Por si no te es familiar el tema, el Continuous Delivery o entrega continua (tiro de la definición de Fowler) es una disciplina, buena práctica, de desarrollo software en la que el software se construye de tal manera que puede ser liberado en producción en cualquier momento. Lo que no implica necesariamente pasar a producción cada vez que hay un cambio, eso lo decide el Product Owner de turno, pero, en cualquier caso, la versión está lista para ello.

Uno de los principales temas en la charla de Jez Humble fueron las excusas típicas para no lograr llegar al Continuous Delivery. Interesante, pero, como te decía antes, todo sonaba muy retro, porque todos los problemas y excusas típicas para seguir manteniendo barreras entre desarrollo y producción llevan ahí años (fíjate, por poner un ejemplo, en este post de hace un par de años ¿Por qué cuesta tanto implantar DevOps (o continuous delivery o pasar a producción algo inmediatamente)?)

agile_2017_jezz_keynoteKeynote sobre Continuous Delivery en el Agile 2017 Orlando

Interesante conocer, más con el objetivo de eliminar excusas, que Amazon lanza una release cada 11,6 segundos, por aquellos que dicen que el Continuous Delivery es “sólo para pequeñas empresas”, eso sí, necesitó 4 años de trabajo para lograrlo.

Y curioso conocer que el Gobierno Federal de los USA consiguió una transformación a Continuous Delivery, por aquellos de que “en entornos muy burocráticos es imposible”.

En el dibujo de antes te dejo más datos interesantes.

Como conclusión final, lo que muchas veces suelo decir, en el mundo de la tecnología, que solemos asociar con que todo va muy rápido… no todo es así y hay prácticas ahí que para muchos, aun siendo de hace muchos años, son aún un futuro lejano.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.
Javier Garzás

3 Comments

  1. Buen post y útil como siempre, Nada que luego de la gráfica en el párrafo donde citas a Fowler dice “en la el software se construye” creo que falta “que” -> “en la QUE el software se construye.”

  2. Buen post y útil como siempre, nada más decir que luego de la gráfica en el párrafo donde citas a Fowler dice “en la el software se construye” creo que falta “que” -> “en la QUE el software se construye”

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This