La idea

Se trata de automatizar las pruebas de integración. Esto se hará con CruiseControl en

colaboración con un repositorio en este caso SVN.

El CruiseControl durante ciclos de 60 segundos consulta al repositorio controlando las

modificaciones que ha habido dentro de el. En caso de que haya habido alguna
modificación, procederá a desplegarlo sobre un servidor de pruebas en caso de que se
trate de un proyecto web con esto se podrá observar si hay alguún error de despliegue en
cuyo caso aparecerá en ala consola del cruise. En caso de que sea un java Project no
realizara este último paso.
Cruise control esta basado en ant en caso configurando su script es posible que ejecute
todas las junit asociadas al proyecto que se esta integrando en el momento que una junit
de un resultado fallido lo mostrara por rss.

Pasos de instalación

Se descomprimen el .zip y se modifica el config.xml y por cada proyecto que queramos

integrar un fichero build.xml con el nombre del proyecto en este caso Kedrosutil.xml.
La configuración gira en torno a solamente 2 ficheros xml, primero el config.xml aquí
se configuran los proyectos por cada proyecto que queramos “integrar continuamente”
se deben configurar entre etiquetas <Project></Project>
<?xml version="1.0" encoding="UTF-8"?>
<cruisecontrol>
<project name="kedrosutil">
<!-- Establece el directorio de trabajo sobre el que esta el fuente dentro del equipo -->
<property name="src.java" value="C:\desarrollo\work_eclipse\Utils\src" />
<listeners>
<currentbuildstatuslistener file="logs/kedrosutil/status.txt"/>
</listeners>
<bootstrappers>
<currentbuildstatusbootstrapper file="logs/kedrosutil/status.txt"/>
</bootstrappers>

<modificationset quietperiod="10">
<svn localworkingcopy="${src.java}"/>
</modificationset>
<!-- Nos indica donde esta el directorio ant y el build.xml sobre el que se va a apoyar
la integracion ademas de poder configurar el numero de segundos por ciclo de integracion en
este caso 60 segundos -->
<schedule interval="60">
<ant antscript=".\apache-ant-1.6.5\bin\ant.bat"
buildfile="kedrosutil.xml" target="build"
uselogger="true" usedebug="false"/>
</schedule>
<!-- Muy importante es donde guarda los resultados de las pruebas en xml la consola
de CC posee unas vistas de xsl que nos resumen la informacion son muy utiles -->
<log>
<merge dir="C:\work\apps\cruisecontrol-bin-
2.4.1\projects\kedrosutil\target\testresults"/>
</log>
<!-- en este tag podemos indicarle la forma de publicar los resultados podemos incluso
configurarlo para que nos lo mande por correo no me parece muy practico -->
<publishers>
<onsuccess>
<artifactspublisher dest="artifacts/${project.name}"
file="projects/${project.name}/target/${project.name}.jar"/>
</onsuccess>
</publishers>
</project>
</cruisecontrol>
Después estaría el fichero de configuración de cada proyecto kedrosutils.xml. No he
podido incluir los comentarios xml por problemas con el juego de caracteres pese a
tener el doctype. Se deberán corregir sobre este fichero los path siempre que no sean los
de mi proyecto.
<?xml version="1.0" encoding="UTF-8"?>
<project name="kedrosutil" default="build" >
<!-- apunta al directorio que contiene los fuentes java -->
<property name="fuentejava" value="C:\desarrollo\work_eclipse\Utils\src" />
<property name="destino" value="C:\work\apps\cruisecontrol-bin-2.4.1\projects\" />
<property name="common" value="C:\work\server\jakarta-tomcat-5.0.28\common\lib\" />
<!-- Muy importante darle el mismo nombre que el fichero xml asi como el nombre de proyecto que
le pusimos en el config.xml -->
<property name="nombreProyecto" value="kedrosutil" />
<!-- Se debe apuntar al directorio de dentro de la carpeta de work donde tengo el CC que contiene
los test java -->
<property name="tests.dir" value="C:\work\apps\cruisecontrol-bin-
2.4.1\projects\${nombreProyecto}\target\classes\es\satec\kedros\junit\test" />
<!-- Se debe apuntar al directorio del workspace del eclipse que contiene los test java -->
<property name="test.src" value="C:\desarrollo\work_eclipse\Utils\src\es\satec\kedros\junit\test" />
<!-- Estos 3 son así siempre -->
<property name="classes" value="./projects/${nombreProyecto}/target/classes" />
<property name="testresults" value="./projects/${nombreProyecto}/target/testresults"/>
<property name="test-classes" value="./projects/${nombreProyecto}/target/test-classes"/>
<target name="build" >
<!— Es conveniente esta instrucción ya que de lo contrario puede bloquear el SVN

<exec executable="svn">
<arg line="cleanup" />
</exec>
<!—Esta instrucción updatea del repositorio SVN la ultima versión en mi caso he creado un
proyecto Kedros sobre el que tengo en el eclipse

<exec executable="svn">
<arg line="co http://127.0.0.1/kedros/ ." />
</exec>
<!—Estas clases configuran el classpath de lo que sería un deploy de un proyecto web además de
algunas api’s para pruebas es opcional en este caso. Ha no se que tengamos jar externos en nuestro
proyecto como p.e log4j.jar

<path id="compile.classpath">
<pathelement path ="C:\work\tester\jameleon-test-suite\lib\"/>
<pathelement path ="c:\j2sdk1.4.2_10\bin"/>
<pathelement path ="C:\work\server\jakarta-tomcat-
5.0.28\server\lib\catalina-ant.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/commons-beanutils.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/commons-digester.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/commons-validator.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/commons-collections.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/commons-logging.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/log4j-1.2.8.jar"/>
 <pathelement path ="${fuente}/WEB-INF/lib/struts.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/displaytag-1.1.jar"/>
<pathelement path ="${fuente}/WEB-INF/lib/htgui.jar"/>
<pathelement path ="${common}\javax.servlet.jar"/>
<pathelement path ="${common}\activation.jar"/>
<pathelement path ="${common}\mail.jar"/>
<pathelement path ="${common}\javax.servlet.jsp.jar"/>
<pathelement path ="${classpath.external}"/>
<pathelement path ="${classpath}"/>
<pathelement path ="${destino}${nombreProyecto}"/>
</path>
<!—classpath de la junit sería classpath de testeo en esta ocasión he utilizado la 3.7 ,
existe una nueva versión que aún no he probado y que cambia mucho solo funciona con este
jar

<path id="tests-classpath">
<pathelement path ="C:\work\apps\cruisecontrol-bin-2.4.1\lib\junit.jar"/>
</path>

<!—crea los directorias de compilación de clases separando las de testeo

<mkdir dir="${classes}"/>
<mkdir dir="${testresults}"/>
<mkdir dir="${test-classes}"/>
<!—compila el proyecto entero

<javac srcdir="${fuentejava}" destdir="${classes}">
<classpath refid="compile.classpath"/>
<classpath refid="tests-classpath"/>
</javac>
<!—compila los testcases dejandolos en su directorio

<javac srcdir="${test.src}" destdir="${test-classes}">
<classpath>
<pathelement location="${classes}"/>
<pathelement location="tests-classpath"/>
</classpath>
</javac>

<!—ejecuta solo los testcases que previamente hemos separado para que sea más rapido el
ciclo

<junit haltonfailure="no" printsummary="on">

<classpath >
<pathelement location="${classes}"/>
<pathelement location="${tests.dir}"/>
</classpath>
<classpath refid="tests-classpath"/>
<classpath refid="compile.classpath"/>
<formatter type="brief" usefile="false"/>
<formatter type="xml" />
<batchtest todir="${testresults}" >
<fileset dir="${test-classes}" includes="**/*Test.class"/>
</batchtest>
</junit>
<!—genera el fichero jar de todo el java project listo para utilizar en otro proyecto

<jar jarfile="./projects/${nombreProyecto}/target/${nombreProyecto}.jar"
basedir="${classes}"/>

</target>

</project>
Conclusiones

He incluido al final la tarea de comprimir en un jar todo el java Project tendriamos un

jar utiles fácil de reutilizar en cualquier proyecto. Otras tareas que se pueden
implementar generar en casi en tiempo real la ultima versión de javadoc del proyecto,
generar un war listo para deplorar sobre un servidor web de pruebas. Añadir al todo el
ciclo de integración librerías de pruebas funcionales un sistema que puede llegar a ser
muy practico en tareas de mantenimiento llevando a cabo las pruebas de regresión de la
aplicación.

La prueba final.

Primero arranco el cruise control ejecutando cruisecontrol.bat de la carpeta del

framework.

He incluido en el java Project con el que he hecho las clases de fechas una clase más de
pruebas para que se vea que el cruise control lanza todas las junit del proyecto.

Voy a probarlo en 2 pasos primero introduzco un error dentro de un método de la clase

DateUtil devuelve una cadena vacía donde antes devolvía un formato de fecha.
Hago commit sobre la clase Cruise control detecta el cambio y compila el proyecto
ejecutando las junit. Se arranca la consola de Cruise control en
http://127.0.0.1:8180/buildresults/kedrosutil. Y te informa de que se han producido 2
fallos en cada uno de los testcases el nombre de los métodos que ha fallado con las
modificaciones de los ficheros que han provocado los fallos. Además es posible ver
estos resultados por medio de rss. Facilita encontrar “daños colaterales”.

Añado 2 capturas de pantalla más subsanando el error. Para demostrar que funciona.
Nota.- Los logs de cruisecontrol estan en la carpeta /cruisecontrol../logs. Aquí podremos
ver secciones que no son lanzadas por consola.

Nota.- Como regla general, evita los directorios con espacios cuando uses versiones
Windows de herramientas Unix. Casi siempre deberían funcionar sin problemas, yo lo
he hecho por probar y funciona, pero no es recomendable.

Osea nada de instalar subversión en C:\Archivos de programa\Subversion\iconv por lo

de los espacios en Archivos de programa

Nota.-Puede pasar que el Server jetty donde se deploya la consola de administración

este ya ocupado por un tomcat de echo es lo más normal.
Cambia el puerto de el jetty para q no interfiera con el tomcat en caso de que este en el
mismo ordenador. Esta en le arrnaque en el cruisecontrol.bat

Añado una libreria al ant del cruisecontrol para poder arrancarlo y pararlo a mi
antojo.set CRUISE_PATH=%CRUISE_PATH%;%LIBDIR%\catalina-ant.jar

posibilita nuevas tareas ant como:

<start url="127.0.0.1:8082" username="tomcat" password="tomcat"
path="/${nombreProyecto}"/>
<stop url="127.0.0.1:8082" username="tomcat" password="tomcat"
path="/${nombreProyecto}"/>

A.M.F. 2007 (c)