Qui sommes-nous
Chez 1C, nous développons non seulement une plateforme
Entrée
Nous utilisons le plus souvent maven comme système de construction d'applications Java, et dans ce court article, nous aimerions parler de l'un des problèmes auxquels nous avons dû faire face dans le processus d'organisation du développement, et de l'approche qui nous a permis de surmonter ce problème. problème.
Conditions préalables et flux de travail
En raison des spécificités de développement de nos projets maven, nous utilisons beaucoup de modules, de dépendances et de projets enfants. Le nombre de fichiers pom dans une arborescence peut se chiffrer en dizaines, voire en centaines.
Il semblerait : ce n’est pas grave, ils l’ont créé une fois et l’ont oublié. Si vous devez modifier ou ajouter quelque chose dans tous les fichiers à la fois, il existe de nombreux outils pratiques dans les éditeurs et les IDE. Quelle est la modification régulière la plus courante apportée à pom.xml ? Nous pensons que les changements dans les versions et les dépendances du projet. Peut-être que quelqu'un voudra contester cela, mais c'est exactement notre situation. La raison réside dans le fait que, parallèlement au noyau, nous développons simultanément plusieurs de nos propres bibliothèques et que, pour la reproductibilité constante des résultats de construction et de test, l'utilisation d'instantanés ne nous semble pas une approche pratique. Pour cette raison, il est nécessaire d’augmenter le numéro de version dans les projets à chaque build.
De plus, de temps en temps, un développeur doit créer sa propre branche d'une bibliothèque et vérifier ses fonctionnalités par rapport à toutes les dépendances, pour lesquelles il doit modifier manuellement la version de chacune d'elles.
Solution initiale
Avec des changements de version aussi fréquents et multiples, je souhaite simplifier et automatiser le processus au sein de CI. C'est là qu'un plugin pratique et bien connu vient à la rescousse. versions-maven-plugin - connectez-le et lancez-le
mvn -N versions :set -DnewVersion=2.0.1
et Maven fera tout comme il se doit : il parcourra la hiérarchie de haut en bas, en remplaçant toutes les versions - beauté ! Il ne vous reste plus qu'à lancer une pull request, vos collègues examineront les modifications et vous pourrez rapidement rejoindre le tronc. Rapidement? Peu importe comment c'est. Quelques centaines pom.xml pour examen, et cela ne compte pas le code. De plus, personne n’est à l’abri de conflits de fusion avec un si grand nombre de fichiers modifiés. Il convient de noter ici que dans le processus CI, les changements de version se produisent automatiquement avec les changements de fonctionnalités, et non séparément.
Nouvelles fonctionnalités
Pendant un moment, nous nous sommes calmés et, résignés, nous avons vécu comme ça jusqu'à ce que les gars de
mvn -Drevision=2.0.0 paquet propre
Les valeurs des propriétés système sont prioritaires sur les valeurs définies danspropriétés>.
Parent
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-parent
Premier amical CI
${révision}${sha1}${changelist}
...
1.3.1
-INSTANTANÉ
Descendant
4.0.0
org.apache.maven.ci
ci-parent
${révision}${sha1}${changelist}
org.apache.maven.ci
ci-enfant
...
Si vous souhaitez créer la version 2.0.0-SNAPSHOT, utilisez simplement
mvn -Drevision=2.0.0 paquet propre
Si vous souhaitez publier une version, réinitialisez simplement SNAPSHOT
mvn -Dchangelist= paquet propre
*Les exemples ci-dessus sont tirés de
La dure réalité
Tout est bon et sain, il est temps d’éprouver un sentiment de satisfaction, mais non. Il s'avère que cette méthode ne fonctionnera pas pour l'installation et le déploiement, puisqu'elle ne sera pas remplacée dans les descriptions des artefacts publiés dans le référentiel. ${révision} sur sa signification et maven ne comprendra plus de quoi il s’agit.
org.apache
apache
${révision}
Une lumière au bout d'un tunnel
Nous devons chercher une solution au problème. J'aurais pu sauver la situation
Ajout d'un plugin au projet
org.codehaus.mojo
aplatir-maven-plugin
1.1.0
vrai
résoudreCiFriendliesOnly
aplatir
processus-ressources
aplatir
aplatir.nettoyer
faire le ménage
faire le ménage
Fait!
Fin heureuse
Désormais, afin de changer la version de l'ensemble du projet et d'en informer toutes les dépendances, il suffit d'éditer l'élémentrévision> juste à la racine pom.xml. Ce ne sont pas cent ou deux de ces fichiers présentant la même modification qui arrivent à l'examen, mais un seul. Eh bien, il n'est pas nécessaire d'utiliser versions-maven-plugin.
Source: habr.com