Entrega continua

La entrega continua ( CD ) es un enfoque de ingeniería de software en el que los equipos producen software en ciclos cortos, lo que garantiza que el software pueda ser lanzado de manera confiable en cualquier momento. ^{[ 1 ] [ 2 ]} Su objetivo es construir, probar y lanzar software con mayor velocidad y frecuencia. Este enfoque ayuda a reducir el costo, el tiempo ^{[ 3 ]} y el riesgo de entregar cambios al permitir actualizaciones más incrementales de las aplicaciones en producción. Un proceso de despliegue sencillo y repetible es importante para la entrega continua.

Según Neal Ford, la entrega continua adopta el principio de "Abordar el problema desde el principio", tratando las tareas difíciles con anticipación, fomentando la automatización y la detección rápida de problemas. ^{[ 4 ]}

La entrega continua trata la noción común de una canalización de despliegue ^{[ 5 ]} como un Poka-Yoke diluido : ^{[ 6 ]} un conjunto de validaciones por las que debe pasar una pieza de software en su camino hacia el lanzamiento . El código se compila si es necesario y luego se empaqueta mediante un servidor de compilación cada vez que se confirma un cambio en un repositorio de control de versiones , luego se prueba mediante una serie de técnicas diferentes (posiblemente incluyendo pruebas manuales) antes de que pueda marcarse como listo para su lanzamiento.

Los desarrolladores acostumbrados a un ciclo de desarrollo largo pueden necesitar cambiar su mentalidad al trabajar en un entorno de entrega continua (CD). Cualquier confirmación de código puede ser publicada para los clientes en cualquier momento. Patrones como los interruptores de características pueden ser muy útiles para confirmar código temprano que aún no está listo para ser utilizado por los usuarios finales. ^{[ 7 ]} El uso de NoSQL puede eliminar el paso de migraciones de datos y cambios de esquema, a menudo pasos manuales o excepciones a un flujo de trabajo de entrega continua. ^{[ 8 ]} Otras técnicas útiles para desarrollar código de forma aislada, como la ramificación de código , no están obsoletas en un mundo de CD, pero deben adaptarse para ajustarse a los principios de CD; por ejemplo, ejecutar múltiples ramas de código de larga duración puede resultar poco práctico, ya que un artefacto publicable debe construirse temprano en el proceso de CD a partir de una sola rama de código para que pase por todas las fases de la canalización.

La entrega continua se habilita mediante el pipeline de despliegue. El propósito del pipeline de despliegue tiene tres componentes: visibilidad, retroalimentación y despliegue continuo. ^{[ 9 ]}

• Visibilidad : Todos los aspectos del sistema de entrega, incluyendo la creación, el despliegue, las pruebas y el lanzamiento, son visibles para todos los miembros del equipo con el fin de fomentar la colaboración.
• Retroalimentación : Los miembros del equipo se enteran de los problemas lo antes posible cuando ocurren para poder solucionarlos cuanto antes.
• Despliegue continuo : mediante un proceso totalmente automatizado, puede desplegar y lanzar cualquier versión del software en cualquier entorno.

Según Yan Cui, en entornos sin servidor , los recursos efímeros deben mantenerse juntos y tener su propio pipeline de despliegue para lograr una alta cohesión . Sin embargo, los recursos compartidos que requieren un tiempo de arranque prolongado y una zona de aterrizaje deben tener su propio repositorio , pipeline de despliegue y pila independientes. ^{[ 10 ]}

La entrega continua lleva la automatización desde el control de versiones hasta la producción. Existen diversas herramientas que ayudan a lograr la totalidad o parte de este proceso. ^{[ 11 ]} Estas herramientas forman parte del pipeline de despliegue, que incluye la entrega continua. Los tipos de herramientas que ejecutan diversas partes del proceso incluyen: integración continua , automatización de lanzamiento de aplicaciones , automatización de compilación y gestión del ciclo de vida de las aplicaciones . ^{[ 12 ]}

Para practicar la entrega continua de manera efectiva, las aplicaciones de software deben cumplir con un conjunto de requisitos arquitectónicamente significativos (RAS), como la capacidad de despliegue, la modificabilidad y la capacidad de prueba. ^{[ 13 ]} Estos RAS requieren una alta prioridad y no se pueden descuidar a la ligera.

Los microservicios se utilizan con frecuencia en la arquitectura para la entrega continua. ^{[ 14 ]} El uso de microservicios puede aumentar la capacidad de despliegue y la modificabilidad de un sistema de software. Las mejoras observadas en la capacidad de despliegue incluyen: independencia del despliegue, menor tiempo de despliegue, procedimientos de despliegue más sencillos y despliegue sin tiempo de inactividad. Las mejoras observadas en la modificabilidad incluyen: menor tiempo de ciclo para pequeños cambios funcionales incrementales, cambios más fáciles en la selección de tecnología, cambios incrementales en los atributos de calidad y actualizaciones más fáciles de lenguajes y bibliotecas. ^{[ 14 ]}

El libro original sobre entrega continua escrito por Jez Humble y David Farley (2010) popularizó el término; sin embargo, desde su creación, la definición ha seguido evolucionando y ahora tiene un significado más desarrollado. Actualmente, las empresas están implementando estos principios y mejores prácticas de entrega continua. La diferencia entre dominios, por ejemplo, médico frente a web, sigue siendo significativa y afecta la implementación y el uso. ^{[ 15 ]} Entre las empresas conocidas que adoptan este enfoque se incluyen Yahoo !, ^{[ 16 ]} Amazon , ^{[ 17 ]} Facebook , ^{[ 18 ]} Google , ^{[ 19 ]} Paddy Power ^{[ 1 ]} y Wells Fargo . ^{[ 20 ]}

Se han reportado varios beneficios de la entrega continua. ^{[ 1 ] [ 15 ]}

• Lanzamiento al mercado más rápido : La entrega continua permite a una organización ofrecer a sus clientes el valor comercial inherente a las nuevas versiones de software con mayor rapidez. Esta capacidad ayuda a la empresa a mantenerse un paso por delante de la competencia.
• Desarrollar el producto adecuado: Las actualizaciones frecuentes permiten a los equipos de desarrollo de aplicaciones obtener comentarios de los usuarios con mayor rapidez. Esto les permite centrarse únicamente en las funciones útiles. Si descubren que una función no es útil, no le dedican más tiempo ni esfuerzo. De esta forma, logran crear el producto adecuado.
• Mayor productividad y eficiencia: Ahorro significativo de tiempo para desarrolladores, probadores, ingenieros de operaciones, etc., gracias a la automatización.
• Lanzamientos fiables: Los riesgos asociados a un lanzamiento han disminuido significativamente y el proceso de lanzamiento se ha vuelto más fiable. Con la entrega continua, el proceso de despliegue y los scripts se prueban repetidamente antes de su implementación en producción. Por lo tanto, la mayoría de los errores en el proceso de despliegue y los scripts ya se han detectado. Con lanzamientos más frecuentes, disminuye el número de cambios de código en cada lanzamiento. Esto facilita la detección y corrección de cualquier problema que surja, reduciendo el tiempo durante el cual tiene un impacto.
• Mejora de la calidad del producto : El número de errores detectados e incidentes de producción ha disminuido significativamente.
• Mayor satisfacción del cliente : Se logra un mayor nivel de satisfacción del cliente.

También se han investigado los obstáculos. ^{[ 15 ]}

• Preferencias del cliente: Algunos clientes no desean actualizaciones frecuentes de sus sistemas.
• Restricciones de dominio: En algunos dominios, como las telecomunicaciones, la medicina, la aviónica, el ferrocarril y la industria pesada, las regulaciones exigen pruebas de las nuevas versiones por parte del cliente o incluso in situ.
• Falta de automatización de pruebas: La falta de automatización de pruebas conlleva una falta de confianza por parte de los desarrolladores y puede impedir el uso de la entrega continua.
• Diferencias en los entornos: Los diferentes entornos utilizados en el desarrollo, las pruebas y la producción pueden provocar que problemas no detectados se filtren al entorno de producción.
• Pruebas que requieren la intervención humana : No todos los atributos de calidad pueden verificarse mediante automatización. Estos atributos requieren la participación humana, lo que ralentiza el proceso de entrega.

Chen planteó y desarrolló ocho desafíos adicionales para la adopción. ^{[ 21 ]} Estos desafíos se encuentran en las áreas de estructura organizacional, procesos, herramientas, infraestructura, sistemas heredados, arquitectura para la entrega continua, pruebas continuas de requisitos no funcionales y optimización de la ejecución de pruebas.

Se han reportado varias estrategias para superar los desafíos de la adopción de la entrega continua. ^{[ 21 ]}

Las siguientes prácticas pueden mejorar la productividad de las canalizaciones , especialmente en sistemas alojados en la nube : ^{[ 22 ] [ 23 ] [ 24 ]}

• Número de pipelines : Los equipos pequeños pueden ser más productivos al tener un único repositorio y un único pipeline. En cambio, las organizaciones más grandes pueden tener repositorios y pipelines separados para cada equipo, o incluso repositorios y pipelines separados para cada servicio dentro de un equipo.
• Permisos : En el contexto de los permisos relacionados con las canalizaciones , cumplir con el principio de mínimo privilegio puede resultar complicado debido a la naturaleza dinámica de la arquitectura . Los administradores pueden optar por permisos más permisivos, implementando al mismo tiempo controles de seguridad compensatorios para minimizar el impacto.

DevOps es un enfoque de ingeniería de software que se centra en el cambio cultural, específicamente en la colaboración de los diversos equipos involucrados en la entrega de software (desarrolladores, operaciones, control de calidad, administración, etc.), así como en la automatización de los procesos en la entrega de software. ^{[ 25 ] [ 26 ] [ 27 ]}

El despliegue continuo es un enfoque de ingeniería de software que utiliza despliegues de software automatizados. ^{[ 21 ]} En él, el software se produce en ciclos cortos, pero a través de despliegues de software automatizados incluso a producción en lugar de requerir un "clic de botón" para ese último paso. ^{[ 1 ] : 52} Por lo tanto, el despliegue continuo puede considerarse una forma más sofisticada de automatización. ^{[ 28 ]} La literatura académica diferencia entre entrega continua y despliegue continuo según el método de despliegue; manual vs. automatizado. ^{[ 2 ] [ 29 ]}

• Humble, Jez; Farley, David (2010). Entrega continua: Lanzamientos de software fiables mediante la automatización de la compilación, las pruebas y la implementación . Addison-Wesley. ISBN 978-0-321-60191-9.
• Wolff, Eberhard (2017). Guía práctica para la entrega continua . Addison-Wesley. ISBN 978-0-134-69147-3.

• Prácticas de entrega continua ^{[ 1 ]}