Continuous Delivery – Pipelines en el desarrollo de software

Continous delivery (entrega continua en español) es un concepto bastante innovador de desarrollo de software que cada vez se escucha con más frecuencia. Gracias a esta práctica, las fases de producción que incluyen el desarrollo, el control de calidad y la entrega, no son definitivas, sino que se repiten de forma automatizada una y otra vez durante todo el proceso de desarrollo a través de un pipeline de continuous delivery. La principal ventaja es que, de esta manera, un software puede someterse cada poco tiempo a controles de calidad en cada una de sus fases de desarrollo, permitiendo realizar entregas, aunque el equipo siga trabajando en el desarrollo del producto final. Además, hay un feedback constante que procede del pipeline, lo que nos permite mejorar el software de forma inmediata tras cada modificación introducida en el código fuente.

Podemos resumir el continuous delivery como un proceso recíproco que integra y automatiza el desarrollo, la entrega, el feedback y la gestión de calidad. El resultado es que podemos simplificar las fases de trabajo para que nos lleven menos tiempo y se completen de forma más eficiente.

La principal ventaja del continuous delivery es que el proceso automatizado beneficia tanto al cliente como al desarrollador. Para el cliente, la ventaja radica en que el producto estará disponible más rápido y, normalmente, no presentará errores. Para los desarrolladores, implementar pruebas de campo resulta mucho más efectivo que llevar a cabo pruebas durante la fase de testeo beta porque obtienen información y orientaciones mucho más valiosas. Todo el proceso de desarrollo adquiere una mayor flexibilidad y se minimiza el riesgo de publicar software con bugs.

1. Fase de commit (Commit Stage): en esta primera fase de prueba se ejecutan tests de la versión del software, se desarrollan sus componentes y, cuando es necesario, se compilan. Además, se llevan a cabo las pruebas unitarias pertinentes. Si se superan con éxito todas las pruebas, la fase se da por finalizada. En este momento, se compilan y se almacenan en el repositorio los artefactos binarios de los componentes de software. Por todo lo anterior, se trata de un paquete que afecta decisivamente a la funcionalidad del pipeline porque determina el estado en el que se encuentra el software. Además, este paquete incluye todos los datos que serán instalados en un momento posterior en el sistema de destino. Los resultados de las pruebas en la fase de commit pueden asignarse de esta manera a las modificaciones concretas realizadas sobre el código fuente, que es precisamente una de las ventajas más significativas de la entrega continua.
2. Fase de aceptación (Acceptance Test Stage): en la segunda fase de prueba se ejecutan los tests de aceptación. Estamos hablando de las pruebas de integración (para comprobar si la interacción entre los componentes funciona) y las pruebas necesarias del sistema (para comprobar si el software funciona del lado del usuario). Además, existen otras pruebas opcionales que forman parte de la fase de aceptación, como pruebas de rendimiento y otros tests que ponen a prueba requisitos no funcionales del software. Durante la fase de aceptación, se vuelve a utilizar la compilación ejecutada en la fase previa que pasa a ser instalada en un entorno de pruebas adecuado.
3. En caso de que se constaten errores o complicaciones durante alguna de las fases comentadas, se creará documentación al respecto y, cuando sea necesario, se deberá enviar feedback al desarrollador. Puede enviarse mediante correo electrónico, programas de mensajería o herramientas especiales (que comentaremos más adelante). Cada vez que se produce una modificación en el código, el pipeline se pone en funcionamiento por lo que los mensajes de error siempre hacen referencia a la última modificación. Así, el desarrollador puede reaccionar con rapidez y de forma eficiente para arreglar los bugs o el código defectuoso.
4. Las pruebas manuales se realizan en función de las necesidades concretas de cada caso. A la hora de realizar estas pruebas, el pipeline vuelve a utilizar la compilación creada en la primera fase y la reinstala en un entorno de pruebas adecuado.
5. Si se completan todas las pruebas y el feedback recibido es positivo, ha llegado el momento de instalar el paquete manualmente en el sistema de destino. Normalmente, esto se hace con un solo clic. Es posible automatizar este paso a través del continuous deployment.

Dentro del mismo contexto en el que encontramos el término continuous delivery, aparece a menudo el término continuous integration. No obstante, hay una diferencia muy importante que afecta al alcance de uno y otro; cuando hablamos de continuous integration estamos haciendo referencia a la automatización del proceso de pruebas. Por lo tanto, el pipeline es un componente compartido con el continuous delivery. En cambio, el continuos delivery es un término que abarca mucho más, concretamente, abarca el proceso de liberación del software como un proceso automatizado. Por lo tanto, la entrega continua complementa al modelo de continuous integration e involucra al usuario final ya que entrega el producto y, simultáneamente, ejecuta las pruebas pertinentes.

Como desarrollador, decidir si basta con utilizar la integración continua o si es preferible ampliar el proceso de desarrollo e incluir el continuous delivery, dependerá de la planificación del desarrollo, del equipo de desarrollo y de la base de clientes. En la siguiente tabla comparamos los dos conceptos:

Existen varios programas que nos ayudarán a comenzar a trabajar incorporando la entrega continua. Os presentamos cuatro de los más conocidos.

Jenkins es una aplicación web que facilita la integración continua de los componentes del software. Jenkins está escrito en Java, se ejecuta en un contenedor EJB y dispone de varias herramientas de build (Apache Ant, Maven/Gradle, CVS, Subversion, Git, etc.) y, por supuesto, de los procesos de pruebas automáticas tan importantes en el caso del continuous delivery (Junit, Emma). Existen plugins opcionales que sirven para garantizar la compatibilidad con otros compiladores. Gracias a su interfaz basada en REST, otros programas pueden acceder a Jenkins. Jenkins es un programa gratuito de código abierto. Está recomendado especialmente para principiantes porque su interfaz y las funcionalidades que ofrece son muy intuitivas y fáciles de usar.

CircleCI también es una aplicación web para continuous integration, delivery and deployment. CircleCI funciona preferiblemente con GitHub, GitHub Enterprise y Bitbucket. Además, la plataforma ofrece muchas funcionalidades prácticas como la gestión de pedidos, gestión de recursos, docker support, soporte de todos los lenguajes de programación conocidos, almacenamiento seguro en caché, análisis de datos con estadísticas y completos conceptos de seguridad. CircleCI recibió el premio “Leader in Continuous Integration” de Forrester en 2017. El primer contenedor es gratuito y a partir del segundo el precio es de 50 $ por contenedor al mes.

Microsoft Team Foundation Server (TFS) es una herramienta colaborativa para proyectos de software que tienen que planificarse, desarrollarse y finalmente ser gestionados de manera conjunta. TFS es el sucesor no oficial de Microsoft’s Visual SourceSafe. Para permitir el trabajo colaborativo en los proyectos de software, TFS soporta varios procesos de desarrollo, incluido el CMMS, el desarrollo de software ágil y Scrum. Además, TFS está vinculado e integra programas de Office muy conocidos como Word y Excel para que no tengas que salir de TFS y abrir otro programa.

Existen varias características que te permiten crear un pipeline para continuous integration, delivery and deployment. Lo que hace TFS básicamente es dividir el proceso completo en varios apartados: control de versiones, build, reports y administración de usuario.

Los equipos de hasta 5 personas pueden utilizar de forma gratuita la versión Express. Los equipos más grandes deberán hacerse con la versión comercial que tiene un precio aproximado de 6 euros por usuario al mes. Pero normalmente esto conlleva la obligación de comprar una licencia de servidor. También es posible hacerse con TFS sin suscripción mensual, aunque para ello tienes que contactar con tu distribuidor local. El precio se encuentra entre los 500 y los 700 euros.

Codeship es una plataforma SaaS de integración continua (y de entrega) que se adapta a las necesidades particulares de cada usuario. Codeship soporta GitLab, GitHub y Bitbucket. Las funcionalidades disponibles dependen del plan contratado. Por ejemplo, en su versión gratuita, Codeship ofrece un entorno CI predefinido y flujos de trabajo CI/CD. Además, la versión gratuita permite realizar un almacenamiento de caché eficiente y pruebas de builds simultáneas en contenedores compartidos y preconfigurados. El plan gratuito incluye 100 builds al mes, un continuous build y un pipeline de pruebas. Destacamos el hecho de que no hayan establecido un límite de proyectos, usuarios o equipos máximos permitidos.

Si queremos sacarle más partido a Codeship, podemos comprar el plan “Codeship Basic”, que cuesta aproximadamente 45 euros al mes y va incrementando su precio en función del tamaño del equipo. Existe también otra versión de pago, la “Codeship Pro”, que aporta una funcionalidad adicional tutorial para docker, el “control completo” sobre el entorno de build, los builds locales y un mejor control del flujo de trabajo. Además, ofrece muchas herramientas que ayudan a ganar en eficiencia y transparencia. El precio varía en función del número de builds paralelos, pero es aproximadamente de 70 euros mensuales.