Las mejoras de nuestro producto de software deben considerarse en cada una de las fases del “Software Development Life Cycle” (SDLC), desde la toma de requisitos hasta el “Deployment”. En esta ocasión me gustaría centrarme en como podemos mejorar la calidad de nuestros Builds considerando unas sencillas “Best Practices”:

• Mantén todo tu código en un repositorio común.  Existen muchas herramientas Open Source, como por ejemplo el Subversion.
• Realiza un Build completo todos los días. Muchas veces se realizan a lo largo del día una sería de Buids incrementales (ya que son más rápidos), pero esto puede ocasionar problemas.  Por eso es recomendable hacer un build completo todas las noches (Nightly Build).
• Automatiza tus Builds. Usa scripst para automatizar todo el proceso, conseguirás un proceso repetible y evitas fallos derivados de procesos manuales.
• Incluye tus test unitarios como parte del sistema de Builds. Una vez el build haya terminado, lanza tus pruebas unitarias. Si algo se ha roto lo podrás idetificar rápidamente. Puedes introducir también herramientas de chequeo de código como el PMD, find bugs or checkstyle.
• Haz análisis y medición de la covertura del código (code coverage). Te ayudará para saber que la cobertura de tus test unitarios, ayudándote a incrementar el número de test unitarios para mejorar la cobertura…mejorando así la calidad final de tu producto (evalúa la eficacia de tu código).
• Realiza pruebas funcionales una vez terminado todo el proceso de Build. Una vez el proceso ha terminado, puedes hacer un Sanity Test de la funcionalidad utilizando una de las muchas herramientas que hay en el mercado, como por ejemplo Selenium…o bien puedes utilizar QTPro o Silktest. De esta manera tendrás una mayor seguridad de que los cambios introducidos no hay roto ninguna de las funcionalidades más importantes para negocio.
• Y finalmente, podrías realizar auditorias periódicas de código. Introdúcelo dentro de tu proceso de build, te ayudará para saber si tu código cumple con los estándares de codificación establecidos por la empresa.

¿Te gustaría construir, testear y “deployar” tu software de forma estable y fiable? Tal vez la integración continua te pueda ayudar. La Integración continua (continuous integration en inglés) es un proceso automático que permite comprobar continuamente que todos los cambios realizados por cada uno de los desarrolladores, no producen problemas de integración con el código del resto del equipo. Se pierde mucho tiempo integrando todo nuestro código, y sobre todo, pasar del entorno de desarrollo al de producción. Esto nos permite construir nuestro código desde las fuentes, simular nuestro entorno de producción y realizar algunas pruebas que garanticen su estabilidad.

¿Que herramientas puedo usar?
Para realizar Integración continua podemos encontrar herramientas tanto comerciales como Open Source. Algunas de las más conocidas son el CruiseControl (Open Source), AntHill (Comercial/Open Source) y el DamageControl. Yo personalmente sólo he trabajado con el framework de CruiseControl, por lo cual será del que hable en las siguientes líneas…

El CruiseControl al fin y al cabo es un framework que nos ayudará a automatizar nuestros procesos Java. Para ello utilizaremos la herramienta Ant (ANT es un framework para realizar scripts), que nos permite llevar a cabo la mayoría de las tareas que realizamos de forma manual.

¿Que se necesito para instalar el CruiseControl?
Lo primero y más importante es tener una máquina dedica a la integración continua, a poder ser, que tenga las mismas características que la maquina que tendremos en producción. También es muy importante que tengamos un repositorio de control de versiones dedicado a nuestra integración.

¿Se verá afectado el equipo?
Como ya había comentado con anterioridad, la implantación de un sistema de integración continua con llevará un serie de cambios y mucha disciplina. En muchos proyectos no se es consciente de que se trabaja en equipo hasta que llega el momento de la integración final.

La integración continua hace que nuestro desarrollo sea incremental. Los nuevas funcionalidades se añadirán, evitando que las anteriores dejen de funcionar. Cuando el conjunto de funcionalidades de nuestro sistema ofrezca la posibilidad de tener un software coherente con nuevas posibilidades, entonces en ese caso deberemos crear una nueva versión.

Daily Build
Uno de los objetivos principales de la integración continua es realizar continuamente integraciones, proceso muy útil para los desarrolladores ya que cuanto más amenudo se realicen antes se identificarán posibles defectos.

Pero, además, podemos usar el CruiseControl para hacer Daily Builds. Para ello schedularemos una hora determinada del día (preferiblemente por la noche) para ejecutar la integración.

Como había comentado al principio, el objetivo de este tipo de herramientas es automatizar tareas que hacemos manualmente. Por eso, si realizamos frecuentemente pruebas funcionales automáticas, podríamos añadir estas pruebas como tarea a nuestro Daily build. De esta forma, no sólamente se integrará todo nuestro código, se ejecutarán las pruebas unitarias, inpección de código, etc…sino que además diariamente ejecutaremos también toda nuestra batería de pruebas automaticas.

En nuestro caso, hemos integrado nuestras pruebas funcionales automatizadas con SilkTest a nuestro Daily build. Pero bueno, otras herramientas como selenium se pueden añadir como tarea facilmente en nuestro CruiseControl:

<selenium
browserExe=”C:Program FilesInternet Exploreriexplore.exe”
testSuiteUrl=”http://localhost/Selenium/TestRunner.html?auto=true&resultsUrl=testsHandleResults.php”
maximumWaitTimeInSeconds=”100″
resultsFile=”Selenium estsTestSummary.xml”
failonerror=”false”
/>

Conclusión
La integración continua nos puede ayudar a mejor la calidad de nuestro proyecto, ayudándonos a identificar de manera temprana posibles problemas.

Referencias
- “Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps” by Mike Clark

- Martin Fowler – http://www.martinfowler.com