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 se pueda lanzar de manera confiable en cualquier momento y, al lanzar el software, sin hacerlo manualmente. [1] [2] Tiene como objetivo construir, probar y lanzar software con mayor velocidad y frecuencia. El enfoque ayuda a reducir el costo, el tiempo y el riesgo de realizar cambios al permitir más actualizaciones incrementales para las aplicaciones en producción. Un proceso de implementación sencillo y repetible es importante para la entrega continua.
El CD contrasta con la implementación continua , un enfoque similar en el que el software también se produce en ciclos cortos pero a través de implementaciones automatizadas en lugar de manuales.
Relación con DevOps
La entrega continua y DevOps son similares en sus significados y, a menudo, se combinan, pero son dos conceptos diferentes. [3] DevOps tiene un alcance más amplio, [4] y se centra en el cambio cultural, específicamente la colaboración de los diversos equipos involucrados en la entrega de software (desarrolladores, operaciones, aseguramiento de la calidad, gestión, etc.), así como en la automatización de los procesos. en la entrega de software. [4] La entrega continua, por otro lado, es un enfoque para automatizar el aspecto de la entrega y se centra en reunir diferentes procesos y ejecutarlos con mayor rapidez y frecuencia. [5] Por lo tanto, DevOps puede ser un producto de entrega continua y el CD fluye directamente hacia DevOps.
Relación con el despliegue continuo
La entrega continua es la capacidad de entregar software que se puede implementar en cualquier momento mediante lanzamientos manuales; esto contrasta con la implementación continua que utiliza implementaciones automatizadas. [6] Según Martin Fowler , el despliegue continuo requiere una entrega continua. [7] La literatura académica diferencia entre los dos enfoques según el método de implementación; manual vs. automatizado. [2] [8]
Principios
Golosinas entrega continua la noción común de un oleoducto despliegue [9] como una magra Poka-Yoke : [10] un conjunto de validaciones a través del cual una pieza de software deben pasar en su camino hacia la liberación . El código se compila si es necesario y luego se empaqueta en un servidor de compilación cada vez que se confirma un cambio en un repositorio de control de código fuente , luego se prueba mediante una serie de técnicas diferentes (posiblemente incluyendo pruebas manuales) antes de que se pueda marcar como liberable.
Los desarrolladores acostumbrados a un ciclo de tiempo prolongado 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 ser entregada a los clientes en cualquier momento. Los patrones, como los de alternancia de funciones, pueden resultar muy útiles para la confirmación temprana de código que aún no está listo para su uso por parte de 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. [11] Otras técnicas útiles para desarrollar código de forma 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 El artefacto liberable debe construirse al principio del proceso de CD a partir de una única rama de código si se va a pasar por todas las fases de la canalización. [ aclaración necesaria ]
Canalización de implementación
La entrega continua se habilita a través de la canalización de implementación. El propósito de la canalización de implementación tiene tres componentes: visibilidad, comentarios e implementación continua. [12]
- Visibilidad : todos los aspectos del sistema de entrega, incluidos la construcció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.
Herramientas / tipos de herramientas
La entrega continua lleva la automatización desde el control de la fuente hasta la producción. Hay varias herramientas que ayudan a lograr todo o parte de este proceso. [13] Estas herramientas son parte del proceso de implementación que incluye la entrega continua. Los tipos de herramientas que ejecutan varias partes del proceso incluyen: integración continua , automatización de lanzamiento de aplicaciones , automatización de compilaciones , gestión del ciclo de vida de las aplicaciones . [14]
Arquitectura para la entrega continua
Para practicar la entrega continua de manera efectiva, las aplicaciones de software deben cumplir con un conjunto de requisitos arquitectónicamente significativos (ASR), como la capacidad de implementación, la modificabilidad y la capacidad de prueba. [15] Estos ASR requieren una alta prioridad y no se pueden negociar a la ligera.
Los microservicios se utilizan a menudo en la arquitectura para la entrega continua. [16] El uso de microservicios puede aumentar la capacidad de implementación y modificación de un sistema de software. Las mejoras de implementación observadas incluyen: independencia de implementación, tiempo de implementación más corto, procedimientos de implementación más simples y 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 de atributos de calidad incrementales y actualizaciones de idiomas y bibliotecas más fáciles. [dieciséis]
Implementación y uso
El libro 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. Actualmente, las empresas están implementando estos principios de entrega continua y mejores prácticas. La diferencia en los dominios, por ejemplo, médico frente a web, sigue siendo significativa y afecta la implementación y el uso. [17] Las empresas bien conocidas que tienen este enfoque incluyen Yahoo! , [18] Amazon , [19] Facebook , [20] Google , [21] Paddy Power [1] y Wells Fargo . [22]
Beneficios y obstáculos
Se han informado varios beneficios de la entrega continua. [1] [17]
- Tiempo de comercialización acelerado: CD permite que una organización entregue el valor comercial inherente a las nuevas versiones 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 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 crear el producto adecuado.
- Productividad y eficiencia mejoradas: ahorros de tiempo significativos para desarrolladores, probadores, 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 CD, 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, el número 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, reduciendo 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.
- Mayor satisfacción del cliente: se logra un mayor nivel de satisfacción del cliente.
También se han investigado obstáculos. [17]
- Preferencias del cliente: algunos clientes no desean actualizaciones continuas de sus sistemas. Esto es especialmente cierto en las etapas críticas de sus operaciones.
- Restricciones de dominio: en algunos dominios, como el de telecomunicaciones y médico, las regulaciones requieren pruebas exhaustivas antes de que se permita que las nuevas versiones entren en la fase de operaciones.
- Falta de automatización de pruebas: la falta de automatización de pruebas conduce a la 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 se deslicen 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 humanos en el circuito, lo que ralentiza el proceso de entrega.
Chen planteó y elaboró otros ocho desafíos de adopción. [6] Estos desafíos se encuentran en las áreas de estructura organizativa, procesos, herramientas, infraestructura, sistemas heredados, arquitectura para CD, 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 la entrega continua. [6]
Estrategia | Descripción |
---|---|
Vender CD como analgésico | Identifique los puntos débiles de cada parte interesada que el CD puede resolver y venda el CD como analgésico a esa parte interesada. Esta estrategia ayuda a lograr la aceptación de la amplia gama de partes interesadas que requiere la implementación de un CD. |
Equipo dedicado con miembros multidisciplinarios | Sin un equipo dedicado, puede ser difícil progresar porque a menudo se asigna a los empleados a trabajar en otras corrientes de valor. Un equipo multidisciplinario no solo proporciona la amplia gama de habilidades necesarias para la implementación de CD, sino que también facilita la comunicación con los equipos relacionados. |
Entrega continua de entrega continua | Organice la implementación de CD de una manera que brinde valor a la empresa lo antes posible, incorporando más proyectos gradualmente, en pequeños incrementos y, finalmente, implementando CD en toda la organización. Esta estrategia ayuda a justificar la inversión requerida al hacer visibles los beneficios concretos a lo largo del camino. Los beneficios visibles, a su vez, ayudan a lograr el apoyo y la inversión sostenidos de la compañía necesarios para sobrevivir el largo y arduo viaje hacia el CD. |
Comenzando con aplicaciones sencillas pero importantes | Al seleccionar las primeras aplicaciones para migrar a CD, elija las que sean fáciles de migrar pero que sean importantes para la empresa. Ser fácil de migrar ayuda a demostrar los beneficios de CD rápidamente, lo que puede evitar que se elimine la iniciativa de implementación. Ser importante para el negocio ayuda a asegurar los recursos necesarios, demuestra un valor claro e indiscutible y aumenta la visibilidad del CD en la organización. |
Esqueleto de canalización de Visual CD | Proporcione a un equipo un esqueleto de canalización de CD visual que tenga la vista de canalización de CD completo pero con etapas vacías para aquellos que aún no pueden implementar. Esto ayuda a desarrollar una mentalidad de CD y mantener el impulso para la adopción de CD. El esqueleto de la canalización es especialmente útil cuando la migración del equipo a CD requiere un gran esfuerzo y cambios de mentalidad durante un largo período de tiempo. |
Gota de expertos | Asigne a un experto en CD para que se una a proyectos difíciles como miembro senior del equipo de desarrollo. Tener al experto en el equipo ayuda a generar la motivación y el impulso para pasar al CD desde dentro del equipo. También ayuda a mantener el impulso cuando la migración requiere un gran esfuerzo y un largo período de tiempo. |
Ver también
- Gestión del ciclo de vida de las aplicaciones
- Automatización de lanzamiento de aplicaciones
- Gestión de edificios
- Gestión del cambio
- CI / CD
- Automatización continua de la configuración
- Integración continua
- Prueba continua
- DevOps
- Gestión de la liberación
- Gestión de configuración de software
- Control de versiones
- WinOps
Otras lecturas
- Humilde, Jez; Farley, David (2010). Entrega continua: Versiones de software confiables a través de la automatización de la construcció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
- ^ a b c 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 .
- ^ a b Shahin, Mojtaba; Ali Babara, Muhammad; Zhu, Liming (2017). "Integración continua, entrega y despliegue: 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 .
- ^ Hammond, Jeffrey (9 de septiembre de 2011). "La relación entre DevOps y entrega continua" . Investigación de Forrester . Guardabosque.
- ^ a b 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. ISBN 978-0-321-60191-9.
- ^ Swartout, Paul (2012). Entrega continua y DevOps: una guía de inicio rápido . Packt Publishing. ISBN 978-1849693684.
- ^ a b c Chen, Lianping (2017). "Entrega continua: superación de los desafíos de la adopción" . Revista de sistemas y software . 128 : 72–86. doi : 10.1016 / j.jss.2017.02.013 .
- ^ "bliki: ContinuousDelivery" . martinfowler.com . Consultado el 29 de octubre de 2015 .
- ^ 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 implementación continua". 2017 Simposio Internacional ACM / IEEE 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. S2CID 3479812 .
- ^ Humble, J .; Leer, C .; Norte, 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 . ISBN 0-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 Continua . Nueva York, NY: Association for Computing Machinery. págs. 1–9. doi : 10.1145 / 2593812.2593813 . hdl : 10344/3896 . ISBN 978-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). "Despliegue continuo con MongoDB en Kitchensurfing" . slideshare.net . Consultado el 3 de enero de 2014 .
- ^ Duvall, Paul (2012). "Entrega continua: patrones y anti-patrones en el ciclo de vida del software" (PDF) . Refcardz . 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 una entrega continua . La 12a Conferencia de Trabajo IEEE / IFIP sobre Arquitectura de Software (WICSA 2015) . Montreal, Canadá: IEEE. doi : 10.1109 / WICSA.2015.23 .
- ^ a b Chen, Lianping (2018). Microservicios: Arquitectura para entrega continua y DevOps . La Conferencia Internacional IEEE sobre Arquitectura de Software (ICSA 2018) . IEEE.
- ^ a b c Leppänen, M .; Mäkinen, S .; Pagels, M .; Eloranta, vicepresidente; Itkonen, J .; Mäntylä, MV; Männistö, T. (1 de marzo de 2015). "Las carreteras y caminos rurales para el 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.
- ^ "Velocidad 2011: Jon Jenkins," Cultura de la velocidad " " . youtube.com . 20 de junio de 2011.
- ^ "Lanzamiento rápido a gran escala" . 2017-08-31.
- ^ Humble, Jez (13 de febrero de 2014). "El caso de la entrega continua" . Thoughtworks.com . Consultado el 16 de julio de 2014 .
- ^ jFrog (diciembre de 2014). "Revolución-de-integración-continua-2014-años" .