A quoi ça sert ?

Intégration continue - Rappel

L'intégration, si on doit le résumé en quelques mots, c'est : "voir les problèmes le plus rapidement possible".

Ce qu'il faut comprendre, c'est que ce concept n'est en aucun cas l'arme absolue contre les défaillances du codes ou du codeurs. Ce qu'il apporte c'est la possibilité de voir les problèmes dès que le codes est écrits et non pas lorsque le code est à quelque jour d'une livraison client par exemple. L'idée étant de voir le comportement de l'ensemble des modules d'un logiciel dans l'environnement de livraison (de préférence) et ainsi voir les problèmes qui peuvent être liés soit à l'environnement soit à des dépendances du code.

Voici comment nous pouvons représenter le cheminement d'un développement :

Sans intégration continue	Avec intégration continue

Pour que le processus est un sens, les tests sont très importants. Unitaires et d'intégrations, ils vont être la clé de voûte de la détection des erreurs introduites par les dernières modifications du code.

Les objectifs d'un serveur d'intégration continue

L'intégration continue en elle-même peut très bien être réaliser par une personne, à la main. Cependant cette tâche serai longue et fastidieuse. C'est pourquoi il existe des serveurs pour remplir ce rôle. Nous pouvons voir 3 rôles importants qui sont délégués à ces serveurs :

• centralisation : permettre à un ensemble de personne de bénéficier d'informations communes.
• automatisation : permettre d'effectuer l'ensemble des phases de productions (compilation, tests, déploiement...) sans ou avec très peu d'intervention d'un humain.
• historisation : permettre de garder les productions précédentes et voir l'évolution des productions.

De nombreux produits répondent à ces critères : Hudson/Jenkins, Bamboo (Atlassian), Continuum (Apache), Cruise Control, Luntbuild, Anthill, TeamCity, BuildForge et sûrement d'autres. J'ai choisi de présenter Hudson/Jenkins car j'en ai une expérience pratique assez importante et que j'ai pu voir ces nombreux avantages ainsi que la facilité avec laquelle il est possible de l'intégrer dans un environnement pré-existant.

Comment ça fonctionne ?

Technologie

Jenkins est une application web, développé en java. De ce fait, il est installable sur un grand nombre de système d'exploitation. Avec Jenkins, il est possible d'utiliser un grand nombre d'outils qui ne sont pas intégré directement à Jenkins.

Installations

Type d'installation

Il existe plusieurs manière d'installer Jenkins :

• serveur d'application web : avec tomcat (par exemple) vous pouvez rapidement mettre en place cette application.
• standalone : sans utiliser de serveur d'application web, une ligne de commande simple pour exécuter le "war" de jenkins
• slave : utiliser pour effectuer de la distribution de job et réduire l'utilisation d'un serveur. Chaque slave est rattaché à un et un seul master, mais un master peut avoir un grand nombre de slave. Ne peut se faire qu'à partir d'un jenkins installer en master (l'une des deux méthodes précédente).

Comparatif des installations

Je vais maintenant comparer les installations en "web-app" et en standalone. Je ne peut pas mettre dans le comparatif l'installation slave car son optique est très différente de ces deux installations.

Pour toutes ces installations, il est possible de distinguer le dossier d'installation et le dossier d'utilisation de jenkins. Le dossier d'installation est composé des exécutables et des fichiers de configuration de la plateforme tandis que le dossier d'utilisation est composé des configurations du service. De base, ces deux dossiers sont les mêmes, mais en mettant en place la variables d'environnement HUDSON_HOME il est possible de les séparer. Cette manipulation peut être utile si vous souhaitez que des utiisateurs puissent accèder aux fichiers des jobs, mais pas au war ni à la configuration de jenkins.

Installation web-app

Installation standalone

Comment je l'ai dit précédemment, une simple ligne de commande permet démarrer Jenkins :

java -jar jenkins.war

Un certain nombre d'option peuvent être rajouter pour changer les paramètres de base de l'installation :

• -httpPort : permet de changer le port HTTP sur lequel le service va se mettre en écoute. De base, il est en écoute sur le port 8080
• -ajp13Port : permet de mettre le service en écoute sur un port AJP, désactivé par défaut. AJP permet par exemple de mettre en place un système de LoadBalancing entre plusieurs instance d'un même service pour assurer de la haute disponibilité.
• -daemon : pour mettre le service en tâche de fond. Avec ce paramètre, le service mettera tous ses messages de fonctionnement dans un fichier plutôt que dans la fenêtre de commande.

D'autres options existes, mais avec ces trois là vous pouvez accomplirer un grand nombre de choses.

Si vous effectuer cette installation sur un OS Windows, il vous est possible de transformer jenkins en service windows en passant par l'écran d'administration de jenkins.

Installation slave

Comme je l'ai dit précédemment, les slaves sont des instances de Jenkins qui sont rattachées à un master. Pour ce faire, c'est pas très compliqué : Administrer Hudson >> Gérer les noeuds >> Nouveau noeud.

Oui, les instances de Jenkins sont considérés comme des noeuds. D'ailleurs le master est lui aussi un noeud. Si on fait l'analogie avec les arbres informatiques, il s'agit d'un arbre à 1 niveau, le master est la racine, les slaves sont les feuilles. Les slaves ne peuvent avoir de slave

Lors de la configuration de ce nouveau noeud, vous pourrez alors spécifier sont nom, le répertoire dans lequel Jenkins s'exécutera sur l'hôte distant et la manière dont l'instance doit être démarrer. A noter qu'il vous est possible de rajouter un "étiquette" au slave. Cette étiquette permet de faire des pools de slave. Ainsi, les job demandant à s'exécuter sur un hôte windows iront s'éxécuter sur une instance du pool "windows".

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:

• matrice: vous accordez certains droits aux utilisateurs enregistré dans la base de Jenkins. L’attribution des droits se fait utilisateur par utilisateur.
• autorisez tous les utilisateurs enregistré à tout faire. Comme vous seul pouvez enregistrer de nouveau utilisateur, cela semble correcte mais vous pouvez vouloir distinguer un utilisateur d’un autre (dans ce cas, retour à la matrice).
• si vous laissez « tout le monde peut tout faire » alors vous ne gérez pas la sécurité..
• vous pouvez choisir une matrice qui dépend de chaque projet. Utile si un même utilisateur ne doit pas avoir les mêmes droits d’un projet à un autre.
• le mode legacy distingue les admins des autres. Les admins peuvent tout faire, les autres rien.

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.

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".

Un peu plus loin

Enchainement des jobs

Afin d'entrer dans un processus d'intégration continue, il est important de pouvoir construire des projets les uns après les autres. Jenkins permet de faire cette configuration.

Ainsi, dans un job de type free-style, il est possible de préciser à la main les jobs qui doivent s'effectuer avant et/ou après. Pour un job de type "maven" il est possible de spécifier déclencher un build lorsqu'une dépendances snapshot est construite.

Les plugins

Le fonctionnement de base de Jenkins permet à la plupart des projets de pouvoir l'utiliser directement. Cependant, il existe plus de 140 plugins qui permettent à Jenkins d'augmenter ces capacités. Ainsi il existe des plugins pour pouvoir utiliser des outils de gestion de version (mercurial, git..), des plugins pour améliorer la présentation de résultats...

Voici la liste complète des plugins: http://wiki.jenkins-ci.org/display/JENKINS/Plugins