Aprende a implantar integración continua desde cero (II): Un esquema simple de integración continua

Seguimos con la segunda parte de esta serie de post sobre cómo implantar integración continua desde cero en una empresa.
—-
Recordando un poco el post anterior (Aprende a implantar integración continua desde cero (I): ¿Por qué integración continua? ), vimos los beneficios de la integración continua, y echamos un primer vistazo a qué es integración continua.
Para ello, partimos de la definición de integración continua de Martin Fowler.
Vimos que integración continua es una práctica que afecta al desarrollo del software y donde se integra el código frecuentemente.
Pero es mucho más, así que sigamos donde nos quedamos:
Práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente, al menos una vez al día. Cada integración se verifica con un build automático (que incluye la ejecución de pruebas) para detectar errores de integración tan pronto como sea posible.”
3. “cada integración se verifica con un build automático”
La integración continua, va un pelín más allá de solo integrar frecuentemente el código.
Además de integrar frecuentemente, con cada integración realizamos varias comprobaciones.
Y te preguntarás, ¿por qué no nos quedamos solo en integrar el código frecuentemente?
Lo cierto es que pasar de integrar todo el código al final a hacerlo frecuentemente de poco en poco ya es un avance grande.
Pero, normalmente, aunque el código que programamos cada uno en nuestra máquina funcione, al integrarlo, solucionar conflictos y demás, no tiene por qué funcionar.
Suelen surgir errores, asumimos cosas que no eran ciertas, y que hay que detectar lo más pronto posible.
Por ello, una primera comprobación es que el código que se ha integrado tiene que compilar correctamente.
Puede parecer algo muy simple, muy trivial, pero no debemos asumir nada.
Haz esta primera comprobación. Parece mentira, pero no es raro encontrarse código en el control de versiones que no compila.
4. “que incluye la ejecución de pruebas”
Desde mi percepción, hay gente que piensa que con integrar el código frecuentemente y que éste se pueda compilar correctamente ya implica integración continua.
Con integración continua queremos detectar los fallos lo más rápidamente posible, de poco en poco, en cada pequeña integración.
Te planteo la siguiente reflexión. ¿Qué el código compile te garantiza que funciona todo bien? ¿Te garantiza algo tan básico como que puedas desplegar ese software en una máquina y que vaya a funcionar?
Yo creo que no. Por eso, para mí integración continua también 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 mínima garantía de que la integración es correcta y probar a fondo el código.
La ejecución de las pruebas conlleva tiempo, y tenemos que tener un feedback relativamente rápido para saber si la integración 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 práctica que suele estar asociada a la integración continua es el smoke test, pruebas simples, básicas para comprobar que la integración es correcta y tener un feedback rápido.
Luego ya pasaríamos a otras etapas dentro del pipeline (de los pasos que establezcamos en nuestra estrategia de integración continua) donde haríamos pruebas más profundas sobre el código.
5.  “para detectar errores de integración tan pronto como sea posible”
Bueno, y durante estos 2 posts he estado insistiendo mucho en detectar los errores lo más pronto posible. ¿Por qué es eso necesario?
Cuanto más tiempo pasa desde que se introduce un error hasta que se detecta y se resuelve, más nos cuesta solucionar ese error.
Si a un desarrollador que acaba de terminar el código 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 días después, ya que el trabajo que ha hecho está más fresco en su cabeza, más reciente hoy que dentro de 3 días.
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 básicas han funcionado, pero en el commit 13 hay un error, resolver el fallo es más sencillo, porque sabemos que el fallo pudo introducirse en el commit 13, o algo del 13 ha hecho fallar lo demás.
Si esperamos hasta por ejemplo el commit 25 para hacer comprobaciones y encontramos un fallo…¿De dónde viene el fallo? ¿Del código del commit 25? ¿Del 24? Es más complicado saberlo, solucionarlo, está menos acotado.
Obviamente, la integración continua no es la bala de plata, no vamos a detectar todos los fallos del software.
Nuestro objetivo es automatizar las cosas más simples, para detectar los fallos más básicos lo antes posible y luego tener tiempo para otras comprobaciones.

Componentes de la integración continua

Una vez visto lo que es integración continua, puede que intuyas qué elementos o qué componentes intervienen en ella: el equipo de desarrollo, el control de versiones…etc.
El siguiente dibujo es un esquema muy simple sobre lo que podría ser integración continua.
esquema-integracion-continua
En este esquema, los desarrolladores subirían el código 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 integración que vigilará el servidor de integración 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?.
Después, el servidor de integración continua se encargará de vigilar el repositorio del control de versiones (la forma en la que lo haga dependerá de cuál es nuestra estrategia de control de versiones). Un ejemplo de servidor de integración 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 código, lo compilará y realizará las comprobaciones pertinentes que hayamos establecido, o desplegará el código a distintos entornos para realizar distintas cosas.
Además dará un feedback a los desarrolladores, para saber si el código que acaban de subir está bien, o hay algún fallo que hay que solucionar.
—-
Todo esto es muy bonito, pero ¿cómo lo pongo en práctica? ¿Por dónde empiezo? En el siguiente post, veremos todo esto, cuál creo que es la mejor forma de ir empezando a implantar la integración continua y las cosas que debes tener en cuenta para ello.

Javier Garzás

0 comentarios en “Aprende a implantar integración continua desde cero (II): Un esquema simple de integración continua”

  1. Andrea Rodriguez

    Muy buenos post, me esta sirviendo de gran ayuda en la implementación de un proyecto.
    Pero tengo una consulta,si bien es cierto integración continua se usa en todo el ciclo de vida del software, una vez que desarrollo termina de codificar y pasa al area de calidad , como se implementaria el ambiente de calidad siguiendo la integracion continua, ya que el ambiente de calidad es el que tiene todos los cambios similares al de produccion…
    agradeceria responder mi duda, muchas gracias

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba