Maven et continuous delivery

[Nicolas]

Hello!

Je suis en train de mettre en place le continuous delivery (CD) avec maven. C'est un sujet couvert par un certain nombre de présentation (eg. http://www.slideshare.net/wakaleo/continuous-deliverywithmaven). Une couverture qui porte généralement sur l'applicatif en lui même et pas sur ces dépendances.

Par exemple j'ai un applicatif W. Chaque packaging fixe la version avec un build number qui s'incrémente (1.0.0-1, 1.0.0-2...). Quand tout est OK, la version avec le dernier build number peut monter dans l'environnement supérieur.

Quid quand W dépend de librairies en cours de developments avec des cycles de vie différents, donc qui n'ont pas la même version ? Si je suis le raisonnement standard Maven, je release les dépendances puis je modifie le POM de W avec les versions releasées avant de pouvoir déployer W. Le coté continuous en prend un coup.

Je creuse une solution qui consiste à gérer les dépendances également en CD. La dépendance D1 a par exemple la version 1.4.0-SNAPSHOT et est packagé et déployé en 1.4.0-1....  W dépend non pas du snapshot de D1 mais d'une version déployée (eg 1.4.0-1). La problématique porte sur comment faire dépendre W de D1 ? L'unique solution que je vois est d'utiliser les ranges de version maven : W dépend de D1 sur le range [1.4.0,1.4.0-99999].  Au packaging de W il est possible ensuite de fixer la version de D1 via le plugings versions (resolve range mojo). L'inconvénient est que cela simule une version snapshot sans jamais réellement fixer la version par une release: W peut être releasé sur une version 1.4.0-10 de D1 alors qu'une version 1.4.0-11 existe.


Qu'en pensez vous? Comment gérez vous ce type de cas ?


Nicolas

[Cédric Champeau]

Je pense que tu tombes sur une typique limite de la gestion des snapshots sous Maven. J'ai bien envie de te dire de te tourner vers Gradle...

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Nicolas]

Le lundi 8 juin 2015 15:52:50 UTC+2, Cédric Champeau a écrit :

Je pense que tu tombes sur une typique limite de la gestion des snapshots sous Maven. J'ai bien envie de te dire de te tourner vers Gradle...

Comment Gradle gererait ce genre de cas?


 

[Cédric Champeau]

Le 8 juin 2015 15:59, Nicolas <nit...@gmail.com> a écrit :

Le lundi 8 juin 2015 15:52:50 UTC+2, Cédric Champeau a écrit :

Je pense que tu tombes sur une typique limite de la gestion des snapshots sous Maven. J'ai bien envie de te dire de te tourner vers Gradle...

Comment Gradle gererait ce genre de cas?

Avec des règles de numéro de version. Au lieu de pondre des SNAPSHOT, par exemple chaque commit aurait son propre numéro de version (c'est une possibilité), ou selon, tes nightlies, etc... avec une date. Et derrière tu fournis un provider de numéros de version. Par ex, tu peux définir ce que veut dire RELEASE, LATEST, ... et que les numéros en question soient calculés, cherchés depuis un serveur ou ce qui te passe par la tête. Ex: https://docs.gradle.org/2.4/userguide/dependency_management.html#sec:custom_versioning_scheme

[Nicolas]

Le lundi 8 juin 2015 16:05:49 UTC+2, Cédric Champeau a écrit :

Le 8 juin 2015 15:59, Nicolas <nit...@gmail.com> a écrit :

Le lundi 8 juin 2015 15:52:50 UTC+2, Cédric Champeau a écrit :

Je pense que tu tombes sur une typique limite de la gestion des snapshots sous Maven. J'ai bien envie de te dire de te tourner vers Gradle...

Comment Gradle gererait ce genre de cas?

Avec des règles de numéro de version. Au lieu de pondre des SNAPSHOT, par exemple chaque commit aurait son propre numéro de version (c'est une possibilité), ou selon, tes nightlies, etc... avec une date. Et derrière tu fournis un provider de numéros de version. Par ex, tu peux définir ce que veut dire RELEASE, LATEST, ... et que les numéros en question soient calculés, cherchés depuis un serveur ou ce qui te passe par la tête. Ex: https://docs.gradle.org/2.4/userguide/dependency_management.html#sec:custom_versioning_scheme

Interessant! Gradle n'est malheureusement pas une option

 

[Cédric Champeau]

Interessant! Gradle n'est malheureusement pas une option

Courage, ça le deviendra.

[François Le Droff]

Une solution est de laisser tomber les releases maven

et d'utiliser le plugin maven-version.

Axel Fontaine a écrit quelques articles intéressant sur ce sujet:

http://axelfontaine.com/blog/final-nail.html

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

François Le Droff

[Nicolas]

Le lundi 8 juin 2015 17:10:54 UTC+2, francoisledroff a écrit :

Une solution est de laisser tomber les releases maven

et d'utiliser le plugin maven-version.

Axel Fontaine a écrit quelques articles intéressant sur ce sujet:

http://axelfontaine.com/blog/final-nail.html

Il se centre sur un applicatif. Quid des dépendances?




 

[Thomas Recloux]

Je te conseille cette présentation : https://www.parleys.com/tutorial/continuous-delivery-patterns-large-software-stacks

Si je me souvient bien, les géants du web ont plutôt une approche avec un référentiel central qui contient tout et que tu build en une fois.

Thomas Recloux

[Vincent Latombe]

Salut,

dans ma boîte on a adressé ca avec le versions-maven-plugin (avec le goal update-properties).

On résout un version range et on commit le pom.xml résultant (dans un process précédant le build lui-même). Les version ranges sont fournis a la configuration du plugin plutot que directement dans les dépendances.

Le gros avantage est que tu as des dépendances qui peuvent évoluer tout en gardant une tracabilité complète du livrable. Tu peux reprendre une vieille révision et la rebuilder a l'identique car toutes les versions sont alors fixes (du point de vue du build).

Cette méthode peut s'apparenter aux systèmes de Gemfile.lock que l'on trouve en Ruby.

Vincent

Le 8 juin 2015 16:45, Cédric Champeau <cedric....@gmail.com> a écrit :

Interessant! Gradle n'est malheureusement pas une option

Courage, ça le deviendra.

[Baptiste Mathus]

Pas encore creusé le sujet, mais ça fait plusieurs fois que Jason Van Zyl parle d'un truc pour le CD fait via/par takari (sûrement à coupler avec le lifecycle spécial ?). Mais je sais pas si c'est devenu public. Sûrement à regarder.

Mes 2 centimes :)

[Vincent Latombe]

Oui les fameuses 'generations'... mais à ma connaissance ce n'est toujours pas public (mis a part http://takari.io/2014/02/03/maven-speed.html)

Vincent

[Henri Tremblay]

Ça dépend un peu comment tu vois le truc.

La première chose qui est certaine c'est que toutes les systèmes que j'ai vu en continuous delivery bypass le système Maven classique (y compris Continuous Delivery, le livre éponyme). Donc, chaque build = une release et on hacke le pom avec un sed, un versions-maven-plugin ou whatever pour fixer la version.

Ça c'est pour l'application.

Pour les dépendances, tu as deux façons de voir les choses:

1. Tu veux toujours livrer avec la dernière dépendance disponible
   
2. Tu mets à jour de temps en temps
   

Dans le second cas, une fois de temps en temps, quelqu'un met à jour les dépendances. Aidé par le versions-maven-plugin. Et en effet, ça donne un peu comme un .lock en ruby.

Dans le premier cas, il faut faire la même chose mais avec un script. Au début du build, tu vérifies s'il y a des nouvelles dépendances à jour et tu les utilises. Il faut faire attention, car tu veux sûrement utiliser uniquement les versions qui ont passé tous les tests. Pour ça, avoir un RELEASE à la fin peu sûrement aider. Ou bien avoir un repository ne contenant que les jars valider. Là je suis dans l'hypothétique car je n'ai implémenté que la solution 1 :-)

[Youen Chene]

Je me permets d'ajouter une question : vous avez des équivalents du plugin versions-maven-plugin en SBT?

[Nicolas Labrot]

2015-06-08 16:54 GMT+02:00 Vincent Latombe <vincent...@gmail.com>:

Salut,

dans ma boîte on a adressé ca avec le versions-maven-plugin (avec le goal update-properties).

Et tu n'as pas de problème avec un projet multi module où la property de la version est défini dans le parent? Je n'arrive pas à faire en sorte qu'il mette à jour le parent et le code

 

On résout un version range et on commit le pom.xml résultant (dans un process précédant le build lui-même). Les version ranges sont fournis a la configuration du plugin plutot que directement dans les dépendances.

Le gros avantage est que tu as des dépendances qui peuvent évoluer tout en gardant une tracabilité complète du livrable. Tu peux reprendre une vieille révision et la rebuilder a l'identique car toutes les versions sont alors fixes (du point de vue du build).

Cette méthode peut s'apparenter aux systèmes de Gemfile.lock que l'on trouve en Ruby.

Votre implémentation est très interessante. Elle permet d'avoir et le range et la version fixe.

 

Vincent

Le 8 juin 2015 16:45, Cédric Champeau <cedric....@gmail.com> a écrit :

Interessant! Gradle n'est malheureusement pas une option

Courage, ça le deviendra.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse lescast...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/lescastcodeurs.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

LilActu.fr Agrégateur de News
http://lilactu.fr

[Vincent Latombe]

Typiquement dans le parent on déclare du dependencyManagement (au moins un par propriété a mettre à jour). Puis dans les modules qui contiennent du code je n'ai que des groupId/artifactId(/scope?) dans les dépendances.

D'ailleurs en pratique la notion de BOM (http://blog.xebia.fr/2014/02/28/la-notion-de-bom-avec-maven/) est très utile et se marie bien avec cette solution, cela évite d'avoir plusieurs entrées pour les différents modules d'un même projet.

Et vu la manière de fonctionner du versions-maven-plugin (pour chaque ref de la propriété, je recupère la liste des versions dispo et je prends la dernière toutes dépendances confondues), on gagne également du temps.

Vincent

[Nicolas]

J'ai tronquée la phrase mon dernier post:

"Je n'arrive pas à faire en sorte qu'il mette à jour le parent et le code"

=> Je n'arrive pas à faire en sorte qu'il mette à jour le parent et le code du plugin montre a priori qu'il ne traite pas la hiérarchie.

Le mardi 9 juin 2015 08:13:36 UTC+2, Vincent Latombe a écrit :

Typiquement dans le parent on déclare du dependencyManagement (au moins un par propriété a mettre à jour). Puis dans les modules qui contiennent du code je n'ai que des groupId/artifactId(/scope?) dans les dépendances.

D'ailleurs en pratique la notion de BOM (http://blog.xebia.fr/2014/02/28/la-notion-de-bom-avec-maven/) est très utile et se marie bien avec cette solution, cela évite d'avoir plusieurs entrées pour les différents modules d'un même projet.

Et vu la manière de fonctionner du versions-maven-plugin (pour chaque ref de la propriété, je recupère la liste des versions dispo et je prends la dernière toutes dépendances confondues), on gagne également du temps.

Pour l'instant notre dependenciesManagement ne contient que les dependances partagées entre modules. Le modifier pour y inclure également les versions "range" est pertinent.

Merci pour ton retour d'expérience!




 

[Nicolas]

Le lundi 8 juin 2015 17:42:43 UTC+2, Thomas Recloux a écrit :

Je te conseille cette présentation : https://www.parleys.com/tutorial/continuous-delivery-patterns-large-software-stacks

Si je me souvient bien, les géants du web ont plutôt une approche avec un référentiel central qui contient tout et que tu build en une fois.

Merci, la présentation est très intéressante. L'un des élements de la conclusion est effectivement très juste quand il dit que google/linkedin ont un CI optimisé car ils y ont investi les moyens nécessaires.