Quienes me conozcan sabrán que, al principio, yo también fui un programador. Eran tiempos diferentes y la programación orientada a objetos era la punta de lanza de las nuevas metodologías.
Hablo de 20 años atrás, era una época más oscura que la actual, hoy nuestro contexto tecnológico está iluminado por 1000 proyectos, 200 meeutps y grupos de desarrolladores que podemos encontrar en nuestra ciudad.
En aquellos tiempos pasar a producción mi aplicación era una tarea ardua que conllevaba desde minutos hasta horas de caídas y varios reinicios de programas y del servidor.

En los últimos años ha sido grande el impacto de las nuevas técnicas provenientes del mundo DEVOPS , es un mundo de sistemas. No voy a hablar en este artículo ni de contenedores ni de Docker, sé bien que más de uno lo está pensando ahora mismo. En más de una ocasión me han hecho notar que utilizo indistintamente los conceptos de integración continua y de puesta en producción continua. Y es una crítica acertada, bien por simplificar y por hacer las charlas más amenas peco de ambiguo y poco preciso. Espero rápidamente explicar en qué son diferentes y cómo utilizarlos de manera adecuada.

La integración continua es un proceso que ocurre, o si bien más debería ocurrir tantas veces como sea posible, en el ciclo normal de desarrollo de una aplicación. Como todos sabemos tan pronto como nuestro código es aplicado a nuestro repositorio sabemos si se ha roto algún tipo de compilación y si el código es consistente con el resto de programadores. El juego es fácil de entender, codificar, pushear y reparar los posibles issues que podamos tener. Cuando tenemos un grupo de desarrolladores trabajando en el mismo código de manera coordinada esta recurrencia, tantas veces como se pueda, es vital en el éxito o el fracaso de mi proyecto. Muchos commits, frecuentes y consistentes.

El llamado en inglés Continuous Delivery, entrega continua o puesta en producción continua es un proceso que tiene que ocurrir tantas veces como sea relevante y no tiene relación aparente con el número de actualizaciones de mi código. No tiene mucho sentido actualizar aplicaciones en producción con código que no afecta a funcionalidad o seguridad.

La diferencia es sutil, si bien los dos conceptos tratan de ciclos recurrentes de actualización de código, la primera obedece a la máxima de poder cotejar nuestro trabajo con el del resto del equipo y la segunda obedece a ciclos de actualizaciones relevantes en producción funcionalidades, librerías, parches de seguridad…)

Como podéis imaginar la cantidad de ciclos iterativos de la integración continua suele ser 1 orden factorial superior al segundo porque sus objetivos son diferentes.
Por último señalar que es altamente conveniente el uso de diferentes ramas nos puede dar una manera de fácil de diferenciar cuál de estos conceptos es aplicable en una iteración en el repositorio de código, en este caso la integración continúa comitearía a Dev o Master (según la filosofía de montaje del repositorio) y el continuous delivery a un rama de producción.

Basado en la idea arrojada por rigor.com sobre “differences-continuous-integration-continuous-deployment-continuous-delivery