¿Qué es la entrega continua?

Según la metodología tradicional, antes de que el software pueda entregarse al usuario final, tiene que pasar por largas fases de desarrollo, análisis y revisión. Esta metodología en cascada, en la que los productos se desarrollan por completo antes de probarse e implementarse, consume mucho tiempo y genera ciclos de implementación lentos y una experiencia de usuario menos positiva.

Como componente principal de DevOps, y en el contexto más amplio de la CI/CD, la entrega continua ha formado parte de la revolución del software Agile. En lugar de crear paquetes completos de una sola vez, la entrega continua incorpora todos los aspectos del desarrollo de código que pueden ir a producción y hace uso de soluciones de automatización avanzadas para tareas repetitivas, como las pruebas. Con este enfoque, los desarrolladores pueden aplicar cambios pequeños en el software a un ritmo más uniforme. En algunas circunstancias, el código puede ir directamente a producción, algo que también se conoce como implementación continua.

Esto proporciona una serie de ventajas clave para las empresas y los proveedores de software:

Cuando los desarrolladores lanzan implementaciones a gran escala, hay muchas cosas que pueden salir mal. La entrega continua limita el riesgo de la implementación, ya que se centra en cambios pequeños que se pueden examinar más fácilmente, cuyos problemas, si los hay, pueden solucionarse de un modo más sencillo y cuyo comportamiento puede corregirse antes si no es el esperado.

En lugar de limitarse a esperar a que los desarrolladores decidan cuándo se ha terminado el trabajo, con la entrega continua los responsables de proyectos y aplicaciones trazan fácilmente el progreso a través del rastreo de los ciclos de entrega de software. Además, pueden decidir cuándo y cómo continuar con la implementación en entornos de producción o pruebas. En algunos casos, puede que sea conveniente aprovechar la información recopilada durante el ciclo de vida de entrega continua a través de una solución de gestión del flujo de valor, ya que puede ayudarnos a comprender las capacidades de los equipos e identificar y eliminar los cuellos de botella.

Cuando las implementaciones de software pasan a través de las etapas de desarrollo preestablecidas, hay fases que pueden tardar bastante tiempo en completarse. La entrega continua obliga a los equipos a incorporar tareas de pruebas y corrección en los procesos rutinarios, y a basarse en la automatización para el desarrollo y el aprovisionamiento con el fin de reducir la carga. Gracias a ello, es posible contar con menos fases de desarrollo, menos trabajo redundante y tiempos de respuesta más rápidos. De hecho, el sello distintivo de la entrega continua es que el software que se produce se puede publicar en cualquier momento; una mejora notable si lo comparamos con los largos plazos de entrega del desarrollo tradicional.

Si los desarrolladores invierten mucho tiempo en crear algo, pero su lanzamiento no es efectivo o su acogida no es buena, deben volver a la casilla de salida sin que su trabajo sea valorado. Como en esta metodología se trabaja con versiones más breves y más frecuentes, cuando el software pasa por la fase de pruebas, resulta más fácil detectar los problemas, y los usuarios de la aplicación pueden proporcionar comentarios en las primeras fases y de forma regular. De este modo, los desarrolladores pueden aplicar correcciones sobre la marcha, si es necesario.

A través de comentarios fiables que se aportan durante todo el ciclo de vida de la entrega, los desarrolladores pueden mejorar y optimizar sus productos, probar las características e ideas, y eliminar cualquier cosa que sea innecesaria, ineficaz o que genere una experiencia de usuario negativa.

La entrega continua se basa en la automatización para eliminar muchos de los costes fijos que tradicionalmente han estado asociados con el desarrollo de software. Con la entrega continua, la inversión en costes inicial y durante el ciclo de vida del desarrollo es inferior, y se obtiene un mayor retorno de los costes que se mantienen.

Los maratones de desarrollo y los inminentes plazos de entrega de proyectos desgastan a los equipos de desarrollo. Por el contrario, las correcciones y las versiones a pequeña escala se pueden gestionar con mayor facilidad y de forma simultánea a otras tareas. La entrega continua no solo crea un entorno de trabajo menos estresante y contribuye a evitar el agotamiento, sino que también da la posibilidad a los desarrolladores de interactuar de forma más directa con los usuarios y ver con claridad los beneficios que aporta su trabajo a los clientes.

A grandes rasgos, la entrega continua parece ser lo mismo que la implementación continua, pero, aunque ambas son parte del enfoque de desarrollo de software Agile, presentan diferencias sutiles que es vale la pena analizar.

Como se ha descrito anteriormente, la entrega continua automatiza muchos de los procesos que forman parte del desarrollo de software y, con ella, los equipos pueden realizar cambios graduales y continuos en los productos. Sin embargo, la entrega continua no automatiza la etapa final de la aprobación de la implementación en producción. Los cambios que se han realizado y probado en entornos de prueba suelen pasar por una fase de revisión manual y autorización como parte del lanzamiento programado para la implementación completa.

La implementación continua lleva la automatización un paso más allá a través de la implementación automática de las actualizaciones según una programación predefinida o cuando el código se entrega desde el proceso de entrega continua. Si el código no requiere un periodo definido de implementación, al automatizar la gestión de la gobernanza del cambio (si se utiliza) de una manera fiable, los desarrolladores obtienen acceso directo a producción y pueden garantizar que las actualizaciones se implementan regularmente, sin que ellos tengan que hacerlo manualmente. Gracias a ello, las empresas tienen una mayor capacidad para lanzar más implementaciones en cualquier momento, y se eliminan muchos de los problemas vinculados a las entregas de mayor volumen. Para la mayoría de las organizaciones, el principal obstáculo de la implementación continua es la necesidad de una gobernanza sólida, por ejemplo, por motivos de normativas del sector. Implantar la implementación continua en algunas organizaciones depende, en gran medida, de la capacidad de automatizar eficazmente las aprobaciones manuales, como en un proceso formal de gestión de cambios.

El concepto general de entrega continua resulta fácil de entender: la división de procesos de desarrollo que requieren mucho tiempo en tareas y lanzamientos de menor escala con el respaldo de la automatización. Sin embargo, entenderlo no es lo mismo que saber aplicarlo. Los siguientes son requisitos previos fundamentales para cambiar a la entrega continua de software:

El enfoque de desarrollo de software en cascada del que hemos hablado antes puede seguir muy arraigado en algunas personas y procesos de los equipos de desarrollo. Por ello, conseguir el cambio cultural a un desarrollo basado en la metodología Agile y de DevOps requerirá una amplia planificación y una formación exhaustiva. Si los equipos de desarrollo no están comprometidos, es poco probable que la entrega continua tenga éxito.

El cambio cultural hacia DevOps tendrá que producirse más allá de los límites del desarrollo de software. Los bucles de retroalimentación rápidos y la toma de decisiones eficaz exigen una colaboración y coordinación claras con el equipo de liderazgo, de modo que todos sean plenamente conscientes de los procesos adecuados y se comprometan con ellos.

Conseguir tiempos de entrega rápidos y lanzamientos de software sin problemas no aportará muchas ventajas a las organizaciones si los productos finales no pueden satisfacer los requisitos de seguridad y cumplimiento. Afortunadamente, es posible aplicar muchos de los mismos enfoque de las herramientas de automatización de la entrega continua a minimizar los riesgos de seguridad que conlleva la implementación. Las herramientas automatizadas de análisis de código que incorporan las políticas determinadas por los equipos de seguridad especializados forman parte del proceso. Si se está utilizando la gestión automatizada de cambios, los análisis mencionados anteriormente pasan a formar parte de la información empleada para crear y aprobar automáticamente solicitudes de cambio.