¡Muy Feliz 2009!

Les deseamos puedan tener la osadía de llevar adelante todos sus sueños durante el 2009. ¡Muchas Felicidades!

"La integración continua es una práctica de desarrollo de software donde los miembros de un equipo de integrar su trabajo con frecuencia, generalmente cada persona integra al menos una vez al día - pudiendo haber múltiples integraciones por día. Cada integración es verificada por un build automatizado (incluyendo los test) para detectar errores de integración tan pronto como sea posible. Muchos equipos piensan que este enfoque conduce a una reducción significativa en los problemas de integración y permite a un equipo desarrollar software cohesivo más rápidamente. " Martin Fowler

Integración continua se ha convertido en algo muy importante en la comunidad de desarrollo de software y esto probablemente se debe a los efectos causados por las metodologías ágiles. En los equipos que han adoptado tales metodologías (Programación extrema, Scrum, etc), la integración continua es uno de los pilares de la agilidad, asegurando que todo el sistema funciona en cada build de manera coherente, incluso si su equipo es grande y diversas partes del código están siendo cambiadas al mismo tiempo.Pero, ¿por qué hacer integración continua? ¿Cuáles son los beneficios que puede aportar?

Básicamente, la gran ventaja de la integración continuidad es la retroalimentación instantánea. Esto funciona de la siguiente manera: con cada commit en el repositorio, el build se realiza automáticamente, con todos los test siendo ejecutados automáticamente y las fallas se detectan en ese momento. Si algun commit no compila o rompe alguno de los test, el equipo toma conocimiento de inmediato (a través de e-mail, por ejemplo, indicando la causa de las fallas y el commit que las causó). El equipo puede entonces corregir el problema tan pronto como sea posible, lo que es fundamental paa no introducir errores al crear nuevas funcionalidades, refactorizar, etc. La integración continua es más una forma de lograr seguridad en relación a los cambios: se pueden hacer cambios sin temor, porque se le notificará si algo se sale de lo esperado.

Pero porque yo no ejecuto personalmente los test en mi máquina y sólo entonces hago el commit?

Simple: su proyecto puede ser tan grande que los test (especialmente los de integración y aceptación) tardan un tiempo considerable para ser ejecutados y no desea esperar todo este tiempo en cada commit para poder seguir trabajando. En este caso, se recomienda ejecutar los test que envuelven las partes que se han modificado y sólo entonces hacer el commit, dejando para el servidor de integración contínua la labor de completar todas las pruebas del sistema y asegurarse de que todo está funcionando. Además, no se trata sólo de pruebas, estamos hablando de builds completos: con cada commmit tenemos una versión que teóricamente está lista para entrar en producción, y esto puede implicar la ejecución de las tareas que no haríamos si sólo estuviesemos probando, tales como por ejemplo generar un archivo .war. El proyecto también pueden ser desplegado automáticamente en un servidor de desarrollo/homologación y, entonces con cada commit tenemos el proyecto en ejecución en la Web instantaneamente reflejando nuestros cambios!

Otro ejemplo interesante es el proceso de generación de los documentos de nuestro proyecto: en cada commit hecho en el repositorio, el
servidor hace el check-out, ejecute la tarea ant correspondiente, y genera el javadoc de nuestro proyecto automáticamente, y podría publicarlo en donde nosotros querramos, Por lo tanto, garantía que ofrecemos es que la documentación se encuentra disponible siempre y en su última versión.

Para que todo esto funcione, sin embargo, debemos entender la idea de commits pequeños. Es más fácil saber dónde un error fue cometido cuando el build se rompe si hay pequeños cambios, en lugar de tener que comprobar las últimas 50 clases cambiadas en el último commit.

Otra cuestión importante es garantizar, al menos, construir un entorno limpio, con todas las pruebas pasando, al final de cada día. Por lo tanto, tenemos el software listo para entrar en producción tan pronto como sea necesario.

En otras palabras, podemos describir a la Integración Continua como un control e integración automática, con proceso de construcción automático y que ejecuta las pruebas en forma automatica y que detecta automáticamente defectos en cada pieza.

A continuación las herramientas que usamos:

Hudson - Integración Contínua
Ant - Ejecución de tareas
JUnit - Para generar los test unitarios, de componentes y de integración.
CheckStyle - Chequeo de sintaxis.
PMD - Chequeo de semántica.
Cobertura - Para generar los informes de cobertura de código de los diferentes tipos de test que hacemos.
JavaDoc - Documentación del código fuente.

Cabe aclarar que trabajamos con TDD como práctica principal, adoptamos algunas prácticas de XP y los proyectos se realizan bajo Scrum.

El Plugin de CheckStyle y PMD para poder visualizar de forma gráfica como se encuentra el proyecto. También usamos el plugin de Cobertura para ver de forma gráfica el nivel de la misma en los proyectos.

Por último, tenemos experiencia en la utilización de estas herramientas en el desarrollo de aplicaciones internas y para nuestros clientes, podemos afirmar que ellas en realidad nos traen una productividad antes inalcanzable. Si usted piensa en empezar a utilizar algunas herramientas de integración continua, vale la pena echar un vistazo en estas que indicamos. Sin embargo, hay varias otras disponibles, y se trata de una cuestión de elegir la que mejor se adapte a sus necesidades. No deje de compartir sus experiencias ...

Puede ser de utilidad, revisar la Automatización de Métricas de Producto y las herramientas para tal fin.

Test