Entrega continua. ¿Un paradigma inalcanzable?

Imagen cortesía de Stuart Miles
freediditalphotos.net

Dicho grosso modo, el objetivo de la entrega continua es el despliegue frecuente a los entornos de producción. De hecho, debería hacerse tan pronto como estuviera disponible una mejora o una nueva característica y estamos hablando de días o incluso horas. El objetivo de entrega continua no es nuevo pero si toma especial relevancia con el “advenimiento” de las metodologías ágiles en el ámbito de la ingeniería de software. Fijémonos en el primer principio del manifiesto ágil:

 “Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.”

Básicamente, las condiciones para que una nueva release pase a producción es que atraviese por las distintas etapas relacionadas con gestión de configuración, build, generación de los paquetes de instalación, la instalación en los distintos entornos y sus pruebas correspondientes.  Si consiguiésemos que todo este proceso fuera automatizado y fiable (entendiendo que la fiabilidad se obtiene con la repetición), se reduciría sustancialmente el tiempo y coste de cada iteración del ciclo de vida, materializando el principio.

Siendo tan evidente, ¿por qué no todo el desarrollo de software sigue este criterio? Fundamentalmente por dos razones. Primero, la automatización de procesos que van más allá de la construcción del software en si no se “entrega”. Es obvio que es mucho más barato y sencillo dos iteraciones manuales que desarrollar un pipeline de despliegue donde todas las fases se automatizan. Es un esfuerzo que el cliente no ve a corto plazo y penaliza la primera entrega. Ahora bien, antes o después será consciente de sus ventajas. Sobre todo cuando vea lo que cuesta cambiar una línea de código. O cuando tenga que asumir los riesgos de cambiarla y, en pro de la flexibilidad, deba dejar a un lado todos los procesos establecidos y delegar en el pobre programador que haga el cambio la responsabilidad de que siga funcionando la instalación. En segundo lugar, la automatización requiere perfiles de análisis y programación muy cualificados. Por alguna razón que no viene al caso, los perfiles de pruebas y que ejecutan procesos de build, generación de versiones e instalación, se han considerado menos cualificados técnicamente  que los de otras fases del desarrollo. Esto conlleva que los programadores más avezados no quieran formar parte de estos equipos, entrando en un círculo vicioso. Si unimos la extendida tendencia de separar los equipos (pruebas, integración, instalación, construcción y análisis), la convergencia con el paradigma de entrega continua se complica.

Tengo que señalar que, salvo en los ejemplos de la literatura, nunca he visto un pipeline de entrega continua completo. Aunque nadie duda de sus bonanzas, siempre ha habido poderosas razones, basadas en lo que ya he descrito, para no llevarlo a cabo o, mejor dicho, para aplazar a posteriores ocasiones que nunca llegaron. En mi opinión, alcanzar este paradigma pasa por un cambio cualitativo en quien adquiere software. Las instalaciones deben estar preparadas para la entrega continua y, el software adquirido, incluir la automatización de los procesos.