Continuous Delivery – Pipelines en el desarrollo de software
Equipo editorial de IONOS
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.
Continuous delivery hace referencia a una serie de prácticas utilizadas en el desarrollo de software para ejecutar el desarrollo, la entrega, el feedback y la gestión de calidad de forma simultánea y cada poco tiempo, de acuerdo con un proceso repetitivo. De esta forma, se gana en eficiencia y el cliente puede recibir el producto con mucha más prontitud, incluso cuando todavía no está terminado. La entrega continua genera un feedback constante para el desarrollador procedente de pruebas automatizadas que sirven, en general, para comprobar la estructura después de cada cambio introducido 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.
Las ventajas del continuous delivery
Antes, el desarrollo de software funcionaba de una manera diferente: el producto final solo se entregaba si todas las funcionalidades estaban totalmente desarrolladas, funcionaban a la perfección y no se detectaban fallos importantes cuando se realizaban las pruebas de calidad. Así que el desarrollador tenía que entregar posteriormente parches o actualizaciones cada cierto tiempo. Gracias al continuous delivery, el cliente recibe el producto en una fase más temprana del desarrollo en la que todavía no ha sido terminado. Esta pre-entrega suele incluir la funcionalidad estructural del software para que el cliente pueda probarla en un entorno real. De esta manera, el propio cliente (o el tester de software) juega un papel muy importante dentro del proceso de control de calidad.
Gracias al feedback recibido, el desarrollador puede mejorar las funcionalidades del producto durante la fase de desarrollo. Además, recibe información muy valiosa que le aporta una idea clara sobre qué funcionalidad debería desarrollar a continuación. Antes de que existiera el continuous delivery, este proceso era realmente tedioso y, a menudo, dejaba descontentas a las dos partes: por un lado, el cliente normalmente espera que un producto final cumpla con sus requisitos y deseos y, por otro, el desarrollador todavía no sabe exactamente cuáles son esos requisitos y deseos. Si se entabla una comunicación sobre el estado de desarrollo del producto en una fase más temprana, es más fácil tener en cuenta los requisitos del cliente y no cometer errores. Es posible ilustrar en forma de ciclo este principio:
Como muestra la imagen, las tres áreas que incluyen el desarrollo, el control de calidad y la producción no se reemplazan por un único proceso, sino que están constantemente interconectadas. De esta forma, un producto pasa por cada una de las fases individuales repetidamente y recibe mejoras continuas. Cuando tenemos que trabajar con muchos clientes al mismo tiempo, es imposible conseguir algo así si no contamos con procesos automatizados. Y en este punto es precisamente en el que interviene la entrega continua ya que se encarga de automatizar todo el proceso.
Gracias al continuous delivery, es posible comprobar los procesos y mejoras implementados sobre el software (es decir, todos los cambios realizados sobre el código fuente) en tiempo real con el fin de conseguir un feedback. Si un cambio genera efectos secundarios no deseados, será posible detectarlos rápidamente, lo que te permitirá implementar las acciones necesarias en una fase temprana del desarrollo. Este punto es realmente una mejora importante porque facilita, por ejemplo, la detección de bugs dentro del código. Sin la entrega continua, detectar dónde se encuentra el error se convierte en un trabajo realmente tedioso.
Hasta que llega al cliente, el software está en una fase intermedia, el pipeline de continuous delivery. En este pipeline se llevan a cabo pruebas manuales y automáticas. Cada fase de pruebas conlleva la aparición de una nueva versión del software (que suele llamarse “versión beta” o en algunas ocasiones “Nightly Build”, es decir la última versión creada de forma automática) que, a su vez, entra en el pipeline. Hasta que se hayan pasado todas las pruebas y se reciba un feedback positivo, no se crea una versión “estable” y no se libera oficialmente el producto (este proceso se conoce como “liberación” y también incluye a la propia aplicación publicada). Así aumentan considerablemente las probabilidades de que el cliente reciba un producto sin bugs.
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.
Resumen: ventajas y desventajas del continuous delivery
| Ventajas | Desventajas |
|---|---|
| Es mucho más fácil encontrar y eliminar los errores presentes en el software durante la etapa de desarrollo. | Factor de costo: es necesario contar con un servidor potente y fiable de integración de datos para llevar a cabo las pruebas automatizadas y conseguir una liberación correcta y segura del producto. |
| En el pasado, el desarrollo de software requería muchísimo esfuerzo. Gracias al continuous delivery, los desarrolladores pueden concentrarse exclusivamente en el desarrollo. | Las pruebas automatizadas tienen que funcionar a la perfección y no presentar errores de código. En caso contrario, pueden ocasionar graves daños al ser ejecutadas. |
| Gracias al pipeline de continuous delivery es mucho más sencillo para los desarrolladores llevar a cabo la resolución de problemas. | Requiere que haya una buena coordinación dentro del equipo porque los cambios introducidos en el código deben compilarse de forma eficiente y con una determinada frecuencia. |
| Otros procesos de prueba (como las pruebas alfa y beta) conllevan más costes asociados. | Requiere una buena y continua comunicación con los clientes y sus sistemas de destino. |
| Se pueden dedicar más recursos a la etapa conceptual que a la técnica durante el control de calidad para mejorar el software. | El cliente espera que haya mejoras y actualizaciones continuamente. Es difícil poder “pausar” el proyecto de desarrollo. |
| Normalmente el desarrollo de software se consigue de forma más rápida porque el proceso de liberación automatizado reduce la carga de trabajo de los desarrolladores y también la cantidad de descansos que deben tomar. | A la hora de implementar innovaciones, mejoras o modificaciones al producto, sigue siendo necesario hacerlo manualmente. Si se quiere automatizar este proceso, es necesario recurrir al continuous deployment. |
| Gracias a que las publicaciones de software ocurren más rápido y más a menudo, se recibe más feedback lo que se traduce en más mejoras. | El cliente tiene que estar dispuesto a utilizar el software cuando todavía se encuentra en una fase de desarrollo. Además, tiene que poner de su parte y devolvernos su feedback. |
| Los desarrolladores tienen que soportar menos presión a la hora de realizar cambios en el código fuente porque los errores se encuentran mucho más rápido. Esto sirve como motivación e inspiración para el trabajo. |
Las fases del pipeline de continuous delivery
Cuando se produce una modificación en el código, se activa el pipeline de continuous delivery y se ejecutan las pruebas. A continuación, te mostramos las fases que atraviesa:
- 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.
- 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.
- 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.
- 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.
- 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.
Continuous integration vs. continuous delivery
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:
| Continuous integration (CI) | Continuous delivery (CD) |
|---|---|
| Proceso de pruebas automatizado que revisa en profundidad cada modificación realizada en el código fuente. | Abarca más que el proceso de pruebas e incluye al proceso de entrega. Las nuevas características y las modificaciones realizadas en el código llegan automáticamente al usuario final. |
| El equipo tiene que ejecutar pruebas automatizadas cada vez que se incluye una nueva característica, mejora o se produce una modificación en el código. | Las pruebas tienen que ser realmente eficaces en el CD porque los resultados se entregan directamente al usuario final. |
| Requiere un servidor de integración dedicado y continuo que controle y ejecute las pruebas automatizadas. | La instalación en el sistema de destino también debe ser lo más automatizada posible, lo que plantea mayores exigencias al servidor. |
| Los desarrolladores tienen que fusionar las modificaciones del código con mucha frecuencia y de forma continua. | Los desarrolladores tienen que mantener una buena comunicación con el cliente y saber explicar de forma clara cómo funciona el software. |
| Requiere un uso relativamente elevado de recursos si se quiere garantizar la calidad del producto en el momento de la entrega. | En el caso del CD el esfuerzo es aún mayor pero el producto puede ser entregado mucho antes tras haber sido sometido a pruebas “reales”. |
| El desarrollo en sí es más eficiente, pero es necesario pausarlo más a menudo debido a las liberaciones manuales. | Permite realizar un desarrollo continuo porque el proceso de liberación está automatizado en gran medida. |
Las continuous delivery tools más conocidas
Existen varios programas que nos ayudarán a comenzar a trabajar incorporando la entrega continua. Os presentamos cuatro de los más conocidos.
Jenkins
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.
Echa un vistazo a nuestro tutorial de Jenkins sobre el funcionamiento de la aplicación paso a paso.
CircleCI
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
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
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.
