Ni la pregunta ni las respuestas encajan realmente en mi manera simple de pensar sobre ello. Soy consultor y he sincronizado estas definiciones con un número de equipos de Desarrollo y personas de DevOps, pero tengo curiosidad sobre 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 continuidad entrega:

Cero. Nada se automatiza cuando los desarrolladores comprueban el código... Tienes suerte si han compilado, ejecutado o realizado alguna prueba antes del check-in.

1. Compilación continua: compilación automatizada en cada check-in, que es el primer paso, pero no hace nada para probar la integración funcional del nuevo código.

2. Integración continua (CI): compilación y ejecución automatizadas de al menos pruebas unitarias para probar la integración de nuevo código con código existente, pero preferiblemente pruebas de integración (end-to-end).

3. Implementación continua (CD): implementación automatizada cuando el código pasa CI al menos a un entorno de prueba, preferiblemente a entornos más altos 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.

4. Entrega continua: automatizado publicación y puesta en producción del sistema. Esto es CD en producción más cualquier otro cambio de configuración como configuración para pruebas A / B, notificación a los usuarios de nuevas características, 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 hace referencia en el primer principio del Manifiesto Ágil ( http://agilemanifesto.org/principles.html ) y práctica de Entrega Continua, como parece ser referenciada 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 los 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 se confunde fácilmente.

Creo que la definición de amazon es directa y sencilla de entender.

"Entrega continua es una metodología de desarrollo de software donde el proceso de liberación está automatizado. Cada cambio de software se crea, prueba e implementa automáticamente en producción. Antes del empuje final a la producción, una persona, una prueba automatizada o una regla de negocio decide cuándo debe ocurrir el empuje final. Aunque cada cambio exitoso de software se puede lanzar inmediatamente a la producción con entrega continua, no todos los cambios necesitan ser liberados de inmediato.

La integración continua es una práctica de desarrollo de software donde los miembros de un equipo utilizan un sistema de control de versiones e integran su trabajo con frecuencia en la misma ubicación, como una rama maestra. Cada cambio se construye 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 construir y probar automáticamente código, en comparación con la entrega continua, que automatiza todo el proceso de liberación de software hasta la producción."

Por Favor, echa un vistazo http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

La integración continua básicamente solo significa que las copias de trabajo del desarrollador se sincronizan con una línea principal compartida varias veces al día.

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 ocurrir lo siguiente:

• Uno o dos desarrolladores mantienen los cambios locales durante unos días porque " no es listo todavía".
• Uno o dos desarrolladores crean ramas en el control de código fuente para que puedan trabajar en sus características "sin ser molestados por los cambios de otras personas".

Esto puede llevar a problemas. La mala organización de 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 completado en un corto período de tiempo (horas como máximo).

Básicamente la idea general es que la integración de un pequeño cambio en una pequeña cantidad de trabajo. Integrar un gran cambio es una cantidad de trabajo desproporcionadamente grande. El conjunto del trabajo de integración es menor si se realiza en pequeños pasos constantes. Esto permite a los desarrolladores pasar más tiempo trabajando en funciones visibles para el negocio en lugar de la sobrecarga del proceso de desarrollo.

La entrega continua se describe como la lógica evolución de la integración continua: ¡Siempre ser capaz de poner un producto en producción!

Esto sigue la misma idea de elementos de trabajo discretos y bien definidos. Si hay una base de código maestra única que solo se ajusta en pequeños incrementos por 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 pulsar un botón.

El menor trabajo de estabilización que se necesita hacer (que, una vez más, es la sobrecarga del proceso de desarrollo y debe ser eliminado), más a menudo que la base de código puede ser empujado a cualquier entorno dado. En muchas empresas, una implementación puede ser un proceso bastante agotador. Incluso una operación de una semana. Esto es caro y no produce valor comercial. Mediante el empleo de buenas definiciones de elementos de trabajo, pruebas automatizadas eficaces e integración continua, un equipo puede estar en condiciones de automatizar la entrega de la base de código a cualquier ambiente.

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.

Rara vez verás 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 automáticamente y desplegar automáticamente en cualquier entorno, entonces, bueno, la producción es un entorno como cualquier otro. Así que si el equipo ha construido hasta en este punto, hay un potencial de valor significativo para el negocio al ser siempre capaz de implementar actualizaciones en producción.

Las correcciones de defectos se envían a los clientes más rápido, las nuevas características llegan al mercado más rápido, las nuevas ideas se prueban contra el mercado en incrementos más pequeños para permitir la redirección de prioridades, etc.

Por ejemplo, digamos que una empresa tiene una gran idea para una nueva característica en su producto o servicio basado en software. Han hecho algunas investigaciones, conocen el mercado, y creen que esta idea resultará en una nueva línea de ingresos sólida. Ahora considere dos opciones para entregar esa característica:

1. Pasar meses desarrollando todo en una rama de una sola vez. Pasa semanas integrándolo de nuevo en la base de código principal. Pasa días probándolo. Pasa un día desplegándolo. Y solo luego comience a rastrear los ingresos reales en el sistema de producción.
2. Implementa pequeñas partes de la característica, una a la vez. Cada semana lanzar una nueva pieza de la misma. Cada semana obtenga más datos sobre los ingresos reales.

En el primer escenario, si la característica no tiene el efecto de mercado deseado, entonces se desperdicia mucho de dinero en algo que los clientes realmente no quieren. En el segundo escenario, el hecho de que los clientes no lo quieran se determina mucho, mucho antes y el resto del trabajo se des-prioriza.

En última instancia, estas "cosas continuas" se tratan de eliminar la sobrecarga del proceso de desarrollo. Si la línea de una empresa los ingresos son una oferta de servicios en particular, entonces idealmente todos sus costos deben ir a esa oferta. Sobrecarga del proceso de desarrollo (fusionar código, 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.

Atlassian publicó una buena explicación sobre La integración continua frente a la entrega continua frente a la implementación continua .

En pocas palabras:

Integración continua - is una automatización para compilar y probar la aplicación cada vez que se introducen nuevas confirmaciones en la rama.

Entrega Continua - es Integración continua + Implementar la aplicación en producción "haciendo clic en un botón" (Lanzamiento a los clientes es a menudo, pero bajo demanda).

Despliegue continuo - is Entrega continua pero sin intervención humana (La entrega a los clientes está en curso).

Un gráfico puede reemplazar muchas palabras:

Disfruta... :-)

# he actualizado la imagen correcta...

Diferencia entre Integración Continua, Entrega continua e implementación continua

Creo que estamos analizando y tal vez complicando un poco el conjunto "continuo" de palabras. En este contexto, continuo significa automatización. Para las otras palabras adjuntas a "continuo" utilice el idioma inglés como su guía de traducción y por favor no trate de complicar las cosas! En "continuous build" construimos automáticamente (write/compile/link/etc) nuestra aplicación en algo que es ejecutable para una plataforma específica/contenedor/tiempo de ejecución/etc. "Integración continua" significa que su nuevo la funcionalidad prueba y se realiza según lo previsto cuando interactúa con otra entidad. Obviamente, antes de que se lleve a cabo la integración, la compilación debe realizarse y las pruebas exhaustivas también se usarían para validar la integración. Por lo tanto, en la "integración continua" uno usa la automatización para agregar valor a un cubo existente de funcionalidad de una manera que no interrumpa negativamente la funcionalidad existente, sino que se integre bien con ella, agregando un valor percibido al conjunto. La integración implica, por su mera definición en inglés, que las cosas jive armoniosamente por lo que en code-talk mi add compila, enlaces, pruebas y se ejecuta perfectamente dentro del todo. No llamarías a algo integrado si fallara en el producto final, ¿verdad?! En nuestro contexto "Continuous deployment "es sinónimo de" continuous delivery " ya que al final del día hemos proporcionado 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 la implementación de algo no necesariamente significa que hemos entregado. Implementamos el código, pero debido a que no nos hemos comunicado de manera efectiva a nuestros grupos de interés, ¡no logramos cumplir desde una perspectiva empresarial! Desplegamos las tropas pero no hemos entregado el agua y la comida prometidos a la ciudad cercana. ¿Y si añadiera el término "transición continua", tendría su propio mérito? Después de todo, tal vez sea más adecuado para describir el movimiento de código a través de entornos, ya que tiene la connotación de" de/a " más aún que el despliegue o la entrega que podría implicar un solo lugar, 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 usa el sentido común, el idioma inglés y estarás bien.

DevOps es una combinación de 3C - continuo, 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 de producto, web, móvil y control de calidad trabajan de manera ágil en un ciclo de scrum de scrum para entregar un producto al cliente final.

Integración continua: Función scrum múltiple que funciona simultáneamente en múltiples puntos finales

Entrega continua: Con integración e implementación, entrega de productos a múltiples clientes para ser manejados al mismo tiempo.

Implementación continua: múltiples productos implementados a múltiples clientes en múltiples plataformas.

Vea esto para saber cómo DevOps habilita el mundo conectado de IoT: https://youtu.be/nAfZt2t4HqA

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 tan a menudo como sea posible para detectar problemas tempranamente.

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 puede ser QA o clientes para su revisión e inspección.

Prueba unitaria durante el La fase de integración continua no puede atrapar todos los errores y la lógica empresarial, particularmente los problemas de diseño, por lo que necesitamos QA, o entorno de prueba para las pruebas.

Despliegue continuo: El despliegue o lanzamiento de código tan pronto como esté listo. La implementación Continua requiere Integración Continua y Entrega Continua, de lo contrario, la calidad del código no estará garantizada en una versión.

Implementación continua ~~ Integración continua + Continua Deplivery