mejores prácticas para Maven de versiones diferentes ramas [Desarrollo, QA/pre-lanzamiento]

Question

Tengo un par de proyectos que se desarrollan y se liberan en diferentes ramas, a saber de desarrollo y liberación . El proceso funciona bastante bien, pero desafortunadamente tiene algunos inconvenientes y me he estado preguntando si hay un mejor esquema de control de versiones para aplicar en mi situación.

El desarrollo principal ocurre en una rama de desarrollo (es decir, Subversion trunk pero no importa mucho) donde el equipo de desarrolladores confirma sus cambios. Después de construir y empacar artefactos, Jenkins los despliega en el repositorio de maven y en el servidor de aplicaciones de integración de desarrollo. Este es un desarrollo de instantáneas y básicamente es sólo un feature branch que contiene todas las características desarrolladas sobre una rama común:

<groupId>pl.cyfrowypolsat.process-engine</groupId> 
<artifactId>process-engine</artifactId> 
<version>D.16-SNAPSHOT</version> 

Cuando un cambio de negocio en particular está hecho y pidió por el equipo de control de calidad, este único cambio, entonces se fusionó a la lanzamiento de la rama (branches/release). Jenkins despliega el artefacto resultante de servidor de aplicaciones de control de calidad:

<groupId>pl.cyfrowypolsat.process-engine</groupId> 
<artifactId>process-engine</artifactId> 
<version>R.16-SNAPSHOT</version> 

Luego hay una liberación que pasa a través de Maven-release-plugin en la versión rama versión del software (que crea un mantenimiento de la etiqueta/rama de corrección de errores rápida). (R.16-SNAPSHOT => R.16)

Las ramas de desarrollo y publicación se están versionando actualmente como D.16-SNAPSHOT y R.16-SNAPSHOT, respectivamente. Esto permite separar artefactos en el repositorio de maven, pero crea un problema con diferentes mecanismos maven que se basan en el estilo de versión Maven estándar. Y esto también rompe el control de versiones de OSGI.

Ahora, ¿cómo nombrarías y harías los artefactos de maven en tal esquema? ¿Hay una mejor manera? ¿Tal vez podría hacer algunos cambios en las estructuras maven además de simplemente cambiar los esquemas de control de versiones y nombres? Pero necesito mantener las ramas SCM de desarrollo y control de calidad (versión) separadas.

¿Sería un clasificador maven de 'desarrollo'/'producción' una alternativa razonable?

<groupId>pl.cyfrowypolsat.process-engine</groupId> 
<artifactId>process-engine</artifactId> 
<version>16-SNAPSHOT</version> 
<classifier>D</classifier> 

Answer 1

Por lo que yo sé, una extensión de denominación común para un artefacto de lanzamiento sería sólo el nombre del artefacto, sin ningún tipo de cosas, sólo la versión especificada. Una rama de desarrollo tendría el mismo nombre de artefacto pero con instantánea.

Por ejemplo, tome twitter4j. El nombre artefacto de la versión de lanzamiento es

Twitter4J-2.5.5

instantánea de su (su) versión de desarrollo

Twitter4J-2.6.5-SNAPSHOT

Esa es la convención de nomenclatura que casi todos usan y es reconocida por la mayoría de las herramientas. Por ejemplo, mi repositorio de Nexus puede especificar una política para ignorar las versiones de desarrollo, lo que básicamente significa que ignora los artefactos que contienen -SNAPSHOT en su nombre.

EDIT: A su pregunta de seguimiento:

Bueno, dependiendo de su herramienta de construcción, puede crear instantáneas de tener la marca de tiempo o algún otro identificador único. Sin embargo, nunca he escuchado acerca de la incrustación de una lógica de bifurcación en el nombre del artefacto solo para que el servidor int continuo pueda distinguirla. Desde la perspectiva del artefacto, es una versión, o una INSTANTÁNEA, no veo el beneficio de incluir más lógica en el nombre del artefacto simplemente porque tu Hudson te permite hacerlo. Para ser honesto, su ciclo de lanzamiento me parece bien, pero requeriría un ajuste fino de sus herramientas de maven. Si no puede vivir con eso, le sugiero que use un clasificador en lugar de confiar en el nombre, ya que siempre es más fácil ajustar el servidor de integración que muchos complementos que dependen de la convención de nomenclatura estándar. En conclusión, creo que estás en el camino correcto.

Answer 2

El complemento de lanzamiento de Maven es compatible con branching. Parece funcionar suponiendo que la rama se crea para admitir la próxima versión de su código.

Personalmente, estoy más inclinado a usar el complemento versions, y establecí explícitamente los números de versión de mi proyecto Maven.

Answer 3

Creo que se podría simplemente el proceso por tener sólo dos tipos tan lejos como experta se refiere

1. instantánea (En desarrollo perpetua)
2. liberables (con un número de versión que se puede implementar al repositorio de Maven o la liberación de producción)

me gustaría manejar su ramificación un poco diferente, Si nos fijamos en el modelo de desarrollo iterativo/scrum su código debe ser desmontable/entregable al final de una iteración/Sprint

• versión sub tronco principal es que los desarrolladores se comprometen su código
• Al final del sprint/rama iteración del tronco principal y lo llamó liberan rama (que no debería ser una rama de QA cualquier código que va a ser liberado está probado para la calidad)
• Corrección de errores deben ocurrir en la rama de lanzamiento y se fusionó periódicamente al tronco principal
• esta manera se puede seguir creando ramas para una liberación y cualquier corrección de errores se han comprometido a ramificarse
• Asegúrese siempre antes de crear una nueva rama desde el tronco principal, tiene todas las fusiones de pr evious branches