git, maven y jenkins: flujo de trabajo de versiones, desarrollo y lanzamiento de compilaciones

¿Cuál es la forma preferida de hacer lo siguiente con git, maven y jenkins?

Estoy desarrollando una aplicación, que me gustaría mantener las ramas "dev" y "release". Me gustaría que Jenkins construyera ambos. Puede ser que los artefactos de lanzamiento tengan versiones como 1.5.2 y las compilaciones de desarrollo sean 0.0.1-SNAPSHOTs. Me gustaría no tener que tener 2 archivos pom.xml diferentes.

Miré en los perfiles, pero parece que no pueden cambiar las versiones de artefactos. Una forma en que miré podría ser agregar un 'calificador' a las compilaciones de prueba. Por supuesto, podría cambiar el nombre del archivo, porque la información real del artefacto sobre esto no es importante, porque la aplicación es independiente.

¿Cuál sería la forma preferida de hacer esto? ¿O cómo harías esto?

Me imagino que debería haber una relación inherente entre estas ramas que debería abordar el problema de los números de versión.

Liberando

Me imagino que podría hacer algo como fusionar código listo para producción de la rama de desarrollo a la rama de lanzamiento, luego realizar una versión de Maven (a través de Jenkins o manualmente). Esto automáticamente pasa los números de versión a la próxima versión. Por lo tanto, combina el código 1.4.7-SNAPSHOT en esta rama, realiza la versión de lanzamiento y corte 1.4.7, y Maven lanza automáticamente su copia de trabajo a 1.4.8-SNAPSHOT.

Actualización de línea de base (opcional)

Si todavía no está utilizando su troncal (o rama de línea de base, etc.) como un lugar para sus lanzamientos, debería actualizar el troncal tan pronto como complete un lanzamiento. Esto significa que sus números de versión también se actualizan. Este paso podría ser discutible si solo considera que la rama de lanzamiento es la línea de base.

Up-merge de Baseline a Dev Branch

Es esencial que su rama de desarrollo se mantenga actualizada con el código de producción real . Debe fusionar el código desde la línea base (o la rama de lanzamiento, según la implementación) hasta su rama de desarrollo. Esto es importante en su caso porque significa que los cambios de pom que ocurrieron durante el proceso de lanzamiento, que cambiaron la versión a 1.4.8-SNAPSHOT, se llevan a esta rama.

Según la lectura que he hecho (así como los procesos en mi organización), este parece ser un uso bastante estándar y efectivo de las versiones e instantáneas de Maven, y en lugar de mantener números de versión completamente desconectados en diferentes ramas, es fácil saber que cualquier compilación 1.4.7-SNAPSHOT fue de hecho un predecesor inmediato de la versión 1.4.7. Están relacionados Llegaría al extremo de decir que si no se está fusionando entre estas ramas, está haciendo mal el control de versiones de SCM y Maven, y se está poniendo en riesgo de desarrollar código que no coincide con la producción , reintroduce errores en la producción, etc.

Reconsidera tu enfoque.

Es muy común usar, por ejemplo, 1.4.2 para una versión de lanzamiento y luego 1.4.3-SNAPSHOT para el desarrollo de la próxima.

Cuando necesite mantener la versión 1.4.2 ENTONCES, bájela del commit que originó su artefacto 1.4.2.

Luego le dice a Jenkins la ubicación de su repositorio y el nombre de la rama, lo que da como resultado que se extraiga un conjunto de archivos, y luego le dice a Jenkins que use maven en su proyecto para construirlo.

Nota: He descubierto que es muy beneficioso usar un solo pom.xml para construir el artefacto real y otro pom.xml para crear los bits reales para el cliente.