Enfoque de ingeniería de software de ciclos cortos.
La entrega continua ( CD ) es un enfoque de ingeniería de software en el que los equipos producen software en ciclos cortos, garantizando que el software pueda lanzarse de manera confiable en cualquier momento y, siguiendo un proceso a través de un "entorno similar a la producción", sin hacerlo manualmente. [1] [2] Su objetivo es construir, probar y lanzar software con mayor velocidad y frecuencia. El enfoque ayuda a reducir el costo, el tiempo, [ cita necesaria ] y el riesgo de realizar cambios al permitir actualizaciones más incrementales de las aplicaciones en producción. Un proceso de implementación sencillo y repetible es importante para la entrega continua.
Principios
La entrega continua trata la noción común de un proceso de implementación [3] como un Poka-Yoke eficiente : [4] un conjunto de validaciones a través de las cuales una pieza de software debe pasar en su camino hacia su lanzamiento . El código se compila si es necesario y luego lo empaqueta un servidor de compilación cada vez que se confirma un cambio en un repositorio de control de código fuente y luego se prueba mediante varias técnicas diferentes (posiblemente incluidas pruebas manuales) antes de que pueda marcarse como liberable.
Los desarrolladores acostumbrados a ciclos largos pueden necesitar cambiar su forma de pensar cuando trabajan en un entorno de CD. Es importante comprender que cualquier confirmación de código puede entregarse a los clientes en cualquier momento. Los patrones como la alternancia de funciones pueden ser muy útiles para confirmar código de manera temprana que aún no está listo para ser utilizado por los usuarios finales. El uso de NoSQL puede eliminar el paso de las migraciones de datos y los cambios de esquema, a menudo pasos manuales o excepciones a un flujo de trabajo de entrega continua. [5] Otras técnicas útiles para desarrollar código de forma aislada, como la bifurcación de código, no están obsoletas en el mundo del CD, pero deben adaptarse para ajustarse a los principios del CD; por ejemplo, ejecutar múltiples bifurcaciones de código de larga duración puede resultar poco práctico, ya que El artefacto liberable debe construirse temprano en el proceso de CD a partir de una única rama de código si se desea pasar por todas las fases del proceso. [ se necesita aclaración ]
Canal de implementación
La entrega continua se habilita a través del proceso de implementación. El propósito del proceso de implementación tiene tres componentes: visibilidad, retroalimentación e implementación continua. [6]
Visibilidad : todos los aspectos del sistema de entrega, incluida la creación, implementación, prueba y lanzamiento, son visibles para todos los miembros del equipo para promover la colaboración.
Comentarios : los miembros del equipo se enteran de los problemas lo antes posible cuando ocurren para poder solucionarlos lo más rápido posible.
Implementación continua : a través de un proceso totalmente automatizado, puede implementar y lanzar cualquier versión del software en cualquier entorno.
Para practicar la entrega continua de manera efectiva, las aplicaciones de software deben cumplir un conjunto de requisitos arquitectónicamente significativos (ASR), como la capacidad de implementación, la modificabilidad y la capacidad de prueba. [9] Estos ASR requieren una alta prioridad y no pueden negociarse a la ligera.
Los microservicios se utilizan a menudo en la arquitectura para la entrega continua. [10] El uso de microservicios puede aumentar la capacidad de implementación y modificabilidad de un sistema de software. Las mejoras observadas en la capacidad de implementación incluyen: independencia de la implementación, tiempo de implementación más corto, procedimientos de implementación más simples y implementación sin tiempo de inactividad. Las mejoras de modificabilidad observadas incluyen: tiempo de ciclo más corto para pequeños cambios funcionales incrementales, cambios de selección de tecnología más fáciles, cambios incrementales de atributos de calidad y actualizaciones de biblioteca y lenguaje más sencillas. [10]
Implementación y uso
El libro en CD original escrito por Jez Humble y David Farley (2010) popularizó el término; sin embargo, desde su creación la definición ha seguido avanzando y ahora tiene un significado más desarrollado. Hoy en día, las empresas están implementando estos principios y mejores prácticas de entrega continua. La diferencia en los dominios, por ejemplo, médico versus web, sigue siendo significativa y afecta la implementación y el uso. [11] Las empresas conocidas que tienen este enfoque incluyen Yahoo! , [12] Amazon , [13] Facebook , [14] Google , [15] Paddy Power [1] y Wells Fargo . [dieciséis]
Beneficios y obstáculos
Se han informado varios beneficios de la entrega continua. [1] [11]
Tiempo de comercialización acelerado : la entrega continua permite a una organización entregar el valor comercial inherente a los nuevos lanzamientos de software a los clientes más rápidamente. Esta capacidad ayuda a la empresa a mantenerse un paso por delante de la competencia.
Creación del producto adecuado: los lanzamientos frecuentes permiten a los equipos de desarrollo de aplicaciones obtener comentarios de los usuarios más rápidamente. Esto les permite trabajar sólo en las funciones útiles. Si descubren que una función no es útil, no dedican más esfuerzos a ella. Esto les ayuda a crear el producto adecuado.
Mejora de la productividad y la eficiencia: ahorro de tiempo significativo para desarrolladores, evaluadores, ingenieros de operaciones, etc. a través de la automatización.
Lanzamientos confiables: los riesgos asociados con un lanzamiento han disminuido significativamente y el proceso de lanzamiento se ha vuelto más confiable. Con la entrega continua, el proceso de implementación y los scripts se prueban repetidamente antes de la implementación en producción. Por lo tanto, la mayoría de los errores en el proceso de implementación y en los scripts ya se han descubierto. Con lanzamientos más frecuentes, la cantidad de cambios de código en cada lanzamiento disminuye. Esto facilita la búsqueda y solución de cualquier problema que surja, reduciendo el tiempo en el que tienen un impacto.
Calidad del producto mejorada : el número de errores abiertos e incidentes de producción ha disminuido significativamente.
Preferencias del cliente: algunos clientes no quieren actualizaciones frecuentes de sus sistemas.
Restricciones de dominio: en algunos dominios, como telecomunicaciones, medicina, aviónica, ferrocarriles e industrias pesadas, las regulaciones exigen pruebas de nuevas versiones por parte del cliente o incluso in situ.
Falta de automatización de pruebas: la falta de automatización de pruebas genera una falta de confianza del desarrollador 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 pasen al entorno de producción.
Pruebas que necesitan un oráculo humano : no todos los atributos de calidad se pueden verificar con la automatización. Estos atributos requieren que los seres humanos estén al tanto, lo que ralentiza el proceso de entrega.
Chen planteó y explicó otros ocho desafíos de adopción. [17] 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.
Estrategias para superar los desafíos de la adopción
Se han informado varias estrategias para superar los desafíos de adopción de entrega continua. [17]
Relación con DevOps
DevOps es un enfoque de ingeniería de software que se centra en el cambio cultural, específicamente la colaboración de los diversos equipos involucrados en la entrega de software (desarrolladores, operaciones, control de calidad, gestión, etc.), así como la automatización de los procesos en la entrega de software. [18] [19] [20]
Relación con la implementación continua
La implementación continua es un enfoque de ingeniería de software que utiliza implementaciones de software automatizadas. [17]
En él, el software se produce en ciclos cortos, pero a través de implementaciones de software automatizadas incluso hasta la producción, en lugar de requerir "hacer clic en un botón" para el último paso. [1] : 52 Por lo tanto, la implementación continua puede considerarse una forma más sofisticada de automatización. [21]
La literatura académica diferencia entre entrega continua y despliegue continuo según el método de despliegue; manual versus automatizado. [2] [22]
Humilde, Jez; Farley, David (2010). Entrega continua: lanzamientos de software confiables mediante la automatización de compilación, prueba e implementación . Addison-Wesley. ISBN 978-0-321-60191-9.
Wolff, Eberhard (2017). Una guía práctica para la entrega continua. Addison-Wesley. ISBN 978-0-134-69147-3.
Referencias
^ abcd Chen, Lianping (2015). "Entrega continua: enormes beneficios, pero también desafíos". Software IEEE . 32 (2): 50–54. doi :10.1109/MS.2015.27. S2CID 1241241.
^ ab Shahin, Mojtaba; Ali Babara, Mahoma; Zhu, Liming (2017). "Integración, entrega e implementación continuas: una revisión sistemática de enfoques, herramientas, desafíos y prácticas". Acceso IEEE . 5 : 3909–3943. arXiv : 1703.07019 . Código Bib : 2017arXiv170307019S. doi :10.1109/ACCESS.2017.2685629. S2CID 11638909.
^ Humilde, J.; Leer, C.; Norte, D. (2006). "La línea de producción de implementación". Ágil 2006 (Ágil'06) . págs. 113-118. doi :10.1109/AGILE.2006.53. ISBN0-7695-2562-8. S2CID 16572138.
^ Fitzgerald, Brian (3 de junio de 2014). Ingeniería de software continua y más allá: tendencias y desafíos (PDF) . 1er Taller Internacional de Ingeniería de Software Rápida y Continua. Nueva York, NY: Asociación de Maquinaria de Computación. págs. 1–9. doi :10.1145/2593812.2593813. hdl : 10344/3896 . ISBN978-1-4503-2856-2. Archivado desde el original (PDF) el 25 de octubre de 2014 . Consultado el 24 de octubre de 2014 .
^ Kluge, Lars (12 de septiembre de 2013). "Implementación continua con MongoDB en Kitchensurfing". slideshare.net . Consultado el 3 de enero de 2014 .
^ Duvall, Paul (2012). "Entrega continua: patrones y antipatrones en el ciclo de vida del software" (PDF) . Refcardz . Archivado desde el original (PDF) el 19 de junio de 2018 . Consultado el 9 de octubre de 2015 .
^ Phillips, Andrew (29 de julio de 2014). "El canal de entrega continua: qué es y por qué es tan importante en el desarrollo de software". DevOps.com . Archivado desde el original el 28 de septiembre de 2015 . Consultado el 9 de octubre de 2015 .
^ Binstock, Andrew (16 de septiembre de 2014). "Entrega continua: el sucesor ágil". El mundo del desarrollo de software del Dr. Dobb . San Francisco: UBM.
^ Chen, Lianping (2015). Hacia una arquitectura para la entrega continua . La 12ª Conferencia de Trabajo IEEE/IFIP sobre Arquitectura de Software (WICSA 2015). Montreal, Canadá: IEEE. doi :10.1109/WICSA.2015.23.Archivado el 13 de noviembre de 2018 en Wayback Machine.
^ ab Chen, Lianping (2018). Microservicios: arquitectura para entrega continua y DevOps. La Conferencia Internacional IEEE sobre Arquitectura de Software (ICSA 2018). IEEE.
^ abc Leppänen, M.; Makinen, S.; Pagels, M.; Eloranta, vicepresidente; Itkonen, J.; Mäntylä, MV; Männistö, T. (1 de marzo de 2015). "Las carreteras y caminos rurales hacia un despliegue continuo". Software IEEE . 32 (2): 64–72. doi :10.1109/MS.2015.50. ISSN 0740-7459. S2CID 18719684.
^ "¡Implementando la entrega continua en Yahoo!". confreaks.tv . 23 de octubre de 2013.
^ "Velocity 2011: Jon Jenkins", Cultura Velocity"". youtube.com . 20 de junio de 2011.
^ "Liberación rápida a escala masiva". 2017-08-31.
^ Humilde, Jez (13 de febrero de 2014). "El caso de la entrega continua". pensamientoworks.com . Consultado el 16 de julio de 2014 .
^ jFrog (diciembre de 2014). "Revolución-de-integración-continua-de-2014-años".
^ abc Chen, Lianping (2017). "Entrega continua: superar los desafíos de la adopción". Revista de Sistemas y Software . 128 : 72–86. doi : 10.1016/j.jss.2017.02.013 .
^ Humilde, Jez; Farley, David (2011). Entrega continua: lanzamientos de software confiables a través de la automatización de compilación, prueba e implementación . Pearson Education Inc. ISBN978-0-321-60191-9.
^ Hammond, Jeffrey (9 de septiembre de 2011). "La relación entre DevOps y entrega continua". Investigación de Forrester . Guardabosque.
^ Swartout, Paul (2012). Entrega continua y DevOps: una guía de inicio rápido . Publicación de paquetes. ISBN978-1849693684.
^ "Implementación continua: una guía esencial". IBM . 2019-10-02 . Consultado el 28 de noviembre de 2022 . La implementación continua es el resultado natural de una entrega continua bien realizada. Al final, la aprobación manual aporta poco o ningún valor y simplemente se reduce lentamente. En ese punto, se elimina y la entrega continua se convierte en implementación continua.
^ Shahin, Mojtaba; Babar, Muhammad Ali; Zahedi, Mansureh; Zhu, Liming (2017). "Más allá de la entrega continua: una investigación empírica de los desafíos de la implementación continua". Simposio internacional ACM/IEEE 2017 sobre ingeniería y medición de software empírico (ESEM) . págs. 111-120. doi :10.1109/ESEM.2017.18. ISBN978-1-5090-4039-1. S2CID 3479812.
