continuous integration - integracion - Integración continua vs. Entrega continua vs. Implementación continua
integracion continua y entrega continua (11)
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.
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:
- Uno o dos desarrolladores mantienen los cambios locales durante unos días porque "aún no está listo".
- Uno o dos desarrolladores crean ramas en el control de origen para que puedan trabajar en sus características "sin ser molestados por los cambios de otras personas".
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.
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!
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.
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á 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, la producción es un entorno como cualquier otro. Entonces, si el equipo se ha desarrollado hasta este punto, 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 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, 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 generará una nueva línea de ingresos sólida. Ahora considere dos opciones para entregar esa característica:
- Pase meses desarrollando todo en una rama única. Pase semanas integrándolo nuevamente en la base de código principal. Pasa días probándolo. Pase un día desplegándolo. Y solo entonces comience a rastrear los ingresos reales en el sistema de producción.
- Implemente pequeñas partes de la función, una a la vez. Cada semana lanza una nueva pieza. Cada semana obtenga más datos sobre los ingresos reales.
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 quieren se determina mucho, mucho antes y el resto del trabajo se da prioridad.
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.
¿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 usa 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!
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 todavía no ha terminado nada.
Entonces el tamaño importa:
small task = continuous integration
big task = frequent integration
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 Addison-Wesley "Martin Fowler" 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:
Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso.
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 empresas que no publican todo a ciegas todo el tiempo pueden tener una serie de razones por las que de todas formas desearían ser maestros en la implementación, 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.
Atlassian publicó una buena explicación sobre la atlassian.com/continuous-delivery/ci-vs-ci-vs-cd .
En una palabra:
Integración continua : es una automatización para compilar y probar aplicaciones cada vez que se introducen nuevos compromisos en la rama.
Entrega continua : es la integración continua + Implemente 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).
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 su 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 compilación debe realizarse y también se utilizarían pruebas exhaustivas para validar la integración. Por lo tanto, en la "integración continua" uno usa la automatización para agregar valor a un grupo de funcionalidades existente de una manera que no interrumpa negativamente la funcionalidad existente, sino que se integre 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 significa necesariamente que lo hicimos. Implementamos el código, pero debido a que no nos hemos comunicado efectivamente con nuestros grupos de interés, ¡no logramos entregarlo 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.
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.
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 crea, 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 ocurrir un empujón final. Aunque cada cambio exitoso de software puede ser lanzado inmediatamente a producción con entrega continua, no todos los cambios necesitan ser lanzados de inmediato.
La integración continua es una práctica de desarrollo de software donde 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
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 que funcionan de manera ágil en un ciclo de scrum de scrum para entregar un producto al cliente final.
Integración continua: función de scrum múltiple que funciona simultáneamente en múltiples puntos finales
Entrega continua: con integración e implementación, entrega de producto a múltiples clientes para ser manejada al mismo tiempo.
Implementación continua: múltiples productos implementados para múltiples clientes en múltiples plataformas.
Mire esto para saber cómo DevOps habilita el mundo conectado de IoT: https://youtu.be/nAfZt2t4HqA
Ni la pregunta ni las respuestas realmente se ajustan a mi forma simple de pensar al respecto. 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 la 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 las pruebas A / B, la notificación a los usuarios de las nuevas funciones, la notificación del soporte de la nueva versión y las 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.
Integración continua
- Automatizado (construcción de check ins + prueba unitaria)
Entrega continua
- Integración continua
- Automatizado (implementación para probar el entorno + prueba de carga + prueba de integración)
- Manual (despliegue a producción)
Despliegue continuo
- Entrega continua pero automatizada (implementación a producción)
CI / CD es un viaje. No es un destino
Estas etapas son sugerencias. Puede adaptar las etapas según las necesidades de su negocio. Algunas etapas se pueden repetir para múltiples tipos de pruebas, seguridad y rendimiento. Dependiendo de la complejidad de su proyecto y la estructura de sus equipos, algunas etapas pueden repetirse varias veces en diferentes niveles. Por ejemplo, el producto final de un equipo puede convertirse en una dependencia en el proyecto del siguiente equipo. Esto significa que el producto final del primer equipo se presenta posteriormente como un artefacto en el proyecto del siguiente equipo.
Nota al pie:
Practicando la integración continua y la entrega continua en AWS
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 un control de calidad o un 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
