Aprende a implantar integracin continua desde cero (I):

Por qu integracin continua?

La integracin continua es una prctica de desarrollo software que me encanta, porque tanto si te faltan elementos
para llevarla a cabo como si no, implantarla aportar muchsimos beneficios a tu organizacin.

Para mi, implantar integracin continua en una empresa lleva de la mano mejoras de la calidad del software en general,
en todos sus mbitos: proceso, producto y equipo.

La integracin continua conlleva una mejora de la calidad del

software
Calidad de proceso

En primer lugar, con la integracin continua se le da ms visibilidad al proceso de desarrollo en general, a todos los
pasos que se siguen desde que se empieza a programar un requisito del cliente hasta que est en produccin.

As, todo el mundo sabe las fases por las que va pasando el cdigo, y el estado del software en cada momento (si
compila, si pasa las pruebas, en qu entorno est cada versin, qu versin se est probando etc).

Tambin le damos visibilidad a la estrategia de gestin de configuracin, poltica de ramas del control de versiones y
tagueos, entre otras cosas.

Si todo el equipo no conoca esto bien, o las estrategias estaban poco definidas, con la integracin continua habr que
solucionarlo.

Y esto ya es un avance importante, porque en muchas empresas a las que vamos, todas estas cosas imprescindibles no
son conocidas por todo el equipo, ni estn claras ni bien definidas.

Calidad de producto

Por otro lado, tambin se mejora la calidad del producto software.

El principal objetivo de la integracin continua es detectar los errores lo ms pronto posible, en fases tempranas del
desarrollo, para poder solucionarlos rpidamente.

As se introducen varios tipos de pruebas y comprobaciones, minimizando los riesgos, y haciendo que el software tenga
menos bugs que si no realizramos integracin continua.

Por otra parte, en fases ya avanzadas de la integracin continua se suelen lanzar inspecciones continuas de cdigo,
anlisis peridicos para detectar problemas de calidad en l.

Los desarrolladores tendrn que mejorar esas deficiencias, e incluso en ciertas ocasiones, se puede impedir que los
desarrolladores suban el cdigo al control de versiones si no cumplen los estndares de calidad definidos por la
empresa.

Calidad de las personas

Por ltimo, tambin se mejora la calidad del equipo. Si no saba, el equipo acaba aprendiendo a hacer distintos tipos de
pruebas (unitarias, de integracin), mejores prcticas de programacin y en general a desarrollar cdigo de mayor
calidad.

Adems, tener todo este proceso de desarrollo claro y tener todas estas comprobaciones para minimizar los riesgos, le
da ms confianza al equipo.
As es capaz de afrontar nuevos retos, mejoras y cambios y est ms motivado. Adems de que le ahorra muchsimo
tiempo, porque automatizamos procesos repetitivos (por ejemplo ciertas pruebas de regresin), dejando ms tiempo
para hacer otras cosas.

Y todo esto, al final se acaba reflejando en una mejora de cara al cliente y por supuesto en trminos econmicos para la
empresa.

Bueno pero qu es integracin continua?

Una de las definiciones que ms me gustan de integracin continua es la de Martin Fowler, porque resume muy bien lo
que conlleva el concepto.

Fowler define la integracin continua como una:

Prctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente, al
menos una vez al da. Cada integracin se verifica con un build automtico (que incluye la ejecucin de pruebas)
para detectar errores de integracin tan pronto como sea posible.

Muchas veces, se tiende a pensar que la integracin continua es tener instalado el servidor de integracin continua (por
ejemplo Jenkins) y que este compile el cdigo peridicamente; o tener automatizados los despliegues dndole a un
botn desde dicho servidor.

Pero como ves, la integracin continua engloba mucho ms que esto. Es una serie de buenas prcticas, de
comprobaciones interconectadas entre s, para conseguir software de mejor calidad.

Y cules son esas buenas prcticas, esos componentes que

intervienen en la integracin continua?
Vamos a ir partiendo de la definicin de Fowler para ir identificando los componentes e ideas claves de la integracin
continua.

1. Prctica de desarrollo software

Como ya coment, la integracin continua afecta al proceso de desarrollo del software, incorporando nuevas prcticas o
interconectando las que ya haba.

Para implantar integracin continua solemos definir un pipeline, un conjunto de etapas, de fases por las que va
pasando el software y que se automatizan.

Un ejemplo de un pipeline podra ser que con cada subida de cdigo al repositorio de control de versiones este se
descargue y compile.

Si est todo correcto, que se ejecuten una serie de pruebas unitarias, o se despliegue el cdigo a otro entorno para
hacer pruebas de sistema.

Por ltimo, que se despliegue al entorno de QA, de pruebas, para realizar otro tipo de pruebas manuales.
(Recuerda Pruebas de integracin, funcionales, de carga? Qu jaleo! Qu diferencias hay?)

Esta es una de las primeras cosas que hay que definir, saber cmo es el desarrollo, cul es el criterio para que el cdigo
promocione de un entorno a otro, y qu se hace en cada entorno.

Y si el cdigo no pasa algn punto hay que establecer cul es la estrategia para resolver el error, quin se encarga de
ello, cmo se gestiona.

Este sera un ejemplo de cmo se vera un pipeline implementado en Jenkins.

Esto es a lo que me refera con visibilidad del proceso. Podremos saber qu revisin de cdigo compila, cul no y en qu
punto del pipeline se encuentra cada subida del cdigo.

2. los miembros del equipo integran su trabajo frecuentemente

Dnde se suele integrar, poner en comn el trabajo que hace cada desarrollador? En el control de versiones.

En un equipo, el cdigo que implementa cada desarrollador no suele actuar aislado.

Cuando se distribuye el trabajo entre los miembros del equipo, y cada uno comienza a trabajar, normalmente se asumen
cosas de otros componentes del software que todava no estn implementados o que est programando otra persona.

Y hasta que no juntamos todo ese cdigo, no nos damos cuenta de los errores de ese tipo que cometemos.

Antes, lo que se tenda a hacer es que cada desarrollador programara de forma independiente y luego al final se
realizaba la integracin de todo el cdigo.

Esto se traduce en integraciones difciles, que tardan mucho en completarse y mucho sufrimiento, ya que hay muchos
cambios, mucho cdigo que integrar.

Uno de los motivos por los que surge la integracin continua es para evitar esto. La idea es que en vez de dejar la
integracin para el final, se vayan haciendo pequeas integraciones de cdigo frecuentemente.

La frase que podramos aplicar aqu es que si algo te cuesta, debes hacerlo ms a menudo y poco a poco, para que con el
tiempo te vaya costando cada vez menos esfuerzo.

Aunque trato de ir a lo esencial, este tema da para varios posts. La semana que viene terminaremos de ver lo
que es integracin continua y nos meteremos en un esquema tpico de integracin continua en la vida real.

Aprende a implantar integracin

continua desde cero (II): Un
esquema simple de integracin
continua
Recordando un poco el post anterior (Aprende a implantar integracin continua desde cero (I): Por qu
integracin continua? ), vimos los beneficios de la integracin continua, y echamos un primer vistazo a qu es
integracin continua.

Para ello, partimos de la definicin de integracin continua de Martin Fowler.

Vimos que integracin continua es una prctica que afecta al desarrollo del software y donde se integra el cdigo
frecuentemente.

Pero es mucho ms, as que sigamos donde nos quedamos:

Prctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente, al menos una vez al
da. Cada integracin se verifica con un build automtico (que incluye la ejecucin de pruebas) para detectar errores de
integracin tan pronto como sea posible.

3. cada integracin se verifica con un build automtico

La integracin continua, va un peln ms all de solo integrar frecuentemente el cdigo.

Adems de integrar frecuentemente, con cada integracin realizamos varias comprobaciones.

Y te preguntars, por qu no nos quedamos solo en integrar el cdigo frecuentemente?

Lo cierto es que pasar de integrar todo el cdigo al final a hacerlo frecuentemente de poco en poco ya es un avance
grande.

Pero, normalmente, aunque el cdigo que programamos cada uno en nuestra mquina funcione, al integrarlo,
solucionar conflictos y dems, no tiene por qu funcionar.

Suelen surgir errores, asumimos cosas que no eran ciertas, y que hay que detectar lo ms pronto posible.

Por ello, una primera comprobacin es que el cdigo que se ha integrado tiene que compilar correctamente.

Puede parecer algo muy simple, muy trivial, pero no debemos asumir nada.

Haz esta primera comprobacin. Parece mentira, pero no es raro encontrarse cdigo en el control de versiones que no
compila.

4. que incluye la ejecucin de pruebas

Desde mi percepcin, hay gente que piensa que con integrar el cdigo frecuentemente y que ste se pueda compilar
correctamente ya implica integracin continua.

Con integracin continua queremos detectar los fallos lo ms rpidamente posible, de poco en poco, en cada pequea
integracin.

Te planteo la siguiente reflexin. Qu el cdigo compile te garantiza que funciona todo bien? Te garantiza algo tan
bsico como que puedas desplegar ese software en una mquina y que vaya a funcionar?

Yo creo que no. Por eso, para m integracin continua tambin implica definir una estrategia de pruebas, diferentes
tipos, en distinta profundidad, para comprobar que las integraciones sean correctas.

Ya lo comentar en alguno de los siguientes posts, pero algo muy importante aqu es mantener un equilibrio entre tener
una mnima garanta de que la integracin es correcta y probar a fondo el cdigo.

La ejecucin de las pruebas conlleva tiempo, y tenemos que tener un feedback relativamente rpido para saber si la
integracin es correcta o no y poder seguir desarrollando.

Por ello, no podemos tirarnos 2 horas esperando a que se pasen las pruebas, para ver si lo que se ha subido al control de
versiones est bien o no.
Lo que se suele hacer es definir distintas etapas, con distintos grados de pruebas. Una prctica que suele estar asociada
a la integracin continua es el smoke test, pruebas simples, bsicas para comprobar que la integracin es correcta y
tener un feedback rpido.

Luego ya pasaramos a otras etapas dentro del pipeline (de los pasos que establezcamos en nuestra estrategia de
integracin continua) donde haramos pruebas ms profundas sobre el cdigo.

5. para detectar errores de integracin tan pronto como sea posible

Bueno, y durante estos 2 posts he estado insistiendo mucho en detectar los errores lo ms pronto posible. Por qu es
eso necesario?

Cuanto ms tiempo pasa desde que se introduce un error hasta que se detecta y se resuelve, ms nos cuesta solucionar
ese error.

Si a un desarrollador que acaba de terminar el cdigo le dices que hay un fallo en esa parte que ha hecho, va a tardar
mucho menos en solucionar el error que si ese fallo se detecta 3 das despus, ya que el trabajo que ha hecho est ms
fresco en su cabeza, ms reciente hoy que dentro de 3 das.

Por otra parte, si vamos haciendo comprobaciones por integraciones en el control de versiones, si sabemos que hasta el
commit 12 (estoy poniendo id de commits que no corresponden con la realidad) las comprobaciones bsicas han
funcionado, pero en el commit 13 hay un error, resolver el fallo es ms sencillo, porque sabemos que el fallo pudo
introducirse en el commit 13, o algo del 13 ha hecho fallar lo dems.

Si esperamos hasta por ejemplo el commit 25 para hacer comprobaciones y encontramos un falloDe dnde viene el
fallo? Del cdigo del commit 25? Del 24? Es ms complicado saberlo, solucionarlo, est menos acotado.

Obviamente, la integracin continua no es la bala de plata, no vamos a detectar todos los fallos del software.

Nuestro objetivo es automatizar las cosas ms simples, para detectar los fallos ms bsicos lo antes posible y luego tener
tiempo para otras comprobaciones.

Componentes de la integracin continua

Una vez visto lo que es integracin continua, puede que intuyas qu elementos o qu componentes intervienen en ella:
el equipo de desarrollo, el control de versionesetc.

El siguiente dibujo es un esquema muy simple sobre lo que podra ser integracin continua.

En este esquema, los desarrolladores subiran el cdigo que han hecho al control de versiones frecuentemente.

Esta parte no es tan trivial como parece, ya que tendremos que definir qu estrategia de control de versiones vamos a
seguir: desarrollaremos en distintas ramas? tendremos una rama de integracin que vigilar el servidor de integracin
continua? mantendremos una nica rama?

Si quieres hacerte una idea sobre posibles estrategias a seguir, te dejo el siguiente post Qu estrategia de control
de versiones seguir en un equipo Scrum?.
Despus, el servidor de integracin continua se encargar de vigilar el repositorio del control de versiones (la forma en la
que lo haga depender de cul es nuestra estrategia de control de versiones). Un ejemplo de servidor de integracin
continua puede ser Jenkins (Qu es Jenkins? Explicado en menos de 10 min para quienes no lo conocen de
nada).

Ante un cambio descargar el cdigo, lo compilar y realizar las comprobaciones pertinentes que hayamos establecido,
o desplegar el cdigo a distintos entornos para realizar distintas cosas.

Adems dar un feedback a los desarrolladores, para saber si el cdigo que acaban de subir est bien, o hay algn fallo
que hay que solucionar.