Integración continua

“La integración continua es una práctica de desarrollo de software donde los miembros de un equipo de trabajo integran su trabajo con frecuencia, por lo general cada miembro integra su trabajo por lo menos una vez al día. Cada integración es verificada por un sistema automatizado de construcción (incluyendo los tests) para detectar los errores de integración lo más rápidamente posible.” – Martin Fowler

Trabajando con IC

Pongámonos en situación en un ejemplo de proyecto real con integración continua:

  • El proyecto está bajo un control de versiones con SVN.
  • Tenemos instalada una herramienta de automatización de ejecución de tests y compilación.

En el momento en el que nos enfrentamos a una nueva tarea lo primero que hacemos es actualizar nuestra copia del proyecto local con lo existente en el repositorio del SVN.

Posteriormente realizamos la tarea que se nos ha asignado y creamos o modificamos los tests asignados a esta tarea.

Apoyándonos en nuestra herramienta de automatización (En mi caso, me gusta utilizar maven para los proyectos Java), lanzamos la ejecución de los test, compilamos y probamos el binario generado en un entorno idéntico al de producción.

Una vez verificamos que todo haya ido correcto, revisamos que el estado del repositorio sea el mismo que en el momento de actualizar nuestra copia local. En caso de no haber variado el repositorio, ya podemos subir los cambios a éste y en el supuesto de que ya se nos hayan adelantado subiendo una nueva versión de los fuentes, actualizamos nuestra copia local y volvemos a realizar la compilación y ejecución de los tests.

De este modo, tendremos como resultado en el repositorio una versión estable de nuestro proyecto en cualquier momento del ciclo de vida del mismo, ya que los errores son detectados rápidamente y solventados antes de actualizar los trabajos en la línea principal del repositorio.

Realización de una tarea con IC

Realización de una tarea con IC

Prácticas clave para trabajar con integración continua

Mantener un repositorio de código fuente único.

El uso de un repositorio de código fuente nos permite garantizar que todo el mundo tendrá acceso a los mismos recursos. Hay una gran variedad de repositorios pero cada vez se está empleando mas como estándar el SVN o Subversion.

Automatizar la construcción

A medida que los proyectos van creciendo, la construcción de los mismos puede llegar a ser muy complicada (compilar en un orden determinado, mover los archivos de aquí a allá, cargar los esquemas en BBDD, etc). Esto acarrea dos problemas fundamentales:

  • Si pretendemos construir nuestro proyecto una o varias veces al día para testear el trabajo realizado nos quitará mucho tiempo y se convierte en una tarea pesada.
  • La construcción manual de un proyecto complejo termina significando errores ya que puede que se nos quede atrás algún paso en el proceso de construcción.

Para evitar estos problemas, podemos automatizar estas tareas, de modo que se puedan ejecutar con un solo comando.

Para mi la herramienta por excelencia para los desarrollos en Java es maven, que además de construir nuestro proyecto es capaz de ejecutar los test definidos.

Incluir tests automatizados

Cada vez se generaliza más el empleo de técnicas como TDD (Test Driven Developer), lo que ha fomentado que muchas personas se den cuenta del valor de programar unos buenos tests.

Para el caso de los proyectos Java yo suelo utilizar la librería jUnit, con la que es muy sencillo preparar las pruebas unitarias y específicamente para los proyectos Web Selenium, que permite preparar pruebas funcionales de las aplicaciones.

Por supuesto, los test no garantizan que todo funcione correctamente, pero nos asegura un mínimo de funcionalidades que están correctas, reduciendo el número de Bugs de las mismas.

Todo el mundo debe subir los cambios a diario

Este punto quizás es uno de los mas importantes. Cuando se pasan muchos días si subir los cambios se puede convertir en un infierno integrar los cambios realizados con la línea principal del proyecto.

Probar el resultado en un clon del entorno de producción

Hemos visto hasta ahora todo el proceso desde el punto de vista del programador, pero la IC no acaba ahí. Una vez se suben los cambios al repositorio es importante probar el proyecto completo en una copia exacta del entorno de producción, teniendo de esta forma la certeza de que la última versión es estable.

En resumen

Con el uso de la IC tendremos las siguientes ventajas:

  • Posibilita la detección temprana de errores, minimizando los costes de resolución.
  • Se minimizan los costes de integración entre las funcionalidades que se van añadiendo al producto.
  • Se anima a los desarrolladores a integrar su código lo antes posible.
  • Permite controlar la estabilidad del producto.

 

Enlaces de interés: artículo de Martin Fowler sobre integración continua.