Bueno, lo primero es lo primero: este post no es la verdad absoluta, así que si vienes en busca de iluminación, espero que esta entrada sirva como punto de partida, pero te recomendaría leer todo lo posible sobre este tema, empezando por consultar los enlaces del final del post.
Por mi parte, con esta entrada he querido resumir los conceptos principales de cada una de estas prácticas, para intentar aclarar(me) con las diferencias entre ellas.
Integración Continua
Los equipos de desarrollo de software que trabajan en un mismo proyecto, suelen encontrarse a menudo con los siguientes problemas:
- Merge conflicts: dos programadores modifican el mismo fichero o incluso la misma línea, lo cual da lugar a conflictos que deben resolverse y que pueden llegar a ser un quebradero de cabeza.
- Compile conflicts: si por ejemplo un programador usa el método foo() y alguien elimina ese método, ésto no dará problemas al hacer el merge, pero a nivel de compilación dará error porqué no encontrará ese método.
- Test conflicts: un ejemplo de test conflict sería cuando tu código depende de otro que ha cambiado (y ahora funciona diferente), lo cual haría que tu código no esté funcionando como esperabas y por tanto tu código no pase los tests.
La integración continua es una práctica de desarrollo de software que pretende minimizar este tipo de conflictos, permitiendo a las desarrolladores desarrollar, en lugar de perder su tiempo solucionando conflictos. La idea básica es que los desarrolladores commiteen los cambios muy frecuentemente (al menos una vez al día) para que en caso de conflicto se puedan solucionar de forma más rápida y sencilla, pues el propio programador tendrá el código que acaba de commitear “fresco” en su cabeza, y además no tendrá que preocuparse de investigar grandes cantidades de código, pues al commitear muy frecuentemente sabe que ha cambiado poco código desde su anterior commit.
La integración contínua, pues, consiste en automatizar los tests y los builds de tu software muy frecuentemente. A no ser que seas el único desarrollador en un proyecto, no hay razón por la que no quieras usar integración continua.
Martin Fowler describe las siguientes prácticas (casi copiadas al dedillo a continuación) para que la integración continua resulte efectiva:
- Mantener un único repositorio de código, con un sistema de gestión de versiones decente (¿he oído Git?). De esta manera, todos sabrán dónde está el código.
- Automatizar los builds de código (compilación, carga de esquemas en base de datos, etc.). Para Java se suele usar Ant o Maven, así como MSBuild para .Net.
- Configurar tests automáticos durante el proceso de build. Seguramente TDD sea la forma más popular hoy en día para producir tests automáticos.
- Todos los desarrolladores han de commitear sus cambios a la branch master al menos una vez al día.
- El build de los commits se hará en un server de integración continua (¿he oído Jenkins aquí?), y sólo si el build tiene éxito se considerará
hacer elese commit. - Arreglar los builds que han fallado, inmediatamente.
- Conseguir que los builds sean suficientemente rápidos, y que no tarden por ejemplo una hora en ejecutarse. Queremos obtener feedback rápidamente.
- Testear en un entorno clónico al de producción.
- Facilitar que cualquiera que forme parte del proyecto, pueda coger el último ejecutable y sea capaz de usarlo.
- Todos deben poder ver qué está pasando en cada momento.
- Los deploys a los diferentes entornos deben poderse hacer de forma automatizada. Es importante contar con la posibilidad de hacer un rollback, sobre todo si se trata de deploys a producción.
Continuous Delivery
La verdad que soy el primero en reconocer lo confuso de estos términos. Sin embargo, en el blog de puppetlabs lo explican muy bien: Continuous Delivery son una serie de prácticas que permiten, de forma automática, testear y deployar el código a un entorno de pre producción, clónico al de producción, dejando a un sólo click manual, (cuando las necesidades del negocio lo consideren) el despliegue a producción.
Así pues, como ese código habrá pasado los tests y se habrá desplegado en este entorno clónico al de producción, podremos estar (muy) seguros de que ese código funcionará también en producción.
Continuous Delivery es la extensión natural de la Integración Continua [Fuente], pues cada cambio no sólo se testeará y se podrá llevar a cualquier entorno, si no que se hará de forma totalmente automática, dejándo su subida a producción a un sólo click. En función de tu empresa y necesidades del negocio, Continuous Delivery puede aportar mucha agilidad.
Continuous Deployment
Continuous deployment sigue la filosofía de Continuous Delivery, pero llevando a producción el deploy en un único proceso automático. A la práctica, Continuous Deployment significa llevar a producción cada funcionalidad en el momento en que esté lista.
En esta ocasión parece más evidente que no siempre querremos que todos los cambios se suban directamente a producción, así que de nuevo, será en función de las necesidades de tu negocio que podrás valorar el uso de Continuous Deployment.
Fuentes
Video: introducción a la integración continua
http://www.martinfowler.com/articles/continuousIntegration.html
http://blogs.atlassian.com/2014/04/practical-continuous-deployment/
http://www.ansible.com/continuous-delivery
https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff
http://www.thoughtworks.com/continuous-delivery
http://blog.koalite.com/2013/05/servidor-de-integracion-continua-una-buena-inversion/
Foto por SMU Central University Libraries
>>> El build de los commits se hará en un server de integración continua, y sólo si el build tiene éxito se considerará hacer el commit. <<<
Me lo explique?
Que es el huevo, o la gallina?
@Buitaker tienes razón al 100%. Si es que no se puede traducir literalmente sin pararse a pensar en lo que se acaba de escribir 🙂
Commit -> Detectado por el server de CI -> Build -> Se notifica el resultado del build al desarrollador que ha hecho el commit
Si hay éxito, el commit generará un artifact que es un release candidate para llegar a producción. Si no hay éxito, el commit habrá provocado un fallo en el build y por tanto, el desarrollador deberá solucionarlo (con lo que ese commit, en realidad, no generará un artifact a deployar).