Todos hemos estado acostumbrados a
Maven , a las versiones que ofrece y a la gesti贸n de dependencias. Maven naci贸 cuando la asamblea diaria del proyecto era la m谩s atrevida, cuando se consideraba normal que se lanzara al menos un par de veces al a帽o,
Jenkins se llamaba
Hudson y los 谩rboles eran grandes ...
Las ideas que Maven trajo al mundo del desarrollo fueron extremadamente populares y r谩pidamente ganaron popularidad: definiendo un proyecto de flujo de trabajo est谩ndar, un modelo de directorio est谩ndar y mucho m谩s, que durante mucho tiempo se dio por sentado.
Como una de las innovaciones, maven introdujo un sistema de versiones est谩ndar. La versi贸n se almacen贸 en el archivo del proyecto y cambi贸 cada vez que lanzamos una nueva versi贸n. En un mundo donde hacer una rama y su merjunt no era una haza帽a accesible para todos, ese enfoque era bastante com煤n.
Todo esto simplific贸 enormemente el desarrollo, el inicio de nuevos proyectos, la introducci贸n de desarrolladores al proyecto, el lanzamiento de la versi贸n y la gesti贸n de dependencias.
Pero el mundo no se detiene, y a pesar del hecho de que muchas ideas implementadas por maven a煤n viven y se mueven de un proyecto a otro, el versionado de maven se ha convertido en un problema m谩s que una ventaja.
A continuaci贸n, intentaremos cambiar el mundo para mejor y simplificar nuestras vidas.
Descargo de responsabilidadSupongo que el lector est谩 familiarizado con Java, Maven, el ciclo de vida del desarrollo y la configuraci贸n de CI / CD, entiende por qu茅 necesita todo esto e incluso un ninja .
En las realidades modernas, el lanzamiento de varias versiones por semana e incluso por d铆a se considera, si no la norma, el objetivo. Y, en tales condiciones, almacenar la versi贸n en el archivo del proyecto conduce a una sobrecarga muy grande.
Cada versi贸n lleva a dos confirmaciones en el repositorio y, como resultado, con el desarrollo activo y la versi贸n del proyecto, hay m谩s confirmaciones t茅cnicas que 煤tiles. La historia del proyecto est谩 llena de basura y es dif铆cil de entender.
Adem谩s, este enfoque conduce a la duplicaci贸n de informaci贸n: se ha vuelto habitual almacenar la versi贸n no solo en el archivo del proyecto, sino tambi茅n en forma de una etiqueta de repositorio.
Adem谩s, surgi贸 la pregunta de seguridad: cuando tiene un proyecto grande, la m谩quina de compilaci贸n solo necesita acceso a 茅l. Cuando hay muchos proyectos, el acceso a muchos proyectos es necesario y creamos un s煤per usuario con acceso a todos los proyectos con derecho a escribir, o tenemos la carga adicional de administrar una gran cantidad de usuarios con un conjunto limitado de derechos, pero a煤n con el derecho de escribir en el repositorio, y a menudo, y el derecho de comprometerse con el maestro sin grupo de solicitud y revisi贸n.
Cuando se usa maven con el complemento de lanzamiento, aparece otra caracter铆stica interesante: la reconstrucci贸n no se realiza con el mismo conjunto de comandos que la versi贸n original.
Quiz谩s todos estos problemas parezcan exagerados para alguien, pero con un n煤mero m谩s o menos grande de proyectos, administrar y configurar CI / CD se convierte en un proceso extremadamente desagradable y confuso.
Ahora que el problema es visible, tratemos de resolverlo, de modo que no cambiemos el conjunto de herramientas, procesos y, en general, sea de alguna manera.
Lo que se requiere:
- la versi贸n se almacena una vez, como una etiqueta de repositorio
- es posible reconstruir cualquier versi贸n, el conjunto de pasos debe ser el mismo que en el caso de una nueva versi贸n
- no necesita permisos de escritura en el repositorio
- todav铆a usamos maven como gerente de proyecto
Supongamos que CI / CD obtendr谩 una etiqueta para nosotros y verificar谩 un proyecto.
Supongamos que la etiqueta para nosotros est谩 llena de CI / CD en la variable de entorno RELEASE_TAG, luego, para liberar la versi贸n, debemos ejecutar los siguientes comandos:
mvn -B versions:set -DnewVersion=$RELEASE_TAG (1) mvn -B deploy (2)
1 - actualiza las versiones en pom-files del proyecto y sus m贸dulos
2: compila y, si el proyecto est谩 configurado correctamente, carga los artefactos en el repositorio
No olvide establecer el indicador
-B , de lo contrario, el registro de ejecuci贸n se convierte en una calabaza.
Importante: para evitar confusiones y mostrar claramente c贸mo y de d贸nde proviene el ensamblaje, debe instalar la versi贸n del proyecto en algo abstracto, por ejemplo, DESARROLLO-INSTANT脕NEA. Puede usar el mismo comando: version: set. La operaci贸n es 煤nica, porque ya no almacenamos la versi贸n del proyecto en un archivo.
Como resultado de los cambios, puede eliminar la configuraci贸n de bloque maven-release-plugin y scm del archivo pom.
禄De las desventajas:
Si usa las versiones SNAPSHOT en alg煤n lugar, entonces puede comenzar la confusi贸n, ahora todas las versiones SNAPSHOT tienen el mismo aspecto. Y quiz谩s esta forma de lanzar proyectos no es para ti.
Puede parecer que el artefacto recogido de la misma confirmaci贸n pero con diferentes etiquetas ser谩 el mismo, pero, desafortunadamente, esto no es as铆. A煤n exponemos la versi贸n en el archivo y, como resultado, los paquetes recopilados ser谩n diferentes.
禄De los profesionales:
- Se cumplen todos los requisitos, 隆y a煤n m谩s!
- la versi贸n se almacena solo en la etiqueta del proyecto
- El ensamblaje de la versi贸n nueva y la reconstrucci贸n de la versi贸n anterior se realiza mediante el mismo conjunto de comandos que la versi贸n original
- sin necesidad de derechos para comprometerse con el proyecto
- la caja de herramientas permanece igual
- bono: configuraci贸n del proyecto simplificada
Entonces, dos l铆neas salvaron nuevamente al mundo.
Eso es todo, 隆gracias por su atenci贸n!