Release Bugzilla Maven Plugin

0
12048

Automatizar acciones en el Bugzilla al generar versiones con Maven

Índice de contenido

Introducción.

Cómo ya hemos visto varías veces, la creación de plugins de maven es bastante sencilla. Como recordatorio os remito a este tutorial «Desarrollo de Plugins para Maven»
como referencia a la creación de plugins de Maven

Aprovechando la facilidad de crear nuestros propios plugins, en este tutorial
vamos a mostrar como automatizar un conjunto de acciones que hay que hacer siempre
en los sistemas de gestión de incidencias, tales como dar de alta una nueva versión
del producto, cerrar las incidencias que soluciona la nueva versión, etc.

En este caso vamos a ver automatizar estas acciones en Bugzilla.

Entorno

El tutorial está escrito usando el siguiente entorno:

Creación del plugin complementario.

Como hemos explicado en la introducción, la solución que hemos adoptado
es crear un plugin de Maven para que se conecte a nuestro Bugzilla y realice
todas las acciones de forma automática.

En primer lugar identificamos los parámeteros que necesita nuestro plugin
para conectarse al Bugzilla y generar el fichero changes.xml:

  • productName: Nombre del producto en el Bugzilla del que obtenemos la
    lista de bugs.
  • bugzillaUser: Usuario para el login en el Bugzilla.
  • bugzillaPassword: Contraseña del usuario para el login en el Bugzilla.
  • loginPage: Página de login en el Bugzilla.
  • loginRequired: Parámetro para indicar si es necesario hacer login en
    el Bugzilla para recuperar la lista de bugs. (por defecto true)
  • parentOnly: Al tener los proyectos de Maven herencia, con este parámetros
    le indicamos que sólo genere la información de cambios en el proyecto padre.
  • versionSuffix: El nombre de la versión es común que tenga un sufijo mientras se está desarrollando, por lo que al consultar en el Bugzilla se debe eliminar. (Por defecto «-SNAPSHOT»).
  • bugsToClose: Identifica el «status» de los bugs que deben ser cerrados al generar la versión. (Por defecto «RESOLVED, CLOSED»).
  • bugsToMove: Identifica el «status» de los bugs que deben ser movidos al nuevo «milestone». (Por defecto «UNCONFIRMED, NEW, ASSIGNED, REOPENED»).

Además de estos parámetros hay que tener en cuenta al proyecto de Maven que también debe ser accesible desde nuestro plugin, por lo que en
nuestro código debemos añadir:

El proceso principal de nuestro plugin se realiza en el método «execute()»
que necesariamente debe implementar al heredar de «org.apache.maven.plugin.AbstractMojo».
Los pasos que sigue son:

  • Preprocesamiento de parámetros: Para controlar si seguir con la ejecución
    y preparar los datos necesarios para el resto del proceso.
  • Login en el Bugzilla.
  • Crear la nueva versión en el Bugzilla.
  • Cerrar los bugs que soluciona la nueva versión.
  • Crear un nuevo «milestone» para la próxima versión.
  • Cambiar el milestone de los bugs que no están solucionado al nuevo milestone creado.

El código del método «execute()» es:

Como se puede ver en el código, después de un procesamiento previo de los
parámetros se empieza con las peticiones al Bugzilla; hacemos el login y
simulamos la navegación por las páginas del Bugzilla para ir ejecutando las acciones que estamos automatizando.

Esta navegación la realizamos con la librería «httpunit«;
por lo que añadimos su dependencia en el fichero pom.xml:

A modo de ejemplo, ponemos parte del código en el que se muestra como simulamos la navegación utilizando httpunit.
Primero hay que crear una conversación, que viene a ser como una sesión con el servidor:

y después realizamos la serie de peticiones … (en este caso el login):

De esta forma, siempre y cuando utilicemos la misma conversación, podemos
seguir haciendo peticiones al servidor bajo la misma sesión. Así pues, el resto
de acciones en el Bugzilla lo realizaremos con la misma conversación (sesión).
Se irán solicitando formularios y enviándose, de forma que se llevarán a cabo todas las acciones previstas.

Ahora sólo queda hacer que nuestro plugin pueda ser utilizado desde otros proyectos instalándolo en nuestro repositorio local ejecutando:

Utilizando nuestro plugin.

Éste plugin lo deberemos ejecutar cuando generemos una «release» con Maven.
Por lo que el plugin debe estar incluido en los proyectos en su fichero «pom.xml» de la siguiente forma.:

De los parámetros de configuración de nuestro plugin, se pueden considerar
un poco distintos los parámetros «bugzillaUser» y «bugzillaPassword», ya que
es algo particular de cada usuario. Al ser el «pom.xml» un fichero que se suele
compartir, no es aconsejable que aparezcan estos datos; por lo que nos valemos de
las ventajas de Maven para recuperarlos del perfil activo en el fichero «settings.xml»;
de esta forma en nuestro fichero «setting.xml» deberá aparecer:

Finalmente sólo queda que nuestro plugin se ejecute. Para eso añadimo el «goal» específico a la línea de comandos para que el contexto de Maven llame a la ejecución de nuestro plugin:

Línea de comandos

Como no todo es Maven en esta vida, ni Java, y podemos tener en Bugzilla la
gestión de otros proyectos, hemos añadido la posibilidad de ejecutar este plugin
desde la línea de comandos pasándole los parámetros necesarios.

Conclusiones

Como hemos visto varias veces, el desarrollo de plugins de Maven nos sirve
para completar nuestras necesidades. En este caso, al tener la generación de
versiones con Maven, parece lógico que aquellas acciones que podamos ir automatizando
las hagamos en un plugin propio de Maven, que se ejecutará al generar una nueva versión.

Si queréis todo el código fuente de este plugin lo podéis conseguir en
sourceforge.

Documentación extra la podéis encontrar
aquí.

Un saludo.
Borja Lázaro de Rafael.

Dejar respuesta

Please enter your comment!
Please enter your name here