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

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.¿Cómo construir e implementar continuamente ramas de características con Maven?

Mi plan era ahora añadir un clasificador para cada característica ramas se acumulan y se espera que uno que se utilizará al crear e implementar los artefactos de este tipo:

Rama: amo
clasificador: ninguno
Artefactos: foo-${version} .jar, foo-${version}-sources .jar, foo-${version}-javadoc.jar
Rama: función X-
clasificador: myfeature
Artefactos: foo-${version}-feature.jar, foo-${version}-sources-feature.jar, foo-${version}-javadoc-feature.jar

Realmente no importa la denominación exacta del artefacto, que sólo necesitan principales, origen y JavaDoc artefactos separados para la rama de la característica . 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?

Fuente

2012-07-10 Oliver Gierke

¿Cuán estáticas son sus ramas de topoc? ¿Con qué frecuencia espera configurar un nuevo trabajo y con qué frecuencia van a ser derribados? ¿Qué usas en el servidor CI para ayudarte con eso? Esta es una de las cosas que me impide pensar en una construcción así. Tal vez un modelo de gatekeeper o servidor de CI local desarrollador sea más adecuado. – eckes

no debe usar el clasificador para reflejar la diferencia en las ramas, ya que tendrá efectos secundarios desagradables con algunos otros complementos. Se supone que los clasificadores son fuentes, javadocs, etc ... Para su necesidad, debe cambiar el artifactId o la versión. – Farid

@eckes: utilizamos Bamboo, que admite el inicio automático de un trabajo de compilación contra una rama diferente en función de una expresión regular en el nombre de la rama. Tan pronto como detecte una rama que coincida con esa expresión, prácticamente clonará un trabajo de compilación si generalmente se le indica que lo haga. –

Sugiero que se agregue el calificador de sucursal en el componente de la 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.

Fuente

2012-07-10 12:51:13 eckes

Si bien esto parece ser un buen enfoque, genera problemas al usar los rangos de número de versión (por ejemplo, para la integración continua). Ver mi respuesta –

sugeriría a utilizar una versión apropiada que representa la rama, así como las cosas de versiones como:

1.0.0-SNAPSHOT para el amo

1.0.0-F1- Descripción para la función F1

etc.

Esto da también un indicador de que liberan 1.0.0 la rama de la característica se ha hecho.

Fuente

2012-07-10 13:20:38 khmarbaise

* 1.0.0 ** es equivalente a * . . - *. * -SNAPSHOT * es parte de Maven. Además, ¿hay algún problema con eso? Simplemente no. – khmarbaise

¿Cómo instruirías a mercurial o a maven para que no incluyan la versión pom al fusionar de nuevo a master? Quiero decir que no creo que quieras resolver esto manualmente cada vez que te fusionas, ¿verdad? – Asgard

Tenemos una secuencia de comandos de instalación de rama que crea una primera confirmación con solo los cambios a los números de versión. Al fusionarnos simplemente dejamos caer este commit y squash y fusionamos todos los siguientes en esta rama (o simplemente lo seleccionamos si solo hay una segunda confirmación). –

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

[1.8-SNAPSHOT,1.9-SNAPSHOT)

La parte calificador dentro del número de versión indica las 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 gama de la versión anterior capturará lo anterior y Maven order them in this order:

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

Cualquier artefacto que lleva la rama de la característica el nombre 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.

Fuente

2015-02-19 08:47:34

si bien es cierto que la rama de características es una base de código 'diferente', sigue siendo el mismo proyecto que la compilación principal. Parece que debería haber una solución distinta a la modificación de la identificación del artefacto. No tengo uno though = (Tal vez las versiones maven son demasiado completas (rangos de soporte) o demasiado inflexibles (solo admiten 3 versiones punteadas abc como números y por defecto para cadenas para abcd) –

FWIW: Voy con completamente diferentes versiones en ramas de características. '1',' 2', '3',' 4' ... en master y 'featureA-001',' featureA-002', ... en ramas de características. Considerado 'featureA- SNAPSHOT' también, pero parecía un enfoque más complicado. –

Esto es cierto, sin embargo, el uso de rangos de versión en Maven tiene varios problemas de todos modos (como el requisito de apegarse al formato de número de versión de Maven), así que no creo que sean Se usa mucho en la práctica. Si nunca usa rangos de versión, este problema no se aplica. – sleske

En lugar de alterar las coordenadas del maven del artefacto, puede usar maven-branch-extension para crear efectivamente un espacio de nombres 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 función, cambiamos el depósito. Cada característica se implementa en un subdirectorio, según el nombre de su sucursal, en un repositorio remoto que solo se utiliza para las ramas de función . 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 entidad.

La belleza de esto es que los usuarios externos de las dependencias SNAPSHOT están completamente aislados del trabajo interno en las ramas de tema.

Fuente

2017-04-11 17:34:16

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

Respuesta

Cuestiones relacionadas