Nous lançons un projet Java avec Maven d'une nouvelle manière

Nous sommes tous habitués depuis longtemps à Maven , aux versions qu'il propose et à la gestion des dépendances. Maven est né lorsque l'assemblage quotidien du projet était la partie audacieuse, alors qu'il était considéré comme normal de sortir au moins deux fois par an, Jenkins s'appelait alors Hudson , et les arbres étaient gros ...

Les idées que maven a apportées au monde du développement ont été extrêmement populaires et ont rapidement gagné en popularité: définir un projet de workflow standard, un modèle de répertoire standard, et bien plus encore, qui a longtemps été considéré comme acquis.

Parmi les innovations, maven a introduit un système de versioning standard. La version était stockée dans le fichier de projet et changée chaque fois que nous publions une nouvelle version. Dans un monde où faire une branche et son merjunt n'était pas un exploit accessible à tous, une telle approche était assez courante.

Tout cela a grandement simplifié le développement, le démarrage de nouveaux projets, l'introduction des développeurs au projet, la sortie de la version et la gestion des dépendances.

Mais le monde ne reste pas immobile, et malgré le fait que de nombreuses idées mises en œuvre par maven vivent et passent d'un projet à un autre, le versionnage de maven est devenu plus un problème qu'un avantage.

Ensuite, nous essaierons de changer le monde pour le mieux et de simplifier nos vies.


Dans les réalités modernes, la publication de plusieurs versions par semaine et même par jour est considérée, sinon la norme, alors l'objectif. Et, dans de telles conditions, le stockage de la version dans le fichier de projet entraîne une surcharge très importante.

Chaque version entraîne deux validations dans le référentiel et, par conséquent, avec le développement actif et la publication du projet, il existe plus de validations techniques que d'utiles. L'histoire du projet est jonchée et difficile à comprendre.
De plus, cette approche conduit à la duplication des informations: il est devenu habituel de stocker la version non seulement dans le fichier de projet, mais également sous la forme d'une balise de référentiel.

En outre, la question de sécurité s'est posée: lorsque vous avez un grand projet, la machine de génération n'a besoin d'y accéder que. Lorsqu'il y a beaucoup de projets, l'accès à de nombreux projets est nécessaire et nous créons soit un super utilisateur avec accès à tous les projets avec le droit d'écrire, soit nous obtenons la charge supplémentaire d'administrer un grand nombre d'utilisateurs avec un ensemble restreint de droits, mais toujours avec le droit d'écrire dans le référentiel, et souvent, et le droit de s'engager auprès du maître sans pool de demandes et d'examen.

Lorsque vous utilisez maven avec le plug-in de publication, une autre fonctionnalité intéressante apparaît: la reconstruction n'est pas effectuée avec le même ensemble de commandes que la version d'origine.

Peut-être que tous ces problèmes sembleront farfelus à quelqu'un, mais avec un nombre plus ou moins important de projets, la gestion et la configuration de CI / CD se transforment en un processus extrêmement désagréable et déroutant.

Maintenant que le problème est visible, essayons de le résoudre, afin de ne pas modifier l'ensemble des outils, des processus, et en général, de manière à ce qu'il soit lui-même en quelque sorte.

Ce qui est requis:

• la version est stockée une fois, en tant que balise de référentiel
• la reconstruction de n'importe quelle version est possible, l'ensemble des étapes doit être le même que dans le cas d'une nouvelle version
• n'ont pas besoin d'autorisations d'écriture dans le référentiel
• nous utilisons toujours maven comme chef de projet

Supposons que CI / CD obtienne une étiquette pour nous et vérifie un projet.

Supposons que la balise pour nous soit remplie de CI / CD dans la variable d'environnement RELEASE_TAG, puis, pour publier la version, nous devons exécuter les commandes suivantes:

mvn -B versions:set -DnewVersion=$RELEASE_TAG (1) mvn -B deploy (2) 

1 - met à jour les versions dans les fichiers pom du projet et de ses modules
2 - construit et, si le projet est configuré correctement, télécharge des artefacts dans le référentiel

N'oubliez pas de définir l'indicateur -B , sinon le journal d'exécution se transforme en citrouille.

Important: afin d'éviter toute confusion et de montrer clairement d'où et d'où vient l'assemblage, vous devez installer la version du projet dans quelque chose d'abstrait, par exemple DEVELOPMENT-SNAPSHOT. Vous pouvez utiliser la même commande: version: set. L'opération est une opération ponctuelle, car nous ne stockons plus la version du projet dans un fichier.

À la suite des modifications, vous pouvez supprimer la configuration maven-release-plugin et scm block du fichier pom.

»Des inconvénients:
Si vous utilisez les versions SNAPSHOT quelque part, alors la confusion peut commencer, maintenant toutes les versions SNAPSHOT se ressemblent. Et peut-être que cette façon de publier des projets n'est pas pour vous.

Il peut sembler que l'artefact collecté à partir du même commit mais avec des balises différentes sera le même, mais, malheureusement, ce n'est pas le cas. Nous exposons toujours la version dans le fichier et, par conséquent, les packages collectés seront différents.

»Des pros:

• Toutes les exigences sont remplies et encore plus!
• la version est stockée uniquement dans la balise de projet
• l'assemblage de la nouvelle et la reconstruction de l'ancienne version sont effectués par le même ensemble de commandes que la version originale
• pas besoin de droits pour s'engager dans le projet
• la boîte à outils reste la même
• bonus: configuration du projet simplifiée

Ainsi, deux lignes ont à nouveau sauvé le monde.
C'est tout, merci de votre attention!