proyecto - maven tutorial pdf

¿Cómo construir e implementar continuamente ramas de características con Maven? (4)

Mi equipo está utilizando ramas de características para implementar nuevas características y despliega continuamente compilaciones de instantáneas en un repositorio remoto para que los usen nuestros usuarios. Por lo tanto, ''implementar'' realmente solo significa ''distribuir a un repositorio remoto de Maven''. Actualmente solo estamos ejecutando compilaciones de integración continua para la rama principal y no las ramas de características por el siguiente motivo: estamos utilizando Maven para construir nuestros proyectos y distribuir JavaDoc y las fuentes junto con el JAR.

Mi plan consistía ahora en agregar un clasificador a cada estructura de ramas de funciones y esperaba que se utilizara al crear e implementar los artefactos de esta manera:

Rama: maestro
Clasificador: ninguno
Artefactos: foo-${version} .jar, foo-${version}-sources .jar, foo-${version}-javadoc.jar
Sucursal: feature-X
Clasificador: myfeature
Artefactos: foo-${version}-feature.jar , foo-${version}-sources-feature.jar , foo-${version}-javadoc-feature.jar

Realmente no me importa el nombre exacto del artefacto, solo necesito artefactos principales, fuente y JavaDoc separados para la rama de características. Resulta que ni el complemento JavaDoc ni el complemento fuente consideran que el clasificador está configurado y, por lo tanto, sobrescriben los artefactos creados para mi compilación maestra.

Realmente no quiero cambiar el artefacto, aunque esto probablemente resolvería el problema. ¿Cómo se aproxima a las ramas de características y la integración continua con Maven?

En lugar de alterar las coordenadas del maven del artefacto, puede usar maven-branch-extension para crear efectivamente un espacio de nombre SNAPSHOT separado para cada una de las ramas de características. Cita de la página del proyecto:

En lugar de cambiar el número de versión cuando estamos en una rama de características, cambiamos el repositorio. Cada característica se implementa en un subdirectorio, en función de su nombre de sucursal, en un repositorio remoto que es solo para las ramas de características. No hay riesgo de que se sobrescriban artefactos. Los números de versión no cambian. La ramificación y fusión con Git se mantiene simple (¡como debería ser!).
La extensión obtiene la rama actual de Git y resuelve una propiedad en la URL del repositorio para que los artefactos puedan almacenarse y recuperarse correctamente. También gestiona el almacenamiento en memoria caché y la obtención de artefactos en el repositorio local para que los artefactos se extraigan del repositorio de ramas de características, si existen, cuando se trabaja desde una rama de características.

Lo bueno de esto es que los usuarios externos de las dependencias de SNAPSHOT están completamente aislados del trabajo interno sobre las ramas temáticas.

Sugeriría agregar el calificador de rama en el componente de versión, ya que está más relacionado con esa parte. Esto también permite sus dependencias de instantáneas en esas versiones junto a la rama principal.

Sugeriría usar una versión apropiada que represente la rama así como la versión de cosas como:

1.0.0-SNAPSHOT para el maestro

1.0.0-F1-SNAPSHOT para la característica F1

etc.

Esto proporciona también un indicador desde el cual se ha realizado la versión 1.0.0 de la rama de características.

Usar el número de versión para almacenar el nombre de la sucursal, como lo sugirieron otros, es una ganancia rápida, pero genera problemas si usa rangos de versión. El número de versión no estaba destinado a ser usado así. Los usamos en un proceso de integración continua para hacer que las pruebas de integración dependan del artefacto probado:

[1.8-SNAPSHOT,1.9-SNAPSHOT)

La parte del calificador dentro del número de versión denota diferentes etapas incrementales de la misma base de código:

1.8-alpha1-SNAPSHOT 1.8-alpha1-SNAPSHOT 1.8-beta1-SNAPSHOT

Esta es la razón por la que el rango de versiones anterior capturará lo anterior y Maven lo ordenará en este orden :

1.8-SNAPSHOT 1.8-alpha1-SNAPSHOT 1.8-alpha1-SNAPSHOT 1.8-beta1-SNAPSHOT

Cualquier artefacto que lleve el nombre de la rama de características en el número de versión ( 1.8-featureA-SNAPSHOT ) se ordenará más nuevo que las instantáneas sin calificador. Pero una rama de característica es una base de código ''diferente'', no una representación más nueva de la misma base de código. Para nuestro escenario de prueba de integración esto llevó a fallas de prueba inútiles. La rama de características aún no estaba lista para ser probada por las pruebas de integración.

Ahora seguimos esta regla: si tiene que cambiar algo de todos modos, ¿por qué no la ID del artefacto? Cambiamos la identificación del artefacto para las ramas de características y funciona muy bien.