Rencontrez Koshkuke Kawaguchi créateur de Jenkins sur Paris le 6 février
Un Hackathon organisé par Zenika

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux

 Discussion forum

Le 24/01/2012, par keulkeul, Responsable Eclipse et JAVA
Avec la venue du créateur de Jenkins, Koshkuke Kawaguchi à Paris le 6 février, Zenika le cabinet d'architecture, de formation, de conseil et de réalisation Java organise un hackathon sur Jenkins. L'idée de ce type d'événement appelé hackathon est de réunir des développeurs de Jenkins afin de partager des idées autour de cette plateforme d'intégration continue.

Au programme de cet événement où Developpez.com est partenaire, quatre présentations de hauts niveaux :

19h00 - Introduction par Kohsuke Kawaguchi
19h30 - Continuous build and deployment for mobile developers par Arnaud Heritier
20h00 - Continuous Deployment with Gerrit and Jenkins par R. Tyler Croy
20h30 - XTrigger, EnvInject et d'autres plugins par Grégory Boissinot

L'événement est gratuit.

Informations supplémentaires sur le site de Zenika


 Poster une réponse

Avatar de rt15 rt15
Membre éprouvé
le 26/01/2012 16:51
Il a de la chance que je sois pas sur Paris...
Je suis obligé d'utiliser jenkins, et c'est pas une sinécure...

Je vais passer sur le fait qu'il faut 3256 plugins pour arriver à peu près à ce que l'on veut, là ou une quinzaine de lignes d'un langage de progs seraient suffisantes. Parce que tant que l'on a un petit projet java tout va bien... Mais dès que ça se complique... Dernier exemple en date : un projet java dont les tests unitaires doivent tourner, une fois en utilisant une base Oracle, une fois en utilisant une base MySQL. On a donc fait une matrice qui compile deux fois la même chose mais exécute les tests unitaires avec une base différente. Bilan, si un des deux "axe" de la matrice réussit, les artifacts sont déployés. Si les deux réussissent, les mêmes artifacts sont déployés deux fois. Génial. Mais on doit mal s'y prendre, il doit y avoir un plugin ou une case à cocher perdue au milieu du de la config pour nous sauver la mise, non ?

Mais le plus magique, ce sont les perfs. Bon, il faut dire que notre jenkins est chargé par pas mal de jobs (Des projets à n'en plus finir, des matrices d'une douzaine de machines unix et windows, des compilations de plusieurs heures incluant différents langages) . Mais le résultat est là. Tu cliques sur "Configurer", tu peux aller boire un café. Le temps de démarrage est aussi assez magique. Il y a quelque temps, jenkins était redémarrer plusieurs fois par semaine. Le hic, c'est qu'il lui fallait plusieurs heures pour démarrer. En attendant, pas de CI...

On a eu aussi pas mal d'erreur sympa du genre :

Code :




1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel
	at hudson.remoting.Request.call(Request.java:137)
	at hudson.remoting.Channel.call(Channel.java:643)
	at hudson.FilePath.act(FilePath.java:745)
	at hudson.FilePath.act(FilePath.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:684)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:633)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1174)
	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:523)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:418)
	at hudson.model.Run.run(Run.java:1362)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:145)

On a aussi eu des problèmes avec la lib java qui remplace svn. Une fois sur dix elle ne parvenait pas à faire un checkout de plusieurs de nos fichiers binaires.

Et les fuites de processus en fin de jobs, qui font planter le suivant... Un peu de notre faute, il est vrai. Mais on a eu bien du mal à balancer les kill -9 dans une bonne partie des cas d'arrêt du build. Nous aurait fallu : "dans tous les cas, réussite, échec, interruption du job... exécute CE script". Mais il y a un plugin pour ça j'imagine ??

Bref, avec jenkins faut vraiment être patient et compiler des hello world en java.

Mais la critique est toujours facile. Il est vrai Jenkins donne quand même une bonne visibilité sur l'état du source.
Avatar de efe4itcc efe4itcc
Invité de passage
le 26/01/2012 22:22
Bonjour

J'ai utilisé Hudson/Jenkins en 2010 sans rencontrer les mêmes difficultés, mais mon contexte était surement moins gourmant en ressources: 10/12 développeurs sur une application Java déployée soit en Standalone (Spring) soit en contexte J2EE (JBoss) utilisant un Backend soit MySQL soit Oracle

Nos besoins IC se sont traduit en une 15aine de Job.

Ne disposant que d'une unique VM de build, j'ai séparé ces jobs en 2 catégories:
  • les batchs longs et gourmants exécutant les tests d'intégration et donc utilisant les ressources physique BDD, etc.: planifiés la nuit (quotidien) ou le WE (hebdo) ou en fin d'itération Agile (15 jours)


  • les jobs nécessitant un feedback < 5 minutes, déclenchés par polling du SCM (ici Subversion) toutes les 5 minutes, et dont le périmètre était limité à la compilation et l'exécution des tests unitaires, en utilisant une BDD in memory (ici H2)



Je n'ai configuré qu'un seul exécuteur de job afin de garantir la durée d'exécution quasi-constante, et repérer d'éventuelles dérives.

A noter que certains plugins stockent trop d'informations dans le fichier résultats du build (ex. "greenpepper", patché depuis). Comme le contenu de tous les fichiers conservés dans l'historique des jobs est lu par Jenkins au démarrage, la durée augmente, et la RAM peut également saturer.

Pour des scénarios plus consommateurs, il me paraît indispensable de disposer de machine/VM slave afin que le master ne serve qu'à l'administration et à l'archivage des résultats et artifacts du build.

L'idéal IMHO serait de disposer d'une architecture physique scalable afin de déclencher l'IC après chaque commit. Voir du côté de la plateforme PaaS Cloudbees si on vous autorise à externaliser le processus IC dans le cloud (chez Amazon EC2 en l'occurence).
Avatar de romaintaz romaintaz
Rédacteur/Modérateur
le 27/01/2012 9:51
Bonjour rt15,

J'utilise Hudson depuis 5 ans (et Jenkins depuis un an), et je suis toujours un grand fan de cet outil.
Je l'utilise pour beaucoup de choses : builds, analyses de qualité, gestion des releases, déploiements, différents contrôles, etc.
Certes, il n'est pas parfait, mais pour moi il représente tout à fait ce que je peux attendre d'un tel outil.

Côté performances, ceci est vrai pour n'importe quel type de serveur d'IC : il faut une machine (voire plusieurs) qui tienne(nt) la charge, surtout quand on en demande beaucoup (mais il faut savoir être exigeant avec ces bêtes-là !).
C'est sûr que si tu as une forte activité sur tes projets, tu auras besoin de bonnes ressources. Mais c'est un "coût" acceptable et compréhensible. Ajouter des slaves peut être aussi une solution intéressante...
L'IC n'est pas une petite pièce de l'usine logicielle, c'est une pièce maitresse, et il faut en prendre soin !
L'idéal, comme l'a souligné efe4itcc c'est de passer par une solution de Cloud, car tu as accès aux ressources nécessaires quand tu en as besoin.
Souvent, l'activité d'une IC est faite de périodes creuses (la nuit, les WE, etc.) et de périodes très chargées. Du coup, il devient difficile de bien doser les ressources nécessaires.
Mais l'utilisation du Cloud peut effectivement aussi poser des problèmes (coûts - quoique - confidentialité, etc.), mais cela reste une solution très intéressante !

Concernant le temps de démarrage, j'admets qu'il est un peu long, dès que l'on ajoute pas mal de plugins.
De mon côté, notre Jenkins mets quelques minutes avant d'être disponible (avec une 30aine de plugins, et une 40aine de jobs, mais une machine pas suffisament costaud à mon goût), mais ce n'est guère génant car nous n'avons pas besoin de le redémarrer souvent (en général uniquement lors de sa mise à jour).

Le fait qu'il faille 300 plugins est un problème ? Oui et non. De mon point de vue, c'est plutôt un avantage d'avoir une telle profusion de plugins.
Cela montre l'intérêt de la communauté pour l'outil, et permet de répondre à un maximum de besoins.
Après, il est sûr que si l'on veut faire des choses un peu exotiques (ou des projets non Java), on va avoir besoin d'un certain nombre de plugins.
Mais n'est-ce pas mieux comme ça, plutôt que de fournir un Jenkins standard avec un millier d'options dont 80% ne seront pas utilisés par les gens ?
De plus, la très grosse majorité des plugins venant de la communauté, ils ne se valent pas tous, et il serait difficile de les intégrer dans le coeur de Jenkins.
Alors certes, au final ça coûte un peu plus en terme de démarrage, mais bon...

Mainteant, si tu préfères ne pas avoir à utiliser des plugins, rien ne t'empêche d'écrire un script, ou d'utiliser Ant / Gradle / je-ne-sais-quel-autre-outil pour le faire, et d'utiliser Jenkins comme lanceur / scheduleur. C'est tout à fait possible. L'idée est toujours de faire au plus simple !

Pour ton problème de matrice, je ne peux pas trop t'aider, car je n'ai jamais eu besoin d'avoir recours à ce type de projet.
Peut-être qu'en effet ce n'est pas la bonne façon de procéder (il faudrait en savoir un peu plus sur ton projet, et ta configuration Jenkins).
Le principe de la matrice, c'est "juste" d'exécuter un même job plusieurs fois, mais avec des paramètres / environnements différents.
Du coup, si ton job standard inclue le déploiement des artifacts, alors c'est normal qu'il déploie jusqu'à 2 fois les artifacts.
Ce que tu peux tester, c'est de modifier ton job standard afin qu'il ne déploie rien, puis d'ajouter un job déclenché par le job matrice (uniquement en cas de succès "total") qui n'aura pour but que de déployer les artifacts.
Ainsi, tes artifacts ne seront déployés qu'une seule fois, et à la condition que les jobs de la matrice se soient bien passés.

Mais n'hésite pas à poster sur le forum dédié à l'IC (http://www.developpez.net/forums/f10...tion-continue/) pour tes problèmes !
Avatar de vdaburon vdaburon
Invité régulier
le 27/01/2012 10:52
Bonjour,

Pour une grande SSII, je m'occupe des environnements d'Integration Continue mutualisés sur un beau serveur Linux (32Go de RAM, 1To DD, 1CPU 4 Coeurs).

Le produit Jenkins est vraiment très bien, facile à configurer avec des messages d'erreurs pertinents lors des installations (ex : le chemin vers un répertoire qui n'existe pas et indiqué lors de la configuration).

Le passage Hudson -> Jenkins s'est fait en douceur et très facilement.

Jenkins a réussi à créer un écosystème avec de nombreux plugins variés et de qualité.

La maintenance d'une cinquantaine de projets différents (petit à très gros) avec leurs propre instance Jenkins, Plugins Jenkins, leur propre maven est très raisonnable.

Concernant la performance, il s'agit plutôt d'un problème du projet avec sa compilation, ses tests unitaires et non pas de l'outil Jenkins qui est surtout un ordonnanceur pour déclencher des actions à période fixe (ex 2 fois par jour) ou événementiel (commit de code).

Bref, nous avons fait le choix de Hudson puis de Jenkins et nous le regrettons pas.

Merci Mr Koshkuke pour ce très bon outil.

Vincent D.


 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum Java

Blogs

Hébergement

 
Partenaires

Hébergement Web