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, lo que garantiza que el software pueda lanzarse de manera confiable en cualquier momento. [1] [2] Tiene como objetivo crear, probar y lanzar software con mayor velocidad y frecuencia. El enfoque ayuda a reducir el costo, el tiempo y el riesgo de entregar cambios al permitir actualizaciones más incrementales a 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 una tubería de implementación [3] como un Poka-Yoke esbelto : [4] 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 un servidor de compilación lo empaqueta cada vez que se confirma un cambio en un repositorio de control de fuente , luego se prueba mediante una serie de técnicas diferentes (posiblemente incluidas las pruebas manuales) antes de que pueda marcarse como liberable.
Los desarrolladores acostumbrados a un tiempo de ciclo largo pueden necesitar cambiar su mentalidad cuando trabajan en un entorno de CD. Cualquier confirmación de código puede ser lanzada a los clientes en cualquier momento. Patrones como los conmutadores de funciones pueden ser muy útiles para confirmar código de manera temprana que aún no está listo para que lo usen los usuarios finales. 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. [5] Otras técnicas útiles para desarrollar código de manera aislada, como la ramificación de código , no son 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 que se pueda lanzar debe construirse temprano en el proceso de CD a partir de una sola rama de código si se va a pasar por todas las fases del proceso. [ aclaración necesaria ]
Canalización de implementación
La entrega continua se habilita a través del flujo de implementación. El propósito del flujo 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, la implementación, las pruebas y el lanzamiento, son visibles para todos los miembros del equipo para promover la colaboración.
Retroalimentación : 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 capacidad de implementación, modificabilidad y capacidad de prueba. [9] Estos ASR requieren una alta prioridad y no se pueden sacrificar 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 implementación, menor tiempo de implementación, procedimientos de implementación más simples e implementación sin tiempo de inactividad. Las mejoras observadas en la capacidad de modificación 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 lenguaje y biblioteca. [10]
Implementación y uso
El libro original en CD 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 frente a web, sigue siendo significativa y afecta a la implementación y el uso. [11] Entre las empresas conocidas que tienen este enfoque se incluyen Yahoo !, [12] Amazon , [13] Facebook , [14] Google , [15] Paddy Power [1] y Wells Fargo . [16]
Beneficios y obstáculos
Se han reportado varios beneficios de la entrega continua. [1] [11]
Aceleración del tiempo de comercialización : la entrega continua permite que una organización entregue el valor comercial inherente a las nuevas versiones de software a los clientes con mayor rapidez. Esta capacidad ayuda a la empresa a mantenerse un paso por delante de la competencia.
Desarrollar el producto adecuado: los lanzamientos frecuentes permiten a los equipos de desarrollo de aplicaciones obtener comentarios de los usuarios con mayor rapidez. Esto les permite trabajar solo en las funciones útiles. Si descubren que una función no es útil, no dedican más esfuerzo a ella. Esto les ayuda a desarrollar el producto adecuado.
Productividad y eficiencia mejoradas: ahorro de tiempo significativo para desarrolladores, evaluadores, ingenieros de operaciones, etc. mediante la automatización.
Versiones confiables: los riesgos asociados con una versión han disminuido significativamente y el proceso de versión 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 los scripts ya se han descubierto. Con versiones más frecuentes, la cantidad de cambios de código en cada versión disminuye. Esto hace que sea más fácil encontrar y solucionar cualquier problema que ocurra, lo que reduce el tiempo en el que tienen un impacto.
Calidad del producto mejorada : la cantidad de errores abiertos e incidentes de producción ha disminuido significativamente.
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, los ferrocarriles y las industrias pesadas, las regulaciones requieren pruebas del lado del cliente o incluso en el sitio de las nuevas versiones.
Falta de automatización de pruebas: la falta de automatización de pruebas genera una falta de confianza en 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 un oráculo humano : no todos los atributos de calidad se pueden verificar con la automatización. Estos atributos requieren la participación de humanos, 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 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 la adopción de la 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 en la colaboración de los distintos 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. [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 ella, 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 un "clic de un botón" para ese ú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 e implementación continua según el método de implementación; manual vs. automatizado. [2] [22]
Humble, Jez; Farley, David (2010). Entrega continua: lanzamientos de software confiables mediante automatización de la creació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". IEEE Software . 32 (2): 50–54. doi :10.1109/MS.2015.27. S2CID 1241241.
^ ab Shahin, Mojtaba; Ali Babara, Muhammad; Zhu, Liming (2017). "Integración, entrega e implementación continuas: una revisión sistemática de enfoques, herramientas, desafíos y prácticas". IEEE Access . 5 : 3909–3943. arXiv : 1703.07019 . Bibcode :2017arXiv170307019S. doi :10.1109/ACCESS.2017.2685629. S2CID 11638909.
^ Humble, J.; Read, C.; North, D. (2006). "La línea de producción de implementación". Agile 2006 (Agile'06) . págs. 113–118. doi :10.1109/AGILE.2006.53. ISBN0-7695-2562-8.S2CID16572138 .
^ Fitzgerald, Brian (3 de junio de 2014). Ingeniería de software continua y más allá: tendencias y desafíos (PDF) . 1.er taller internacional sobre ingeniería de software continua rápida. Nueva York, NY: Association for Computing Machinery. págs. 1–9. doi :10.1145/2593812.2593813. hdl : 10344/3896 . ISBN .978-1-4503-2856-2Archivado 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 flujo 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". Dr. Dobb's the World of Software Development . 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 la entrega continua y DevOps. 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.
^ "Implementación de la entrega continua en Yahoo!". confreaks.tv . 23 de octubre de 2013.
^ "Velocity 2011: Jon Jenkins, "Cultura de la velocidad"". youtube.com . 20 de junio de 2011.
^ "Liberación rápida a escala masiva". 31 de agosto de 2017.
^ Humble, Jez (13 de febrero de 2014). "The Case for Continuous Delivery" (El caso de la entrega continua). thoughtworks.com . Consultado el 16 de julio de 2014 .
^ jFrog (diciembre de 2014). "2014, año de revolución de integración continua".
^ abc Chen, Lianping (2017). "Entrega continua: superando los desafíos de adopción". Revista de sistemas y software . 128 : 72–86. doi : 10.1016/j.jss.2017.02.013 .
^ Humble, Jez; Farley, David (2011). Entrega continua: lanzamientos de software confiables mediante automatización de la creació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 la entrega continua". Forrester Research . Forester.
^ Swartout, Paul (2012). Entrega continua y DevOps: una guía de inicio rápido . Packt Publishing. ISBN978-1849693684.
^ "Implementación continua: una guía esencial". IBM . 2019-10-02 . Consultado el 2022-11-28 . La implementación continua es el resultado natural de una entrega continua bien realizada. Con el tiempo, la aprobación manual aporta poco o ningún valor y simplemente hace que las cosas se pongan en marcha lentamente. En ese momento, se elimina y la entrega continua se convierte en implementación continua.
^ Shahin, Mojtaba; Babar, Muhammad Ali; Zahedi, Mansooreh; 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 de 2017 sobre ingeniería y medición de software empírico (ESEM) . págs. 111–120. doi :10.1109/ESEM.2017.18. ISBN .978-1-5090-4039-1. Número de identificación del sujeto 3479812.
