Lanzamiento de Maven a través de Hudson

Question

Estoy configurando Hudson para usar el complemento de tarea por lotes para hacer las versiones de maven a nuestro repositorio interno. Lo estoy haciendo a través de:

mvn --batch-mode release:prepare 
mvn --batch-mode release:perform 

estoy interesado en otras personas han utilizado métodos y las ventajas y desventajas de estos métodos. Además, cualquier gente de gotchas se ha encontrado.

Answer 1

he tendido a hacer los comunicados siempre a mano por varias razones. Primero, si tiene que retroceder, es más fácil cuando puede regresar a la ubicación de lanzamiento original y hacerlo. En segundo lugar, porque necesita resolver todas las dependencias de instantáneas como parte del proceso.

Nuestro proceso de desarrollo nos tiene dejando dependencias externas a la compilación actual en la versión de lanzamiento anterior hasta que una solución requiera una actualización. Esto significa que si estoy lanzando Nexus, Maven, etc., entonces veo instantáneas y significa que tengo que salir y liberar las primeras. Este proceso no es realmente posible de automatizar, ya que varía en función de lo que ha cambiado desde la última versión.

Dicho esto, tenemos una configuración de máquina especial (en Sonatype solo es una vm) solo para compilaciones. Esto se hace para garantizar que no se produzcan cambios ambientales que puedan influir en una creación accidental (como un cambio jdk). También facilita que cualquiera pueda retomar el proceso de lanzamiento porque siempre está listo para funcionar.

Answer 2

siempre he disparado un comunicado de forma manual con ventajas y desventajas obvias :-)

Answer 3

Hemos estado experimentando con el complemento de lanzamiento de Hudson Maven, aunque me siento un poco desafiado por conseguir que acredite correctamente las versiones, sin cosas malvadas como contraseñas de codificación en nuestros archivos de compilación.

Answer 4

Recientemente, un complemento m2release llamó mi atención. Parecía agradable. Aunque, me hubiera gustado que mi proceso de lanzamiento fuera completamente «pom-tweak-free». Lo que quiero decir con esto es que tenemos para proporcionar 4 parámetro de entrada para procesar una liberación completa: (Ex. 1.0.0)

1. la versión de lanzamiento
2. la nueva versión de desarrollo (ex 1.0.1-. INSTANTÁNEA) etiqueta
3. la liberación en SCM (ex. liberar-1.0.0 o 1.0.0)
4. la ruta de la base de etiqueta en SCM

el primero 2 tienen valores predeterminados aceptables. La versión toparse con el dígito de la versión de corrección de errores está perfectamente bien para mí.

El número 4 se puede especificar en el pomo. No cambiará

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-release-plugin</artifactId> 
    <configuration> 
     <tagBase>https://example.com/svn/myProject/releases</tagBase> 
    </configuration> 
</plugin> 

Es el tercero que me impide una automatización completa de una versión con solo presionar un botón. La etiqueta de la liberación por defecto no lo hará por nosotros lo que tenemos que especificar que:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-release-plugin</artifactId> 
    <configuration> 
     <tag>release-${pom.version}</tag> 
     <tagBase>https://example.com/svn/myProject/releases</tagBase> 
    </configuration> 
</plugin> 

Ahora, si bien esto podría ser justo lo que necesitaba, me acaban de tener una etiqueta con el SVN en el -SNAPSHOT fin. :(Así que tengo que pasar el parámetro de etiqueta en la configuración de trabajo de Hudson. Además, tengo que cambiarlo para cada versión que hagamos ... que no es exactamente lo que necesito.

---

Así que, al final, tener un proyecto de tipo maven2 en Hudson + el plugin m2release Hudson + la liberación experta en el plugin configurado correctamente es la madre de todo el proceso de liberación que he visto hasta ahora. Si bien no es perfecto, me ahorró mucho trabajo tiedous.

JS.