Queremos velocidad. Y cada vez más. Queremos tener ciclos de desarrollo más cortos, con feedback más rápido y que empiecen a aportar valor lo antes posible. No se trata sólo de aplicaciones web, con su facilidad de despliegue comparada con la actualización de una aplicación de escritorio instalada en miles o millones de máquinas, sino de todo tipo de aplicaciones.

Si hace unos años lo habitual era encontrarse con aplicaciones que se actualizaban cada 12 o 18 meses, ahora es frecuente que las aplicaciones se actualicen cada pocos meses, semanas o incluso días (y en casos más extremos, horas). Tener aplicaciones que son actualizadas en producción varias veces al día no es algo extraño actualmente.

La motivación económica de todo esto es clara. Si podemos empezar a obtener rendimiento del desarrollo que hemos realizado antes, podremos tardar menos en amortizarlo, aunque ello implique tener que gestionar adecuadamente la deuda técnica asumida por el camino. Por el camino además podremos validar las hipótesis de las que partimos y modificarlas si fuera necesario. Cuando se produzcan problemas en nuestras aplicaciones podremos ofrecer solución en menos tiempo.

Continuous delivery y continuous deployment

No voy a entrar en demasiados detalles sobre lo que significan estos conceptos, pero sí lo suficiente como para poder poner en contexto el resto del post. La definión que da Martin Fowler de continuous delivery (¿entrega continua?) es bastante clara (negritas mías):

La entrega continua es una disciplina del desarrollo de software en la que se construye el software de tal manera que puede ser desplegado a producción en cualquier momento.

Continuous delivery nos permite desplegar siempre que queramos, pero ello no implica que lo hagamos siempre que sea posible. En eso consiste precisamente continuous deployment (¿despliegue continuo?): en desplegar cada cambio que realizamos en el software. Aquí puede empezar a haber una escala de grises en cuanto a si el despliegue es directamente a producción o a un entorno de preproducción donde realizar alguna última comprobación manual, como en el caso de los blue-green deployments.

Conseguir todo esto no es nada fácil. Para empezar, es necesario ser capaz de partir el trabajo de una forma que no implique dedicar 18 semanas de desarrollo para implementar una funcionalidad sino que podamos hacerlo incrementalmente aportando valor por el camino. Además, tenemos que resolver unos cuantos problemas técnicos para trazar una buena estrategia de pruebas automáticas, diseñar un sistema automático de despligue, contar con mecanismos de monitorización para asegurarnos de que el despliegue no ha destruido nada y un sinfín de cosas más. Si alguien tiene curiosidad, el libro DevOPS Handbook (gracias por el regalo, DeveloperOS) es un buen recurso para aprender más sobre las cosas que debemos tener en cuenta y cómo podemos conseguirlas.

Como usuario

Lo bueno de ser desarrollador de software y no ser, por ejemplo, veterinario, es que es más sencillo comprender a tus usuarios. Los desarrolladores usamos software (yo diría que, en general, más que el resto del personas) y eso nos permite comprobar en nuestras propias carnes los efectos que tienen ciertas prácticas en el desarrollo de software.

Cuando pienso en cómo me afecta como usuario la entrega continua y, especialmente, el despliegue continuo, mi experiencia es variada.

Hay situaciones en las que no interfiere en mi flujo normal de uso de aplicaciones, por lo que toda mejora, ya sea una pequeña funcionalidad o la corrección de un agujero de seguridad, es bienvenida. Es el caso de los navegadores, que se han convertido en uno de los mejores exponentes de las aplicaciones evergreen. Actualizar Firefox o Chrome no me supone ningún esfuerzo y, la mayoría de las veces, ni siquiera soy consciente de ello y puedo aprovechar las mejoras de rendimiento y seguridad.

Sin embargo, que cada vez que enciendo el portátil de casa se tire un par de horas quemando CPU y disco con Windows Update, o que cuando quiera usar un juego me toque actualizar el cliente de Steam y luego el propio juego, me resulta bastante molesto, sobre todo porque no suelo percibir grandes ventajas.

En el mundo de las aplicaciones web la cosa es más fácil. No pagas el precio de la instalación y el proceso es transparente, pero aun así, que me estén cambiado de sitio los 4 informes que miro esporádicamente en Google Analytics tampoco me hace mucha gracia.

Si esto lo llevo al desarrollo (herramientas, plataformas, librerías, etc.), puede ser incluso más cansado. Muchas veces acabo con la sensación de que estoy usando productos inacabados porque, «total, como podemos sacar una versión en cada commit, ya iremos corrigiendo los problemas sobre la marcha». Puede que para el que desarrolla estos productos sea verdad, pero como usuario preferiría despliegues menos frecuentes y más consistentes.

Por poner un ejemplo que no sea el loco mundo de javascript, en el caso de C# se ha pasado de versiones cada 1 o 2 años a versiones cada pocos meses. Antes, la temática de cada versión estaba clara: 2.0 generics, 3.0 linq, 4.0 dynamic, 5.0 async/await… Ahora, los cambios son menores y las diferencias entre C# 7.2 y C# 7.1 son menores. Pese a que comprendo las ventajas de disponer antes de las mejores del lenguaje sin esperar a versiones mayores, esto hace que las bases de código acaben siendo poco homogéneas y (tal vez) más incómodas de mantener.

Por supuesto, todo esto tiene sus ventajas. Que los problemas se corrijan en muy poco tiempo (a veces incluso horas) es algo que se agradece. ¿Compensa con lo que comentaba antes? En mi caso preferiría dos líneas en paralelo, una de correcciones con releases más frecuente y otra de nuevas funcionalidades más paquetizada, mejor probada y con menor frecuencia, pero supongo que cada uno tendrá sus preferencias.

Y todo esto teniendo en cuenta que yo me considero un usuario con conocimientos técnicos.

Para los otros usuarios

Cuando trasladas este escenario a usuarios no avanzados, el problema se acentúa.

Desde nuestra torre de marfil pensamos que desplegar software es lo importante, pero eso es sólo el principio. El software está ahí para solucionar el problema de alguien y, casi siempre, eso implica ser usado por alguien. Y ese alguien no quiere tener que estar pensando en cómo actualizar aplicaciones, en descubrir nuevas funcionalidades que tal vez no le interesen y, sobre todo, en que cambie la forma en que tiene que usar el software para realizar su trabajo porque alguien ha decidido que era mejor cambiar un botón de sitio u «optimizar» un flujo de aplicación.

Recuerdo la época en la que hacía proyectos en lugar de desarrollar producto.

El despliegue podía ser más o menos complicado, pero llegaba un momento en que entre el departamento de sistemas del cliente y nuestro equipo de desarrollo el proceso quedaba bastante automatizado y manejable. La parte difícil era coordinar con negocio y con los usuarios.

A veces la funcionalidad nueva sólo podía entrar en producción en determinado momento por cuestiones comerciales (aunque hubiera estado desarrollada antes y hubiera, teóricamente, podido «aportar valor» antes). Otras veces, había que asegurarse de que los usuarios estaban formados en la nueva funcionalidad, que no era sólo una cuestión de software. El software estaba ahí para ayudarles a hacer un proceso del mundo físico, y si no sabían como realizar ese proceso, daba igual el software que tuvieran.

En estas ocasiones en las que el despliegue del software forma parte del despliegue de un nuevo proceso de negocio hace falta coordinar muchas áreas más allá del desarrollo de software. Está bien que el desarrollo de software no sea un obstáculo para desplegar esos procesos de negocio cuando sean necesarios, pero tampoco puede acelerar ciertas cosas.

Conclusión

Aplicar continuous delivery/deployment tiene muchas ventajas, tanto para nuestros potenciales usuarios como para nosotros. Nuestros usuarios tienen acceso antes a funcionalidades que les pueden resultar útiles y a soluciones a problemas que hayan podido encontrar, y nosotros tenemos un mecanismo rápido que nos permite obtener su feedback y validar nuestras hipótesis.

Desde esa perspectiva, el único freno a la hora de tratar de implementar estas técnicas sería el coste de hacerlo. Como mencionaba al principio del post implementarlas requiere cambios importantes a nivel cultural y técnico que deben ser valorados.

Sin embargo, como todo, hay que entender el contexto en que nos encontramos antes de aplicar soluciones que, tal vez, en lugar de aportar valor nos lo restan. Especialmente cuando hacemos cosas que nuestros clientes perciben como molestas.

A nosotros nos puede venir fenomenal usar a nuestros clientes actuales como conejillos de indias para validar hipótesis (usando tests A/B o técnicas similares), pero tal vez a ellos no les resulte tan cómodo un cambio en algo que usan a diario. Podemos pensar que partir esa feature enorme en 17 más pequeñas es genial porque nos permite liberarla de forma incremental, pero quizá nuestro cliente acabe un poco decepcionado cuando ve una implementación demasiado simple y se canse de nosotros.

Incluso hay quien no se preocupa demasiado de los fallos en producción porque puede monitorizarlos y corregirlos en muy poco tiempo, pero para el cliente que ha perdido datos por culpa de uno de esos fallos le sirve de poco consuelo.

Todo esto se puede amortiguar con una buena comunicación con tus clientes, pero eso no siempre es viable en determinados modelos de negocio.

Creo que es fundamental ser capaz de responder rápidamente ante fallos y para ello acercarnos al ideal del continuous delivery puede ser útil, aunque no tengo tan claro que para ese escenario sea la mejor salida. Como usuario, preferiría que estuviera separada claramente una cosa de otra (correcciones de nuevas versiones), y poder mantenerme en la versión X del producto un tiempo razonable recibiendo correcciones sin tener que ir recibiendo cambios de funcionalidad cada poco tiempo. Al menos en los productos que considero herramientas importantes en los que prefiero una cierta estabilidad, tanto técnica como funcional.