JAVAUY 07 – Integración continua

Ya se está subiendo el material del Javauy al sitio del JUGUY, así que voy a ir repasando las conferencias a las que asistimos y tratar de publicar algo de material por acá.

Estuve leyendo sobre “Integración continua“, la primer conferencia que asistimos. Lo bueno que tuvo esta charla al igual que muchas otras, es que el orador la presentó no solo basado en lo teórico, sino en experiencia propia. El orador fue Yonathan Lapchik, desarrollador de Tata Consultancy Services, que para mostrar ejemplos, se conectó por escritorio remoto a una computadora en Ciudad Vieja y otra en Zona América.

Me sirvió mucho haber aprendido a usar control de revisiones (Subversion en mi caso) en el trabajo para entender el concepto global. Pueden leer más sobre eso en Wikipedia.
No saqué muchos apuntes pensando en ver las diapositivas publicadas más adelante, así que voy a confiar en lo que me acuerde. De todas formas van a estar disponibles en el sitio del JUGUY más adelante, ya han subido unas cuantas, y siguen subiendo las que se van sumando.

La integración continua es una práctica de desarrollo de software, del lado de la programación extrema o programación ágil, introducida por Martin Fowler y Kent Beck. Fowler la define en su trabajo como:

“Una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo frecuentemente, usualmente cada persona integra al menos diariamente – llevando a varias integraciones por día. Cada integración es verificada por una generación automatizada (incluyendo testeo) para detectar errores de integración tan rápido como sea posible. Muchos equipos han encontrado que ésta técnica los lleva a problemas de integración significativamente reducidos y permite a un equipo desarrollar software cohesivo más rápidamente.”

Por medio de un sistema de control de revisiones, y un sistema de automatización del build, se mantiene un repositorio único con el código del software. Es bastante popular y bastante usada en el desarrollo de software.

Algunas de las prácticas incluyen:
-Automatizar el build: De ésta forma, a pesar de haber muchos programadores trabajando en distintos sectores y partes del código, todos van a compilar y generar el proyecto de la misma manera.
-Incluir test automáticos.
-Administrar cambios al menos una vez por día.
-Testear en un clon del ambiente de producción: las condiciones en que se testean deben ser iguales a las del ambiente de producción.
-Facilitar acceso a último ejecutable a todos.
-Todos ven lo que está pasando.

Algunas de sus ventajas son:
-Cuando fallan los tests unitarios, o se descubre un bug, los desarrrolladores pueden revertir el código a un estado libre de errores, sin perder tiempo debugueando.
-Avisos tempranos de código roto o incompatible.
-Avisos tempranos de cambios conflictivos.
-Tests unitarios inmediatos de todos los cambios.
-Disponibilidad constante de un build actual para testear, demostrar, o entregar.
-El impacto inmediato de chequear código roto o incompleto es un incentivo para que los desarrolladores aprendan a trabajar incrementalmente con ciclos de feedback más cortos.

En la charla mencionaba cómo un desarrollador detecta errores propios enseguida, en contraste con un código sin integración. Ésto haría que todos perdieran tiempo buscando un culpable de un código erróneo. Y una de las cosas que más enojan a un programador es el código erróneo de otro. Por eso, al detectar al que metió la pata, le están echando mucha responsabilidad y presión encima.
Sin embargo, con éste método, uno mismo se da cuenta de sus errores, pudiendo corregirlos antes de incluirlos en el repositorio. Ésto supone una moral más alta en los desarrolladores al no tener que pasar por esa situación incómoda.

Mencionaron más de un software que hace posible el trabajo de la integración continua, y demostró el que usa en la práctica en su trabajo. Muchos de ellos son Open Source, por lo que pueden obtenerse gratuitamente por internet. Tengo entendido que los hay no solo para Java y .NET sino también para Ruby, Python y otros lenguajes. Tienen una interfase muy amigable y fácil de usar, e incluso plugins para Firefox.

Lo que descubrí por casualidad es que el equipo de desarrollo de SharpDevelop, el IDE gratuito y libre para desarrollar en .NET, utiliza un software de integración continua, CruiseControl. Caí de casualidad en la interfaz de integración continua del proyecto, y lo reconocí instantáneamente después de haber asistido a ésta conferencia.

En conclusión puedo decir que la integración continua es una práctica bastante interesante para proyectos grandes y rápidos, aunque lleva una disciplina bastante exigente de desarrollo para el programador. Sin embargo, sería interesante trabajar bajo esta disciplina en algún momento para poder conocer la metodología a fondo y determinar las ventajas y desventajas basado en experiencia propia.

Si les interesa el tema, pueden leer más detalles sobre las prácticas y beneficios en el papel de Martin Fowler, o buscar al respecto en Google.