Qui sommes-nous
Chez 1C, nous développons non seulement une plateforme sur и , mais aussi des applications Java - notamment le nouvel environnement de développement basé sur Eclipse et un serveur de messagerie profondément intégré à la 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 À partir de la version 3.5.0-beta-1, Maven n'incluait pas la prise en charge des « espaces réservés ». L'essence de ces substituts est que pom.xml au lieu d'une indication spécifique de la version du projet, des variables sont utilisées ${révision}, ${sha1} и ${liste de modifications}. Les valeurs de ces propriétés elles-mêmes sont définies soit dans l'élémentpropriétés>, ou ils peuvent être définis via une propriété système
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 sur le site du projet Maven Apache
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 . Ce plugin résout toutes les variables du pom, mais supprime en même temps de nombreuses autres informations qui ne sont nécessaires que lors de l'assemblage et qui ne sont pas nécessaires lors de l'importation d'artefacts publiés dans d'autres projets. Le plugin « redresse » également toutes les dépendances parent-enfant et, par conséquent, vous obtenez un pom plat qui comprend tout ce dont vous avez besoin. L’inconvénient était que cela supprimait trop de « extra », ce qui ne nous convenait pas du tout. Après avoir étudié les informations sur le développement de ce plugin, il s'est avéré que nous ne sommes pas seuls dans l'univers, et en août 2018, une pull-request a été créée sur Github dans le référentiel du plugin avec le désir de le rendre possible. pour déterminer par nous-mêmes comment « gâcher » pom.xml. Les développeurs ont écouté les voix de ceux qui souffrent, et déjà en décembre, avec la sortie de la nouvelle version 1.1.0, un nouveau mode, solveCiFriendliesOnly, est apparu dans le plugin flatten-maven, qui était plus adapté que jamais - il laisse pom.xml tel quel, à l'exception de l'élément et permet ${révision}, ${sha1} и ${liste de modifications}.
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
