Automatización con Maven y ciclo de desarrollo continuo

Todos los módulos MADS son proyectos Maven y heredan de los POM padre de la plataforma. Por eso se construyen igual en cualquier máquina, y los comandos que usas en local son los mismos que en un servidor de integración continua.

Estructura de un módulo

Un módulo nuevo creado con mads create module tiene un POM como este:

<parent>
  <groupId>madsv5</groupId>
  <artifactId>mads-module</artifactId>
  <version>5.1.0</version>
</parent>

<groupId>madsv5.module</groupId>
<artifactId>facturacion</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

<dependencies>
  <dependency>
    <groupId>madsv5</groupId>
    <artifactId>mads-jpalib</artifactId>
    <version>5.1.0</version>
  </dependency>
  <dependency>
    <groupId>madsv5.module</groupId>
    <artifactId>security</artifactId>
    <version>5.1.0</version>
  </dependency>
  <dependency>
    <groupId>madsv5</groupId>
    <artifactId>mads-jtest</artifactId>
    <version>5.1.0</version>
    <scope>test</scope>
  </dependency>
</dependencies>

mads-module (o mads-service para servicios web) aporta la configuración de compilación común.
platform, el padre de ambos, fija las versiones de las dependencias, así que todos los módulos usan las mismas.
Las dependencias entre módulos son dependencias Maven normales: Maven las resuelve y avisa si falta alguna.

El ciclo de un cambio

Paso	Comando	Qué hace
Generar	`mads generate module`	Regenera el modelo Java, los textos y los parámetros a partir de los metadatos
Probar	`mads module test`	Ejecuta los tests del módulo
Construir	`mads module build`	Compila, empaqueta e instala en el repositorio Maven local
Versionar	`mads module version`	Actualiza la versión del módulo
Desplegar	`mads module deploy`	Publica el artefacto en el repositorio Maven
Publicar	`mads pub module` / `mads pub app`	Publica el módulo o la app en el servicio WAPP

Para una app, mads app version y mads app update hacen lo equivalente.

Todos los comandos de módulo aceptan --modulePath para trabajar sobre un módulo desde cualquier carpeta, lo que facilita automatizarlos.

Integración continua

Un pipeline típico ejecuta el mismo ciclo en cada cambio que llega al repositorio. Por ejemplo, en un script de CI:

export MADS_NO_UPDATE_CHECK=1          # sin comprobación de versiones en el servidor
export M2_HOME=/opt/maven

# 1. (Opcional) El código generado debe coincidir con los metadatos
mads generate module --modulePath .
git diff --exit-code                   # falla si alguien olvidó regenerar

# 2. Tests y construcción
mads module test --modulePath .
mads module build --modulePath .

# 3. Solo en la rama principal: desplegar
mads module deploy --modulePath .

El paso 1 es opcional y requiere que el código generado esté en el repositorio y que la generación sea estable (sin fechas ni cambios de orden entre ejecuciones; compruébalo ejecutándola dos veces). Cuando se cumple, garantiza que nadie sube metadatos sin el código regenerado, o al revés.

Buenas prácticas

Una versión por entrega. Usa mads module version antes de desplegar y nunca despliegues dos veces la misma versión.
Dependencias entre módulos por versión, no por copia. Si un módulo necesita a otro, declara la dependencia en el POM; no copies sus clases.
Tests con mads-jtest. Extiende sus casos base para probar contra una base de datos real de desarrollo.
Revisa el código generado. Forma parte del repositorio y de la revisión de cada cambio.

Consulta todas las opciones en la referencia de mads.