¿Cuál es la diferencia entre estos tres términos? Mi universidad proporciona las siguientes definiciones:
La integración continua básicamente significa que las copias de trabajo del desarrollador están sincronizadas con una línea principal compartida varias veces al día.
La entrega continua se describe como la evolución lógica de la integración continua: ¡Siempre se puede poner un producto en producción!
La implementación continua se describe como el siguiente paso lógico después de la entrega continua: ¡ Implemente automáticamente el producto en producción cada vez que pase el control de calidad!
También proporcionan una advertencia: a veces, el término "Implementación continua" también se utiliza si puede implementar continuamente en el sistema de prueba.
Todo esto me deja confundido. ¡Cualquier explicación que sea un poco más detallada (o que venga con un ejemplo) es apreciada!
Respuestas:
Integración continua
Estoy de acuerdo con la definición de tu universidad. La integración continua es una estrategia sobre cómo un desarrollador puede integrar el código a la línea principal de forma continua, en lugar de hacerlo con frecuencia.
Puede afirmar que es simplemente una estrategia de ramificación en su sistema de control de versiones.
Tiene que ver con el tamaño de las tareas que asigna a un desarrollador; Si se estima que una tarea demora entre 4 y 5 días-hombre, el desarrollador no tendrá incitación a entregar nada durante los próximos 4-5 días, porque aún no ha terminado nada.
Entonces el tamaño importa:
El tamaño ideal de la tarea no es más grande que un día de trabajo. De esta forma, un desarrollador tendrá naturalmente al menos una integración por día.
Entrega continua
Básicamente, hay tres escuelas dentro de la entrega continua:
La entrega continua es una extensión natural de la integración continua
Esta escuela, analiza la serie de firmas "Martin Fowler" de Addison-Wesley y asume que desde el lanzamiento de 2007 se llamó "Integración continua" y la que siguió en 2011 se llamó "Entrega continua" probablemente sean volúmenes 1 + 2 de la misma idea conceptual que tiene que ver con algo continuo .
La entrega continua tiene que ver con el desarrollo ágil de software
Esta escuela se compensa con la idea de que la entrega continua se trata de ser capaz de apoyar los principios en el movimiento ágil, no solo como una idea conceptual o una carta de intención, sino de verdad, en la vida real.
Tomando en cuenta el primer principio en el Manifiesto Ágil donde el término "entrega continua" se usa por primera vez:
Esta escuela afirma que "Entrega continua" es un paradigma que abarca todo lo necesario para implementar una verificación automatizada de su "definición de hecho" .
Esta escuela acepta que "Entrega continua" y la palabra de moda o megatendencia "DevOps" son las dos caras de la misma moneda, en el sentido de que ambos intentan adoptar o encapsular este nuevo paradigma o enfoque y no solo una técnica.
La entrega continua es sinónimo de implementación continua
La tercera escuela defiende que el Despliegue continuo y la Entrega continua se pueden usar indistintamente para significar lo mismo.
Cuando algo está listo en manos de los desarrolladores, se entrega inmediatamente a los usuarios finales, lo que en la mayoría de los casos significará que debe implementarse en el entorno de producción. Por lo tanto, "Implementar" y "Entregar" significa lo mismo.
A qué escuela unirte
Su universidad claramente se unió a la primera escuela y afirma que nos estamos refiriendo al volumen 1 + 2 de la misma serie de publicaciones. Mi opinión es que este es un mal uso del término Entrega continua.
Personalmente defiendo el entendimiento de que la entrega continua está relacionada con la implementación de un apoyo de la vida real para las ideas y conceptos establecidos por el movimiento ágil. Así que me uní a la escuela que dice que el término abarca un paradigma completo, como "DevOps".
La escuela que usa la entrega como sinónimo de implementación es principalmente defendida por los proveedores de herramientas que crean consolas de implementación, tratando de obtener un poco de entusiasmo por el uso más extendido del término Entrega continua .
Despliegue continuo
El enfoque en la implementación continua es principalmente relevante en dominios donde el acceso del usuario final a las actualizaciones de software se basa en la actualización de alguna fuente centralizada para esta información y donde esta fuente centralizada no siempre es fácil de actualizar porque es monolítica o tiene (también) alta coherencia por naturaleza (web, SOA, bases de datos, etc.).
Para muchos dominios que producen software donde no hay una fuente centralizada de información (dispositivos, productos de consumo, instalaciones de clientes, etc.) o donde la fuente centralizada de información es fácil de actualizar (la aplicación almacena sistemas de gestión de artefactos, repositorios de código abierto, etc. ), casi no hay exageración sobre el término Despliegue continuo en absoluto. Simplemente se despliegan; No es una gran cosa, no es un dolor que requiere un enfoque especial.
El hecho de que el despliegue continuo no sea algo que sea genéricamente interesante para todos es también un argumento de que la escuela que afirma que "entrega" y "despliegue" son sinónimos lo entendió todo mal. Porque la entrega continua en realidad tiene mucho sentido para todos, incluso si está haciendo software integrado en dispositivos o lanzando complementos de código abierto para un marco.
La definición de su universidad de que el Despliegue continuo es un próximo paso natural de la Entrega continua asume implícitamente que cada entrega que se QA'ed debe estar disponible para los usuarios finales de inmediato, está más cerca de la definición que utiliza mi tribu para describir el término "Continuo Release ", que, a su vez, es otro concepto que tampoco tiene sentido genéricamente para todos.
Un lanzamiento puede ser algo muy estratégico o político y no hay razón para suponer que todos desearían hacer esto todo el tiempo (a menos que sean una librería en línea, un tipo de empresa de servicios de transmisión). Sin embargo, las compañías que no publican todo a ciegas todo el tiempo pueden tener varias razones por las cuales desearían ser maestros de implementación de todos modos, por lo que también lo hacen Implementación continua . No de lanzamiento a producción, sino de candidatos de lanzamiento a entornos de producción .
De nuevo, creo que tu universidad se equivocó. Están confundiendo "Despliegue continuo" con "Lanzamiento continuo".
El despliegue continuo es simplemente la disciplina de poder mover continuamente el resultado de un proceso de desarrollo a un entorno similar a la producción donde las pruebas funcionales se pueden ejecutar a escala completa.
La historia de entrega continua
En la imagen todo cobra vida:
El proceso de integración continua son las dos primeras acciones en el diagrama de transición de estado. que, si tiene éxito, inicia la canalización de entrega continua que implementa la definición de hecho . La implementación es solo una de las muchas acciones que deberán realizarse de forma continua en este proceso. Idealmente, el proceso está automatizado desde el punto en que el desarrollador se compromete con el VCS hasta el punto en que la tubería ha confirmado que tenemos un candidato de lanzamiento válido.
fuente
Ni la pregunta ni las respuestas realmente se ajustan a mi forma simple de pensar en ello. Soy consultor y he sincronizado estas definiciones con varios equipos de Dev y personas de DevOps, pero tengo curiosidad acerca de cómo coincide con la industria en general:
Básicamente pienso en la práctica ágil de entrega continua como un continuo:
No continuo (todo manual) 0% ----> 100% Entrega continua de valor (todo automatizado)
Pasos hacia la entrega continua:
Cero. Nada se automatiza cuando los desarrolladores registran el código ... Tienes suerte si han compilado, ejecutado o realizado alguna prueba antes del check-in.
Compilación continua: compilación automatizada en cada registro, que es el primer paso, pero no hace nada para demostrar la integración funcional del nuevo código.
Integración continua (CI): compilación y ejecución automatizadas de al menos pruebas unitarias para probar la integración del nuevo código con el código existente, pero preferiblemente pruebas de integración (de extremo a extremo).
Implementación continua (CD): implementación automatizada cuando el código pasa CI al menos a un entorno de prueba, preferiblemente en entornos superiores cuando la calidad se prueba a través de CI o marcando un entorno inferior como APROBADO después de la prueba manual. Es decir, las pruebas pueden ser manuales en algunos casos, pero la promoción al siguiente entorno es automática.
Entrega continua: publicación automatizada y lanzamiento del sistema en producción. Este es un CD en producción más cualquier otro cambio de configuración, como la configuración para pruebas A / B, notificación a los usuarios de nuevas funciones, notificación de soporte de nueva versión y notas de cambio, etc.
EDITAR: Me gustaría señalar que hay una diferencia entre el concepto de "entrega continua" como se menciona en el primer principio del Manifiesto Ágil ( http://agilemanifesto.org/principles.html ) y la práctica de la Entrega Continua, como parece ser referenciado por el contexto de la pregunta. El principio de entrega continua es el de esforzarse por reducir el desperdicio de inventario como se describe en Lean thinking ( http://www.miconleansixsigma.com/8-wastes.html ). La práctica de la entrega continua (CD) por parte de equipos ágiles ha surgido en los muchos años desde que se escribió el Manifiesto Ágil en 2001. Esta práctica ágil aborda directamente el principio, aunque son cosas diferentes y aparentemente fáciles de confundir.
fuente
Creo que la definición de Amazon es directa y simple de entender.
" La entrega continua es una metodología de desarrollo de software en la que el proceso de lanzamiento está automatizado. Cada cambio de software se construye, prueba e implementa automáticamente en la producción. Antes del empuje final a la producción, una persona, una prueba automatizada o una regla comercial decide cuándo Debería producirse un empujón final. Aunque cada cambio de software exitoso puede lanzarse inmediatamente a producción con entrega continua, no todos los cambios deben lanzarse de inmediato.
La integración continua es una práctica de desarrollo de software en la que los miembros de un equipo usan un sistema de control de versiones e integran su trabajo con frecuencia en la misma ubicación, como una rama maestra. Cada cambio se crea y verifica mediante pruebas y otras verificaciones para detectar cualquier error de integración lo más rápido posible. La integración continua se centra en la creación y prueba automática de código, en comparación con la entrega continua, que automatiza todo el proceso de lanzamiento del software hasta la producción ".
Consulte http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
fuente
Atlassian publicó una buena explicación sobre la integración continua frente a la entrega continua frente a la implementación continua .
En una palabra:
Integración continua : es una automatización para compilar y probar aplicaciones cada vez que se introducen nuevas confirmaciones en la rama.
Entrega continua : es la integración continua + Implementación de la aplicación en producción "haciendo clic en un botón" (La liberación a los clientes es a menudo, pero a pedido).
Implementación continua : es una entrega continua pero sin intervención humana (la liberación a los clientes está en curso).
fuente
O más de varias veces al día. Tan a menudo como cualquier tarea discreta dada se completa, básicamente. Considere, por ejemplo, un equipo de desarrolladores que trabajan en una sola aplicación empresarial. En muchos entornos, puede suceder lo siguiente:
Estos pueden conducir a problemas. La mala organización del código / tarea conduce a la ramificación, la ramificación conduce a la fusión, la fusión ... conduce al sufrimiento. La integración continua como práctica aborda esto alentando a todos a trabajar desde la misma fuente compartida. Los elementos de trabajo individuales deben ser lo suficientemente discretos como para completarlos en un corto período de tiempo (horas como máximo).
Básicamente, la idea general es integrar un pequeño cambio en una pequeña cantidad de trabajo. Integrar un gran cambio es una cantidad desproporcionadamente grande de trabajo. El conjunto del trabajo de integración es menor si se realiza en pequeños pasos constantes. Esto permite a los desarrolladores dedicar más tiempo a trabajar en funciones visibles para la empresa en lugar de los gastos generales del proceso de desarrollo.
Esto sigue la misma idea de elementos de trabajo discretos y bien definidos. Si hay una única base de código maestra que solo se ajusta en pequeños incrementos mediante características de trabajo completas, probadas y conocidas, entonces esa base de código siempre es estable. Las pruebas automatizadas son clave aquí para poder demostrar esa estabilidad con solo presionar un botón.
Cuanto menos trabajo de estabilización deba realizarse (que, una vez más, es una sobrecarga del proceso de desarrollo y debería eliminarse), más a menudo esa base de código se puede enviar a cualquier entorno dado. En muchas empresas, una implementación puede ser un proceso bastante agotador. Incluso una operación de una semana con todas las manos en la cubierta. Esto es costoso y no produce valor comercial. Al emplear buenas definiciones de elementos de trabajo, pruebas automatizadas efectivas e integración continua, un equipo puede estar en condiciones de automatizar la entrega de la base de código a cualquier entorno dado.
Raramente verá que esto suceda en un entorno empresarial, y es una gran alegría cuando se encuentra. Si la base de código se puede probar y desplegar automáticamente en cualquier entorno dado, entonces, bueno, la producción es un entorno como cualquier otro. Entonces, si el equipo se ha desarrollado hasta este punto, entonces existe un potencial de valor significativo para la empresa al poder siempre implementar actualizaciones en la producción.
Las soluciones de defectos se envían a los clientes más rápido, las nuevas funciones llegan al mercado más rápido, las nuevas ideas se prueban en el mercado en incrementos más pequeños para permitir la redirección de prioridades, etc.
Por ejemplo, supongamos que una empresa tiene una gran idea para una nueva característica en su producto o servicio basado en software. Han investigado un poco, conocen el mercado y creen que esta idea dará como resultado una nueva línea de ingresos sólida. Ahora considere dos opciones para entregar esa característica:
En el primer escenario, si la función no tiene el efecto de mercado deseado, se desperdicia mucho dinero en algo que los clientes realmente no desean. En el segundo escenario, el hecho de que los clientes no lo quieran se determina mucho, mucho antes y el resto del trabajo se prioriza.
En última instancia, estas "cosas continuas" tienen que ver con eliminar la sobrecarga del proceso de desarrollo. Si la línea de ingresos de una empresa es una oferta de servicio particular, idealmente todos sus costos deberían ir a esa oferta. La sobrecarga del proceso de desarrollo (código de fusión, volver a probar las mismas características después de una fusión, tareas de implementación manual, etc.) en realidad no contribuyen al valor del servicio, por lo que estos conceptos buscan eliminar esos costos del proceso.
fuente
Un gráfico puede reemplazar muchas palabras:
¡Disfrutar! :-)
# He actualizado la imagen correcta ...
fuente
Diferencia entre integración continua, entrega continua y despliegue continuo
fuente
Creo que hemos terminado de analizar y quizás complicar un poco el conjunto de palabras "continuo". En este contexto, continuo significa automatización. ¡Para las otras palabras adjuntas a "continuo", use el idioma inglés como guía de traducción y no intente complicar las cosas! En "compilación continua" construimos automáticamente (escribir / compilar / vincular / etc.) nuestra aplicación en algo ejecutable para una plataforma / contenedor / tiempo de ejecución / etc específico. "Integración continua" significa que su nueva funcionalidad prueba y funciona según lo previsto cuando interactúa con otra entidad. Obviamente, antes de que tenga lugar la integración, la construcción debe realizarse y también se utilizarían pruebas exhaustivas para validar la integración. Entonces, en "integración continua" uno usa la automatización para agregar valor a un grupo de funcionalidades existente de una manera que no interrumpe negativamente la funcionalidad existente, sino que se integra muy bien con ella, agregando un valor percibido al conjunto. La integración implica, por su mera definición en inglés, que las cosas se combinan armoniosamente, por lo que en code-talk agrego compilaciones, enlaces, pruebas y funciona perfectamente dentro del conjunto. No llamarías a algo integrado si fallara el producto final, ¿verdad? En nuestro contexto, "implementación continua" es sinónimo de "entrega continua", ya que al final del día hemos brindado funcionalidad a nuestros clientes. Sin embargo, al analizar esto en exceso, podría argumentar que la implementación es un subconjunto de la entrega porque implementar algo no necesariamente significa que lo hicimos. Implementamos el código pero porque no tenemos No nos comunicamos eficazmente con nuestros grupos de interés, ¡no logramos entregar desde una perspectiva comercial! Desplegamos las tropas, pero no hemos entregado el agua y los alimentos prometidos a la ciudad cercana. ¿Qué pasaría si tuviera que agregar el término "transición continua", tendría su propio mérito? Después de todo, tal vez sea más adecuado describir el movimiento del código a través de los entornos, ya que tiene la connotación de "de / a" más que el despliegue o la entrega, lo que podría implicar una sola ubicación, ¡a perpetuidad! Esto es lo que obtenemos si no aplicamos el sentido común. ¿Tendría su propio mérito? Después de todo, tal vez sea más adecuado describir el movimiento del código a través de los entornos, ya que tiene la connotación de "de / a" más que el despliegue o la entrega, lo que podría implicar una sola ubicación, ¡a perpetuidad! Esto es lo que obtenemos si no aplicamos el sentido común. ¿Tendría su propio mérito? Después de todo, tal vez sea más adecuado describir el movimiento del código a través de los entornos, ya que tiene la connotación de "de / a" más que el despliegue o la entrega, lo que podría implicar una sola ubicación, ¡a perpetuidad! Esto es lo que obtenemos si no aplicamos el sentido común.
En conclusión, esto es algo simple de describir (¡hacerlo es un poco más ... complicado!), Solo use el sentido común, el idioma inglés y estará bien.
fuente
Integración continua: La práctica de fusionar el trabajo de desarrollo con la rama principal constantemente para que el código se haya probado con la mayor frecuencia posible para detectar problemas lo antes posible.
Entrega continua: entrega continua de código a un entorno una vez que el código está listo para enviarse. Esto podría ser puesta en escena o producción. La idea es que el producto se entregue a una base de usuarios, que pueden ser QA o clientes para su revisión e inspección.
La prueba unitaria durante la fase de Integración continua no puede detectar todos los errores y la lógica empresarial, en particular los problemas de diseño, por eso necesitamos QA o entorno de ensayo para las pruebas.
Implementación continua: la implementación o liberación de código tan pronto como esté listo. La implementación continua requiere la integración continua y la entrega continua; de lo contrario, la calidad del código no se garantizará en una versión.
Implementación continua ~~ Integración continua + Entrega continua
fuente
Integración continua
Entrega continua
Despliegue continuo
CI / CD es un viaje. No es un destino
Nota al pie:
Practicando la integración continua y la entrega continua en AWS
fuente
Fuente: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/
Qué es la integración continua La integración continua es un proceso o una práctica de desarrollo de compilación automatizada y prueba automatizada, es decir, se requiere que un desarrollador confirme su código varias veces en un repositorio compartido donde cada integración se verifica mediante compilación y prueba automatizadas.
Si la compilación falla / es exitosa, se le notifica a un desarrollador y luego puede tomar las medidas pertinentes.
¿Qué es la entrega continua? La entrega continua es la práctica en la que mantenemos nuestro código desplegable en cualquier punto que haya pasado toda la prueba y tenga toda la configuración requerida para llevar el código a producción pero aún no se ha implementado.
¿Qué es la implementación continua? Con la ayuda de CI, hemos creado una compilación para nuestra aplicación y estamos listos para impulsar la producción. En este paso, nuestra compilación está lista y con CD podemos implementar nuestra aplicación directamente en el entorno de control de calidad y, si todo va bien, podemos implementar la misma compilación en producción.
Básicamente, la implementación continua está un paso más allá de la entrega continua. Con esta práctica, cada cambio que pasa todas las etapas de su proceso de producción se libera a sus clientes.
La implementación continua es una combinación de gestión de configuración y contenedorización.
Gestión de la configuración: CM se trata de mantener la configuración del servidor que será compatible con los requisitos de la aplicación.
Containerization : Containerization es un conjunto de peajes que mantendrán la consistencia en todo el entorno.
Fuente Img: https://www.atlassian.com/
fuente
DevOps es una combinación de 3C: continua , comunicación , colaboración y esto conduce a un enfoque principal en varias industrias.
En un mundo de dispositivos conectados a IoT, múltiples funciones de scrum como propietario del producto, web, móvil y control de calidad funcionan de manera ágil en un ciclo de scrum de scrum para entregar un producto al cliente final.
Mire esto para saber cómo DevOps habilita el mundo conectado de IoT: https://youtu.be/nAfZt2t4HqA
fuente
Por lo que aprendí con Alex Cowan en el curso Entrega continua y DevOps , CI y CD son parte de una cartera de productos que consiste en el tiempo que pasa de las observaciones a un producto lanzado.
Desde las observaciones hasta los diseños, el objetivo es obtener ideas comprobables de alta calidad. Esta parte del proceso se considera diseño continuo .
Lo que sucede después, cuando pasamos del Código en adelante, se considera una capacidad de Entrega continua cuyo objetivo es ejecutar las ideas y lanzarlas al cliente muy rápido (puede leer el libro de Jez Humble Entrega continua: lanzamientos de software confiables a través de Build, Test, y Automatización de implementación para más detalles). La siguiente tubería explica en qué pasos consiste la integración continua (CI) y la entrega continua (CD).
Integración continua , como explica Mattias Petter Johansson ,
(puede ver los dos videos siguientes para obtener una descripción más práctica usando CircleCI - Comenzando con CircleCI - Integración continua P2 y Ejecutando CircleCI en la solicitud de extracción ).
Se puede especificar la canalización de CI / CD de la siguiente manera, que va de Nuevo Código a un Producto lanzado.
Los primeros tres pasos tienen que ver con las Pruebas, extendiendo el límite de lo que se está probando.
El despliegue continuo , por otro lado, es manejar el despliegue automáticamente. Por lo tanto, cualquier confirmación de código que pase la fase de prueba automatizada se lanza automáticamente a la producción.
Nota : Esto no es necesariamente el aspecto que deberían tener las tuberías, pero pueden servir como referencia.
fuente
vamos a mantenerlo corto:
CI: Una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo al menos diariamente. Cada integración se verifica mediante una compilación automatizada (incluye pruebas) para detectar el error lo más rápido posible. CD: CD Builds on CI, donde construye software de tal manera que el software puede lanzarse a producción en cualquier momento.
fuente