Hudson Jenkins - Serveur d'intégration continue

Comment s'en sert-on ?

Configuration générale

La configuration général de Jenkins se fait dans "Administrer Jenkins" >> "Configurer le système" :

Informations systèmes

Dans un premier temps, il peut être (c’est sûrement le cas) de vérifier et de configurer le système de Jenkins: sécurité, où se trouve les différents outils, email…

La première chose à vérifier est le dossier d’installation de Jenkins. La première ligne doit donc être le dossier que vous avez défini lors de l’installation. Le nombre d’exécuteur corresponds au nombre de construction qui pourront être faite en parallèle. La période d’attente corresponds au temps que doit attendre un « job » entre le moment où il est déclenché et le moment où la construction commence réellement.

Gestion de la sécurité

Ici le plus important peut être la sécurité (comme pour tout). Avant toute configuration, tout le monde peut créer/configurer/exécuter/voir/supprimer un job et le contenu de l’espace de travail du job. Afin d’éviter cela, vous devez mettre en place des règles de sécurité pour que ces actions ne soit possible que pour cette personne.

Activez la sécurité, choisissez la base de donnée d’utilisateur que vous souhaitez utiliser. Dans le cas d’utilisation d’un Jenkins « isolé », prenez simplement la base de donnée de Jenkins. Pas de panique, il n’est pas nécessaire d’installer une base oracle ou MySQL en supplément. Il est également possible de caller votre Jenkins avec un serveur LDAP et même d’utiliser les groupes de votre LDAP. Ici, je vais uniquement vous parler de la configuration avec la « base de données » intégré dans Jenkins.

Dans un premier temps, laissez coché le champs pour laisser les utilisateurs s’inscrire. Sauvegarder votre configuration.

Inscrivez un nouvel utilisateur, admin par exemple, qui aura tous les droits. Retournez dans la configuration du système et décochez la case d’inscription. En faisant cela, vous vous assurez que vous seul pourrez ajouter les personnes que vous désirez. Ensuite, vous devez choisir la méthode d’autorisation que vous souhaitez utiliser:

Configuration des outils tiers

Par la suite, vous devez configurez les outils de construction de projet (Ant, Maven, JDK, G++, SVN, Mercurial…) pour que Jenkins puisse les trouver et les utiliser.

Tout ce que vous avez besoin de renseigner dans cette catégorie, c'est l'emplacement des exécutables que vous souhaitez pouvoir utiliser. De base, vous devrez indiquer l'emplacement d'un JDK, de Maven, de Ant. Avec l'installation de quelques plugins, vous pouvez mettre mercurial en plus par exemple.

Biensûr, il est possible de demander à Jenkins de télécharger et d'installer ces outils pour vous. Comme ça vous n'avez pas besoin d'avoir les droits d'administration sur la machine hôte. A noté, qu'il faut tout de même que Jenkins ai ces droits sur la machine hôte, donc qu'il est été démarré par un administrateur.

Si toute fois, vous utiliser un outil externe qui n'a pas d'équivalent en plugin (PLink, putty...) et que vous avez besoin d'effectuer des lignes de commande avec cet outil, il est possible de mettre en place une propriété global dans Jenkins. Cette propriété va agir comme une variable d'environnement mais ne touchera que Jenkins. Vous pourrez donc appeler un exécutable facilement (sans avoir besoin de mettre la chemin d'accès complet).

Gestion des plugins

Hudson vous permet d’accéder à une bibliothèque d’extensions (plugins) assez très conséquente.

L'installation d'un plugin est très simple : choisir, cocher, cliquer, utiliser. Par ici le chemin : "Administrer Jenkins" >> "Gestion des plugins"

Choisir les plugins qui vous intéresse :

En bas de la page, vous trouverez le bouton pour installer votre sélection de plugins. Un petit redémarrage de Jenkins et s'est bon, vous pouvez les utiliser.

La mise à jour des plugins est très simple également : c'est presque la même manipulation. La différence étant d'aller dans l'onglet "mise à jour" plutôt que dans "disponible".

Création et configuration d'un job

Jenkins vous permet de pouvoir configurer un nombre infini de Job. Chaque job est une configuration de production pour un projet : le même projet peut avoir plusieurs job.

C'est plutôt bien expliqué : juste comprendre que un "free-style" permet de TOUT faire, un maven2/3 permet de produire des projets sous maven et la copie de job existant permet que si vos projets sont identiques en terme d'exécution alors vous pouvez ne pas vouloir tout refaire (surtout si c'est long), Jenkins le fait pour vous.

L'écran ci-dessus montre les propriétés qu'il est possible de mettre sur chaque job. Ces paramètres sont les premières choses consultés par Jenkins lorsqu'il doit construire le projet. Ces paramètres ne corresponde pas réellement à ce que Jenkins doit faire mais comment il doit se comporter.

L'écran ci-dessus montre comment Jenkins doit récupérer le code du projet. De base, il gère CVS et Subversion (SVN). Des plugins existe pour la plupart des autres grands outils du domaine : Git, Mercurial, Bazaar, ClearCase...

L'écran ci-dessus permet de spéficier quand ou pourquoi le job doit se lancer. Ainsi on retrouve des CRON, il est également possible de lancer des builds successivement. A noter que "Construire périodiquement" et "Scruter l'outil de gestion de version" sont tous deux des CRON mais l'un va forcer la construction, tandis que l'autre ne va le faire que si un changement dans le code à été fait.

Dans un job de type "maven", une autre option est disponible : "construire à la suite de dépendances SNAPSHOT". Les dépendances sont automatiquement récupérées grâce au fichier POM. On arrive alors à avoir un vrai fonctionnement d'intégration continue : si une des dépendances à changer (nouveau code, correction, nouvelle feature..) alors il est important de vérifier que ces changement non pas altéré le fonctionnement de mon code, même si mon projet n'a pas changé entre temps.

Comme nous sommes dans un job "free-style", nous pouvons choisir ce que nous souhaitons faire. De base, on peut effectuer des commandes windows (batch), *unix (shell), ant et maven. Des plugins viennent compléter ces possibilités (python..) mais avec ces 4 là, il est déjà possible de faire pas mal de choses.

J'ai donc choisi de faire une commande shell puis d'appeler des goal mavens. Il est possible de mettre autant de fenêtre de construction que l'on souhaite.

Ensuite on effectue la configuration de ce que Jenkins doit faire une fois la construction du projet terminée. On y retrouve l'analyse des résultats de tests, archiver les livrables créés, mettre à disposition la javadoc directement depuis la page du job... Toutes ces configurations permettent de mettre en place un rendu visuel sur la page du job comme présenté un peu plus bas.

Voilà la configuration possible d'un job "free-style". Comme vous pouvez le voir, il est possible d'y appeler des goals maven.

Distribution de job

Afin de faire de la distribution de Job, nous avons besoin d'au moins un slave opérationnel. Lorsque un slave est configuré sur le master, il est possible de mettre en place une règle dans la configuration du job pour que l'exécution soit déporté sur un slave particulier ou sur une famille de slave.

La valeur peut être le nom exact du slave que vous visez, une étiquette de slave (défini à la création des slaves) ou une expression régulière ou conditionnelle.

Résultats

Une fois votre job confguré comme vous le souhaitez, Jenkins vous permettra d'obtenir des courbes de tests, d'analyse statique de votre code, un historique des productions effectué. Et le tout de manière claire et simple.

Ci-dessus, nous avons la page du job. Elle permet d'avoir les informations concernant ce projet : évolution des tests, évolution des constructions, divers lien vers la documentation, rapport d'analyse...

Ci-dessus est représenté la page d'un build. Jenkins nomme un "build" une construction d'un job. Nous pouvons y voir ce qui à délenché le build, les modifications par rapport au build précédent, si il a réussi ou non...

De plus, grâce à l'historisation des builds précédent, Jenkins permet de noter tout changement de comportement du projet. Ainsi un test qui ne fonctionne pas sera noté "Failed" mais un test qui ne fonctionne plus (par rapport au build précédent) sera noté "Regression".

Une réussite est de couleur bleu car le création est Japonnais. Les feux tricolore y sont bleu-orange-rouge. D'où la couleur bleu. Toute fois, si cela vous choque, il existe un plugin pour mettre du vert à la place. Cependant, cela n'affectera pas les graphiques de tests, mais uniquement les boules de status de build.