Integración Continua

La integración continua es una práctica muy útil en el desarrollo de software (lastima que no la usamos, bueno no al 100%).
Recientemente escuche algo de un servidor de integración y me llamo la atención. Pense, en que podrá servirnos a nosotros, recuerdo haber visto algo de esto en internet, de pronto recorde que ya teníamos uno, que se empezo a utilizar en tres proyectos, uno de los cuales se cancelo y se quedo en un proof of concept, otro fue tan sencillo que nunca realmente se notaron los beneficios que CI (Continuous Integration) pudo haber brindado y en este último que nos hubiera servido muchísimo en algún momento se desconfiguro el Build Server y se dejo de utilizar.

Bueno en resumen, teníamos el servidor, pero no la práctica de integración continua. CI es de esas cosas como control de versión y administración de proyectos que por más que tengas CVS o MS Project (o algo mejor), si tu equipo no tiene buenas prácticas de Administración de la Configuración o Planeación de Proyecto de poco sirve. Lo mismo nos ocurre ahora...

Bueno volviendo al tema. Martin Fowler reescribió sobre CI, si quieren conocer un poco más de esto se los recomiendo.

Por último, aunque Team Foundation Server aún le falta madurar un poco en algunas de sus áreas (al igual que otras de VSTS), trae ya un servidor de Integración con el que Christian y yo estuvimos jugando.

Como funciona, simplemente creas un nuevo build, le dices que proyectos de Visual Studio o que soluciones quieres compilar, cuales dependen de cuales y que pruebas quieres correr sobre el build. Una vez que haces esto y programas la frecuencia (minímo diario), todo funciona en automático. El build server tomara del repositorio los archivos que necesita, compilara lo que le indicaste, correrá las pruebas y te deja todo el output (dlls, archivos de pruebas, exes, etc) en un dropbox (un folder compartido en red). La mejor parte es que todo esto se integra con los reportes de Sharepoint que tiene el Team Foundation, por lo que podemos ver estadísticas como las siguientes:
Pruebas fallando con bugs activos y con bugs activos,
Regresiones: pruebas que ya pasaban y ahora no.
Otros indicadores de calidad,
% de pruebas que pasan.
% de codigo cubierto por pruebas (Code Coverage).

También se pueden hacer otro tipo de revisiones aparte de las pruebas automatizadas, como para poder hacer el deployment o release de un build en partícular.

La verdad es que nosotros estamos medio güeyes, la regamos, pensamos que los builds eran para tenerlos. Como? Si pensabamos que para tenerlos y poder obtener de una fecha en partícular los ejecutables y librerías necesarias para de ahí poder hacer un release. La verdad es que esto de los builds tiene mucho mayor sentido que eso: Continuous Integration. Esto nos va a permitir saber como vamos, que tal trabajamos juntos, si vamos mejorando o empeorando, detectar rápidamente como nos pegan los cambios de otros y arreglarlos rápidamente y más que nada, tal como dice martin fowler "treat integration as a non-event", "trata la integración como si no fuera un evento", es decir, no vamos a estar al final del proyecto integrando todos los modulos.