Hudson es un sistema de integración continua del que ya he comentado algo otras veces, se utiliza para lanzar tareas periódicas de compilación, ejecución de pruebas y despliegues. El problema que tiene es que cada tarea realiza un volcado del repositorio de control de versiones para sí mismo, y suele requerir bastante espacio en disco a medida que van añadiéndose tareas (jobs).
Hay una solución parcial que evita ocupar tanto espacio en disco y es desmarcar la opción de “Usar SVN update” en lugar de un checkout, de esta manera se borrará todos los fuentes y temporales creados por las tareas. Por contra, el realizar un checkout cada vez, en proyectos de tamaño considerable, realiza una sobrecarga sobre el repositorio SVN que en tareas de compilación puede afectar al resto de usuarios y proyectos que se encuentren albergados.
Además, existe un problema añadido en el almacenamiento de SNAPSHOTS en el repositorio Maven2 local de la máquina donde se ejecuta Hudson, ya que se puede dar el caso, de hecho a nosotros nos ha pasado, de que acabe por llenar la partición donde se almacena. Así que nada mejor que hacer un shell-script que vaya eliminando los ficheros JAR creados temporalmente del repositorio Maven2 locale con una periodicidad diaria y cuya modificación sea mayor de, por ejemplo, diez días:
find /opt/tomcat/.m2/repository -type f -mtime +10 -exec rm {} \;
Bastaría con añadir este comando en un fichero ubicado en /etc/cron.daily y un problema menos.
Aplicando el Application Lifecycle Management a los proyectos Maven.
http://pillitu.wordpress.com/2009/06/26/maven-calm/
http://www.sonatype.com/people/2008/05/misused-maven-terms-defined/
Un par de presentaciones de introducción:
Archiva es el repositorio Maven de la ASF. Sobre la instalación y configuración ya hay bastante documentación, tanto oficial como en la wiki, lo que quiero dejar es un problema de configurar las últimas versiones de Archiva con MySQL 5.0 o superior, cuando la base de datos está creada en UTF-8, que durante el proceso de instalación escupe la siguiente excepción:
ERROR RDBMS
- Error thrown executing CREATE TABLE `OPERATIONS`
(
`NAME` VARCHAR(256) BINARY NOT NULL,
`DESCRIPTION` VARCHAR(256) BINARY NULL,
`PERMANENT` BIT NOT NULL,
`RESOURCE_REQUIRED` BIT NOT NULL,
PRIMARY KEY (`NAME`)
) ENGINE=INNODB : Specified key was too long; max key length is 765 bytes
java.sql.SQLException: Specified key was too long; max key length is 765 bytes
Esto es un error conocido que de momento sigue sin arreglarse:
http://jira.codehaus.org/browse/MRM-227
pero que se puede “salvar” mediante configuración, y es añadiendo el siguiente bloque:
<!-- this is required for some MySQL versions and configurations, see CONTINUUM-1113 -->
<property>
<name>org.jpox.rdbms.stringDefaultLength</name>
<value>255</value>
</property>
en el fichero: archiva/WEB-INF/classes/META-INF/plexus/application.xml
Una de mis últimas labores profesionales ha sido definir los entornos de desarrollo corporativos para JavaEE, de un departamento de Factoría de reciente creación, para ello se ha definido tanto los sistemas software a utilizar, para automatizar tareas comunes, y las metodologías a aplicar a todos los niveles, como siempre con el objetivo que tanto le gusta a “los corbatas”: mejorar la calidad y la productividad de los resultados.
En estos sistemas lo que se busca es tener herramientas que faciliten las tareas de gestión de proyectos, desarrollo y ejecución automática de pruebas o despliegues.
En artículos posteriores se comentarán cada uno de ellos, pero para que sirva a modo de presentación, los integrantes del ecosistema software son:
- Entorno de desarrollo integrado
- Forja de desarrollo
- Repositorio de fuentes y control de versiones
- Repositorio de artefactos
- Sistema de integración continua
- Cuadro de mando de métricas y calidad
- Sistema de gestión de incidencias
