Sacar Release de un proyecto con Maven

Sacar Release de un proyecto con Maven

Índice de contenidos.

• 1. Introducción
• 2. Entorno
• 3. Configuración del pom.xml
• 3.1. Configuración del subversion
• 3.2. Configuración del maven-release-plugin
• 3.3. Configuración del repositorio de Maven
• 3.4. Configuración del settings.xml
• 4. Sacar release del proyecto
• 4.1. mvn release:prepare
• 4.2. mvn release:perform
• 5. Conclusión

1. Introducción

Este tutorial muestra los pasos necesarios para sacar release de un proyecto con Maven. La release contempla 2 pasos: cuando sacamos versión del proyecto crearemos una etiqueta dentro del directorio /tags de nuestro repositorio subversion para tener perfectamente controladas las versiones que se van instalando en producción y por otro lado se instalará la versión del proyecto en el repositorio de Maven corporativo donde se guardan las versiones estables de nuestro proyecto. Para ello vamos a configurar los plugins necesarios en nuestro pom.xml.

El plugin de maven necesario para sacar release es el maven-release-plugin del cual ya escribió Alejandro un tutorial. En este tutorial vamos a configurar el pom.xml del proyecto para que pueda conectarse al repositorio subversion, configuración del maven-release-plugin y nuestro settings.xml para configurar un repositorio de Maven corporativo para lo cual seguiremos el tutorial de Raúl

Es necesario disponer de un repositorio Subversion accesible a través de HTTP. Podéis seguir los pasos para montarlo con este tutorial.

2. Entorno.

El tutorial está escrito usando el siguiente entorno:

• Hardware: Portátil Asus G50Vseries (Core Duo P8600 2.4GHz, 4GB RAM, 320 GB HD).
• Sistema operativo: Ubuntu Desktop 8.04 (Hardy), Kernel: 2.6.24

3. Configuración del pom.xml

A la hora de sacar versión, lo más complicado o bien lo que más quebraderos de cabeza nos puede dar es a la hora de configurar nuestro pom.xml. Una vez hecho esto ya no nos
tendremos que preocupar de nada cada vez que saquemos versión del proyecto, simplemente bastará con ejecutar un par de comandos.

3.1. Configuración del subversion

Es necesario indicarle a Maven el path del subversion para que pueda conectarse para subir la etiqueta de la versión bajo el directorio /tags

		
			scm:svn:http://localhost/repoJuan/trunk/pruebas-parent
		
		
			scm:svn:http://localhost/repoJuan/trunk/pruebas-parent
		
		
			http://localhost/repoJuan/trunk/pruebas-parent
		

3.2. Configuración del maven-release-plugin

Del maven-release-plugin vamos a configurar las tareas o goals que se encargará de lanzar maven cuando invoquemos a la tarea de release que
serían por un lado limpiar el directorio de compilación del proyecto (clean) y por otro hacer una instalación del proyecto en el repositorio local (install) para compilar de nuevo
todo el proyecto, pasar los test, etc. De esta manera nos aseguramos que todo está OK para instalar. Si por el contrario algo no compilara o no pasara algún test la release no se llegaría
a hacer asegurándonos por tanto que lo que se instalará funciona correctamente.

	maven-release-plugin
	
		
		clean install
		${svn.username}
		${svn.password}
		
			http://localhost/repoJuan/tags
		
	

Los valores indicados en username y password se sacarán del settings.xml como veremos más adelante.

En la etiqueta tagBase indicamos la ruta del Subversion donde dejar la etiqueta del proyecto.

3.3. Configuración del repositorio de Maven

La etiqueta distributionManagement indica el repositorio de Maven donde se alojará el proyecto cuando hagamos la release

	
		repoPruebas
		Repositorio de Maven de Pruebas
		scp://localhost/var/maven/repository
	

En mi caso crearé un repositorio de Maven en una máquina local por lo que el acceso se realizará por localhost. Cambiar el campo url indicando el nombre
del servidor donde se tiene el repositorio local o bien su dirección IP.

3.4. Configuración del settings.xml

En este fichero, situado en ~/.m2 se almacenan los repositorios y claves de acceso a los mismos que tengamos configurados. Es aquí donde
debemos crear nuestro repositorio corporativo de Maven, usuario y password de acceso para que Maven pueda subir o bajar los proyectos desplegados.

   
  	
  		 
  			juan 
  			mipassword 
  		
  	 
  
  
  
        
          repoPruebas
          Repositorio de maven de Pruebas  
          scp://localhost/var/maven/repository  
      
  
  
  
        
        repoPruebas  
        usuario   
        password  
       
  
  
  /home/juan/.m2/repository

Aquí debemos configurar un usuario y password de acceso al repositorio subversion para que Maven pueda crear la etiqueta cuando saquemos la versión. Por otro lado hay
que dar de alta el repositorio de Maven corporativo repoPruebas y la url mediante la cual Maven copiará el proyecto una vez versionado. También hay que indicar
dentro de la etiqueta server las credenciales de acceso a la máquina donde se encuentra el repositorio de Maven.

No olvidar crear el directorio de maven en la máquina en /var/maven/repository y asignar los permisos correctamente.

4. Sacar release del proyecto

La release se hará en dos partes, primero se etiquetará la versión en el subversion (release:prepare) y posteriormente se guardará en el repositorio de
Maven corporativo (release:perform).

4.1. mvn release:prepare

Como decíamos, la release se sacará en dos partes. La primera de ellas se realiza mediante el siguente comando:

mvn release:prepare

En este punto Maven nos realizará una serie de preguntas para configurar la versión a etiquetar del proyecto

Primera pregunta: La versión que queremos sacar.

Si estamos trabajando en desarrollo sobre la versión 1.0-SNAPSHOT, nos preguntará si queremos sacar la versión 1.0. El sufijo SNAPSHOT indica que la versión está en desarrollo.
Una vez que decidimos sacar versión, Maven automáticamente le quita este sufijo y propone el número de versión actual. Esto lo podemos cambiar aunque lo normal es mantener la misma versión.

What is the release version for «pruebas-parent»? (com.autentia.tutoriales:pruebas-parent) 1.0: Intro para aceptar

Esto nos lo pregunta para cada módulo en que está dividido el proyecto. Lo normal, y lo que hacemos en Autentia, es dividir el proyecto en módulos funcionales (core, web, test, …)
y todos ellos englobados por un parent. Cada módulo a su vez tiene su propio pom.xml con su número de versión. Por tanto en este caso nos preguntará por la versión de cada pom.xml. Damos intro para los demás:

Segunda pregunta: La versión que queremos etiquetar en el subversion bajo el directorio /tags.

Nos sugiere la versión que se etiquetó anteriormente y lo normal es conservar la misma. Por tanto Intro para aceptar.

En este punto se hace un clean y un install del proyecto como explicamos anteriormente. Si algo no fuera bien se puede ejecutar un
mvn release:rollback que devuelve los poms a su versión original.

Tercera pregunta: Siguiente versión del proyecto.

Si antes estábamos sacando la versión 1.0 ahora nos sugiere que la siguiente es la 1.1-SNAPSHOT. Si nos viene bien aceptamos y si no podemos elegir la que nosotros queramos.
Nos preguntará por cada proyecto y maven se encargará de modificarnos los pom.xml poniendo esta nueva versión.

Si todo va bien nos creará en el subversion, bajo el directorio /tags, la versión 1.0.

4.2. mvn release:perform

Llegados a este punto está todo listo para sacar una nueva versión del proyecto. Se ha etiquetado la versión en el svn bajo el directorio tags y se han
modificado nuestros poms con la siguiente versión en desarrollo. Para sacar versión a instalar en producción ejecutar lo siguiente:

mvn release:perform

Esta tarea coge la etiqueta creada en el paso anterior con los poms actualizados a la nueva versión y lo copia en el repositorio de Maven.
La versión ya está lista para instalar en producción.

Para aclarar conceptos sobre cómo se trabaja a la hora de sacar release se muestra la siguiente imagen:

5. Conclusión

Una vez más, Maven nos facilita la tarea a los desarrolladores. En este caso el trabajo a la hora de sacar release de nuestros proyectos para instalar en el correspondiente entorno.
Por otro lado conservamos un histórico de cambios realizados y correctamente etiquetados para llevar el control de lo que vamos haciendo en el proyecto.

Esta forma de trabajar en los proyectos, o alguna similar, sobre todo los que están en pleno desarrollo o mantenimiento, debería ser obligatorio en cualquier organización
para mantener los proyectos bajo control.