Integración continua

Este artículo está traducido y adaptado del siguiente artículo de Martin Fowler en el que expone su idea de lo que es la integración continua:

http://martinfowler.com/articles/continuousIntegration.html

Según Martin Fowler: “La integración continua es una práctica de desarrollo de software en la cuál los miembros de un equipo integran su trabajo frecuentemente, como mínimo de forma diaria. Cada integración se verifica mediante una herramienta de construcción automática para detectar los errores de integración tan pronto como sea posible. Muchos equipos creen que este enfoque lleva a una reducción significativa de los problemas de integración y permite a un equipo desarrollar software cohesivo de forma más rápida.”

Desarrollo mediante integración continua

A continuación se muestra un ejemplo de como incorporar un nuevo desarrollo en un proyecto siguiendo las indicaciones de la integración continua.

1. Debemos comenzar obteniendo una copia local del código fuente del repositorio de control de versiones, donde se guarda de forma integrada.


2. Tras obtener la copia local se procede a hacer los cambios necesarios en el código y en los tests de verificación, que se ejecutarán de forma automatizada. Para los tests se suelen usar herramientas de la familia de XUnit.


3. Una vez finalizados los cambios se llevará a cabo una construcción automatizada en la máquina de desarrollo. Esta fase se encargará de compilar el código, empaquetarlo y realizar las pruebas automátizadas. Sólo si todas estas tareas se realizan sin error se considerará que la construcción ha sido correcta. Si hay errores, habrá que solucionarlos.


4. Tras una construcción correcta ya se puede pensar en entregar los cambios al repositorio. Puesto que puede haber habido otros cambios por parte de otros desarrolladores mientras se trabaja en local, lo primero será actualizar la copia local y reconstruir el proyecto. En caso de conflicto con nuestros cambios aparecerán errores de compilación o en las pruebas que tendremos que solucionar antes de poder actualizar el repositorio con nuestros cambios.


5. Una vez entregados los se volverá a construir la línea principal de desarrollo del proyecto en la máquina de integración. Si no hay errores se ya podrá decir que los cambios se han llevado a cabo. En caso de que apareciesen errores, habría que solucionarlos. Esta construcción automática en la máquina de integración puede ser realizada por nosotros de forma manual o de forma automática mediante alguna herramienta.

En caso de que aparezcan conflictos entre desarrolladores, estos serán detectados rápidamente. En este momento lo más importante será solucionar estos errores tan pronto como sea posible.

El resultado de todo esto es un proyecto que funciona correctamente y tiene pocos errores. Todo el mundo desarrolla a partir de un código estable y trata de mantenerse lo más cerca de él como para que las integraciones con él no lleven demasiado tiempo. Se tarda menos tiempo en arreglar errores porque estos aparecen más rápidamente.

Prácticas de integración continua

A continuación se describen las principales prácticas de integración continua:

• Mantener un único repositorio de código fuente
• Automatizar la construcción del proyecto
• Hacer que la construcción del proyecto ejecute sus propios tests
• Entregar los cambios a la línea principal todos los días
• Construir la línea principal en la máquina de integración
• Mantener una ejecución rápida de la construcción del proyecto
• Probar en una réplica del entorno de producción
• Hacer que todo el mundo pueda obtener el último ejecutable de forma fácil
• Publicar qué está pasando
• Automatizar el despliegue

Mantener un único repositorio de código fuente

Los proyectos de software implican a un montón de ficheros que necesitan ser organizados para construir un producto. Hacer el seguimiento de todos estos ficheros es costoso, sobre todo cuando hay varias personas involucradas. Para facilitar esta tareas han surgido las herramientas de gestión del código fuente o control de versiones, como Subversion o CVS.

Todo se debe incluir en el repositorio. Se debe ser capaz de de construir un proyecto a partir del código descargado del repositorio. También es útil incluir otros recursos como la configuración compartida del IDE. Se recomienda no subir todo aquello que se pueda construir.

Estos sistemas de control de versiones permiten la creación de ramas para el desarrollo. El uso de ramas es problemático y se debe usar lo mínimo posible, como para la corrección de bugs de versiones anteriores o experimentos temporales.

Automatizar la construcción del proyecto

La construcción de un proyecto implica la compilación del código fuente, mover ficheros de un sitio a otro, cargar esquemas en base de datos, etc. Todas estas tareas deberían automatizarse para evitar errores y ganar tiempo.

Existen herramientas como Maven o Ant que permiten esta automatización.

Hacer que la construcción del proyecto ejecute sus propios tests

Dentro del proceso de construcción de un proceso se deberían realizar los tests del código, que pueden implementarse mediante herramientas de la familia XUnit. Estos tests, si están bien hechos, pueden detectar muchos errores.

Entregar los cambios a la línea principal todos los días

La integración permite que los desarrolladores informen unos a otros de los cambios que han hecho. Si esto se hace de forma frecuente, todo el mundo sabrá rápidamente los cambios que se han producido.

El único prerrequisito para que un desarrollador entregue sus cambios a la línea principal es que se pueda construir el código de forma correcta. El desarrollador debe actualizar primero su copia local, resuelve cualquier conflicto y construye su copia local. Si se hace de forma correcta, se subirá a la línea principal.

Haciendo esto de forma frecuente, lo desarrolladores encuentran rápidamente si hay un conflicto y lo arreglan tan pronto lo detectan, cuando todavía es fácil de arreglar. Como mínimo, los desarrolladores deberían entregar sus cambios una vez al día.

Construir la línea principal en la máquina de integración

A pesar de las entregas diarias de los desarrolladores, todavía se pueden producir errores de integración debido a falta de disciplina del equipo o diferencias ambientales entre las máquinas de los desarrolladores.

Para evitar estos errores hay que asegurarse de que se construye el proyecto en la máquina de integración. Es el desarrollador que está haciendo la entrega el responsable de que esta construcción se realice de forma correcta.

La construcción en la máquina de integración se puede hacer de forma manual o mediante un servidor de integración continua como Hudson, CruiseControl, Continuum, etc.

En la forma manual el propio desarrollador lleva a cabo la construcción en la máquina de integración, vigilando su progreso.

Un servidor de integración continua vigila el repositorio y, cada vez que se hace una entrega, para el servidor, recoge el código fuente del repositorio, lo construye y notifica al responsable de la entrega del resultado.

Mantener una ejecución rápida de la construcción del proyecto

Puesto que en un proceso de integración continua lo que cuenta es obtener resultados del proceso tan pronto como sea posible, es preciso que el proceso de construcción no se demore excesivamente.

Normalmente se considera que 10 minutos es un tiempo razonable para la construcción de un proyecto. Si la construcción de un proyecto sobrepasa este tiempo se puede optar por crear varios scripts de construcción, dejando el más sencillo para cuando se quiera hacer una entrega y los más complicados para cuando se deseen hacer pruebas más exhaustivas del proyecto.

Probar en una réplica del entorno de producción

Si estamos probando en un entorno distinto del de producción, cada diferencia es un riesgo de que los que ocurre en desarrollo no ocurra en producción. Para minimizar estos riesgos, se debería usar en ambos entornos el mismo gestor de base de datos, la misma versión del sistema operativo, librerías, etc.

Hacer que todo el mundo pueda obtener el último ejecutable de forma fácil

Todo el mundo que esté involucrado en el desarrollo de un determinado software debería ser capaz de obtener fácilmente el último ejecutable y de ejecutarlo, facilitando las demostraciones, la prueba y la revisión de los últimos cambios.

Publicar qué está pasando

La integración continua considera que la comunicación es muy importante, así que hay que asegurarse que todo el mundo puede ver fácilmente el estado del sistema y los cambios que se han realizado.

Uno de las cosas más importantes que hay que comunicar es el estado de la línea principal de desarrollo. Si se está usando un servidor de integración continua, probablemente se dispondrá de una herramienta web donde se puedan ver los trabajos en progreso en cada momento.

Si se quiere hacer esta información más aparente, se pueden usar los llamados “radiadores de información”, que no son más que elemento visuales como luces o muñecos que informan de un determinado estado. Por ejemplo, se puede usar una luz roja para indicar que se ha producido un error en el servidor de integración continua y una luz verde para cuando no haya errores.

Automatizar el despliegue

Para llevar a cabo la integración continua se necesitan varios entornos como desarrollo, prueba y producción. Ya que se deben mover ejecutables entre múltiples entornos varias veces al día, será mejor hacerlo de forma automática, así que es necesario tener scripts que permitan el despliegue de aplicaciones entre entornos de forma sencilla.

Beneficios de la integración continua

El principal beneficio de la integración continua es la reducción del riesgo. Se puede predecir el tiempo de integración, puesto que es algo que se realiza de forma continua.

También permite reducir la aparición de bugs, puesto que la realización constante de pruebas permite su pronta detección y corrección antes de que entren en producción.

Ya que se dispone en todo momento de ejecutables del proyecto, esto permite la rápida adopción por parte de los usuarios de las nuevas características añadidas al proyecto. Esto también permite que los usuarios valoren estos cambios y sugieran cambios nuevos de forma rápida.

Referencias:
Artículo sobre integración continua de Martin Fowler