Pregunta padre pom maven con diferentes versiones infantiles


Existen múltiples módulos en nuestras aplicaciones y cada uno de ellos tiene su versión separada y depende de otros módulos (externos a nuestra organización). Todos tienen un POM principal que tiene su propia versión, independiente de la versión infantil.

Cuando uno de esos módulos cambia, se convierten en instantáneas.

Para el siguiente ejemplo:

Parent v14.0
- module1 v1.5.0
    - dependency1(module2 v15.0.0)
    - dependency2(external-jar v12.0.1)
- module2 v15.0.0
- module3 v3.1.0

Si hubiera un cambio en el módulo 2, entonces la versión del módulo 2 se convertiría en v15.0-SNAPSHOT, luego el módulo 1 se convierte en v1.5-SNAPSHOT. El padre sigue siendo el mismo. El propósito de no tener la misma versión en los módulos principales +, es que queremos localizar las actualizaciones realizadas en algunos módulos y no afectar las versiones de otros.

Esto se diseñó de esta manera hace mucho tiempo y existen varios scripts de bash para respaldar las actualizaciones, aunque no manejan todos los casos. En cualquier caso, no tenemos un proceso de lanzamiento con un solo clic y sentimos que estamos muy lejos de este enfoque.

No sabemos cómo convencer a la administración para un enfoque de una sola versión en todos los módulos. ¿Cómo te sientes acerca de lo anterior? ¿Alguna vez se encontró con un proyecto usando la estructura anterior y qué tan bien funcionó?

¡Gracias!


5
2018-03-20 10:00


origen


Respuestas:


He tenido que lidiar con tales situaciones antes. Hay un beneficio real de tener versiones descentralizadas, especialmente en los casos en que su producto está hecho de una gran cantidad de módulos y esto se debe a los siguientes hechos:

  • No tiene que liberarlos a todos como un todo, si solo se han cambiado unos cuantos (lo cual, desde mi observación es casi siempre el caso).

  • No tiene que crear etiquetas innecesarias en su control de versión para el código que no ha cambiado desde la versión anterior.

  • No tiene que perder demasiado tiempo liberando módulos que no necesitan ser liberados.

  • Usted sabe con certeza qué módulos han cambiado en una versión, lo que ayuda mucho cuando necesita investigar un error complejo, que parece que se remonta a un tiempo atrás.

  • En realidad, puede liberar ciertos módulos / agregadores antes de la fecha de lanzamiento real del producto completo, lo que permite más tiempo de prueba y una sensación de integridad para una parte determinada del producto.

  • Puede hacer que los lanzamientos de sucursales de características sean mucho más fáciles e implementar una entrega continua de una mejor manera.

  • Puede reutilizar el mismo código en múltiples ramas de desarrollo sin preguntarse si esa versión ramificada coincide con la de su rama (o al menos con menos confusión).

Lo que terminamos haciendo fue:

  • Extraer un padre o un conjunto de padres (sin submódulos).

  • Trate de usar versiones fijas para los padres tanto como sea posible. Esto es un poco de una advertencia, ya que debe cambiar todos los módulos que lo heredan, pero al final mejora la estabilidad.

  • Extraiga cada uno de los módulos cuyas versiones son independientes del resto a módulos separados.

  • Extraiga conjuntos de módulos cuyas versiones siempre deben moverse juntas en agregadores.

  • Cree trabajos en su servidor de CI que puedan realizar liberaciones o liberar manualmente estos módulos.

  • Utilizar el versiones-maven-plugin.

Creo que es mucho más maduro que un proyecto y los principios de desarrollo de una empresa utilicen versiones descentralizadas y debo admitir que al principio me resistí mucho a este enfoque. Es posible que no se dé cuenta o entienda los beneficios de inmediato, pero con algo de práctica y una configuración adecuada, comenzará a ver los aspectos positivos. No estoy diciendo que no haya advertencias como ... por ejemplo, golpear la versión de un padre, o tener que saber en qué módulos golpear la versión de uno de sus módulos.

Desde mi experiencia, este módulo realmente funciona mejor al final, una vez que te has acostumbrado a trabajar con él.


5
2018-03-20 10:31



Desde mi experiencia: en todas partes probamos esto, eventualmente falló.

Aunque Maven apoya este enfoque, no es recomendable debido al esfuerzo adicional.

Intento usar los siguientes criterios al elegir si usar proyectos distintos o una estructura de varios módulos:

  • Si todos los proyectos tienen el mismo ciclo de publicación, los coloco en una estructura común de varios módulos. En ese caso, les doy a todos la misma versión y los libero juntos.
  • Si una parte del proyecto es utilizada por otros proyectos diferentes (proyectos organizacionales), siempre los divido y les doy un ciclo de vida separado y una versión separada.
  • Si una parte de mi proyecto se estabiliza, lo divido y le doy un ciclo de vida separado (refactorización de Maven)

Hacerlo de manera diferente siempre resulta en soluciones caseras que ni se escalan bien ni son fáciles de mantener.

Espero que ayude.


1
2018-03-20 10:22