Maven i cicle de desenvolupament continu

Tots els mòduls MADS són projectes Maven i hereten dels POM pare de la plataforma. Per això es construeixen igual a qualsevol màquina, i les ordres que fas servir en local són les mateixes que en un servidor d'integració contínua.

Estructura d'un mòdul

Un mòdul nou creat amb mads create module té un POM com aquest:

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

<groupId>madsv5.module</groupId>
<artifactId>facturacio</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 per a serveis web) aporta la configuració de compilació comuna.
platform, el pare de tots dos, fixa les versions de les dependències, de manera que tots els mòduls fan servir les mateixes.
Les dependències entre mòduls són dependències Maven normals: Maven les resol i avisa si en falta alguna.

El cicle d'un canvi

Pas	Ordre	Què fa
Generar	`mads generate module`	Regenera el model Java, els textos i els paràmetres a partir de les metadades
Provar	`mads module test`	Executa els tests del mòdul
Construir	`mads module build`	Compila, empaqueta i instal·la al repositori Maven local
Versionar	`mads module version`	Actualitza la versió del mòdul
Desplegar	`mads module deploy`	Publica l'artefacte al repositori Maven
Publicar	`mads pub module` / `mads pub app`	Publica el mòdul o l'app al servei WAPP

Per a una app, mads app version i mads app update fan l'equivalent.

Totes les ordres de mòdul accepten --modulePath per treballar sobre un mòdul des de qualsevol carpeta, cosa que en facilita l'automatització.

Integració contínua

Un pipeline típic executa el mateix cicle a cada canvi que arriba al repositori. Per exemple, en un script de CI:

export MADS_NO_UPDATE_CHECK=1          # sense comprovació de versions al servidor
export M2_HOME=/opt/maven

# 1. (Opcional) El codi generat ha de coincidir amb les metadades
mads generate module --modulePath .
git diff --exit-code                   # falla si algú s'ha oblidat de regenerar

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

# 3. Només a la branca principal: desplegar
mads module deploy --modulePath .

El pas 1 és opcional i requereix que el codi generat sigui al repositori i que la generació sigui estable (sense dates ni canvis d'ordre entre execucions; comprova-ho executant-la dues vegades). Quan es compleix, garanteix que ningú puja metadades sense el codi regenerat, o a l'inrevés.

Bones pràctiques

Una versió per lliurament. Fes servir mads module version abans de desplegar i no despleguis mai dues vegades la mateixa versió.
Dependències entre mòduls per versió, no per còpia. Si un mòdul en necessita un altre, declara la dependència al POM; no en copiïs les classes.
Tests amb mads-jtest. Estén els seus casos base per provar contra una base de dades real de desenvolupament.
Revisa el codi generat. Forma part del repositori i de la revisió de cada canvi.

Consulta totes les opcions a la referència de mads.