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:
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 "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:
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 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.