Maintenant que SonarQube est capable de scanner nos différents projets pour sortir des rapports de qualité de code (voir l’article au sujet de SonarQube), il est intéressant d’automatiser le processus, et c’est là qu’un outil d’intégration continue comme Jenkins intervient.

Jenkins, intégration continue

SonarQube, comme nous l’avons vu, est très intéressant pour scanner nos projets et trouver des erreurs ou des façons de coder qui ne correspondent pas aux standards. Par contre, à moins de le planifier à intervalle régulier (via un shell par exemple en crontab), il ne se lancera pas de lui-même. C’est dommage de lancer une analyse si aucune modification de code n’a été faite, et c’est à l’inverse dommage que le code puisse avoir été modifié depuis plusieurs jours sans qu’une analyse ait tourné.
C’est là que Jenkins est intéressant. Car il est capable d’aller se connecter à un outil de gestion de sources (Git, SVN) et de voir si des modifications ont été effectuées. S’il en détecte, il peut lancer un « build » qui va pouvoir lancer un certain nombre d’actions.

Installation de Jenkins

L’installation de Jenkins est assez simple. L’installation complète est décrite sur ce blog

En résumé, Il suffit de lancer ces quatre lignes pour installer Jenkins :

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins

Une fois Jenkins installé, il est possible via la « Gestion des plugins » de l’administration de l’enrichir. Dans notre cas, nous avons ajouté les plugins suivants :

  • Git plugin
  • SonarQube plugin

Nous voici prêts à nous lancer dans la création de projets.

Création d’un projet

Options d’un projet

Pour créer un projet, il suffit de cliquer sur « Nouveau item » depuis la page d’accueil de Jenkins. Vous aurez l’écran suivant :

Nouveau projet Jenkins

Dans le cadre d’un projet PHP, il faut choisir le projet free-style qui sera entièrement configurable.

Une fois le nom et le type de projet défini, vous entrez dans la configuration fine. Le premier bloc concerne les options du projet :

options projet Jenkins

En plus de la description, vous pouvez définir un certain nombre de choses, comme par exemple le fait d’avoir une suppression automatique des anciens builds. A noter que dans l’univers Jenkins, le build est l’opération qui consiste à lancer le projet, à faire toutes les étapes que vous avez défini pour celui-ci et à rapporter l’état du build. A vous de voir en fonction du poids de des anciens build, et à l’historique que vous souhaitez conserver. En tout cas il peut être intéressant d’activer cette option pour éviter d’avoir un gonflement de l’espace de stockage avec des build datant d’une époque lointaine. Vous pouvez également définir la politique de conservation des artefacts, qui sont des fichiers et données générés par le build que Jenkins peut ou non stocker.

Gestion de code source

Nous sommes là au cœur du processus d’intégration continue, et à la raison qui nous a fait installer Jenkins en plus de SonarQube. Il est capable d’aller se connecter à un gestionnaire de code source pour aller voir si le code a changé. Si oui, il va se connecter au dépôt pour rapatrier le code source dans un répertoire de travail, et il va lancer un build. Dans notre cas, il va se connecter à un dépôt Git (avec le plugin installé donc) :

Jenkis et git

Il va falloir entre l’url du dépôt Git, choisir les crédentials qui vont permettre de s’y connecter (elles auront été préalablement renseignées dans la section dédiée de l’administration, pour Git il est possible de renseigner la clé ssh) et la branche à scruter. Dans un processus d’intégration continue en mode GitFlow (voir l’article sur Git et SourceTree sur ce blog), l’idéal est de se connecter à la branche develop pour avoir un retour d’analyse avant le marge avec la branche master. Il est également possible de le brancher sur une feature spécifique.

Une fois les paramètres de connexion au dépôt établies, il faut préciser ce qui déclenche le build, et la fréquence de recherche :

Jenkins scrutation git

Dans cet exemple, le build est déclenché par une scrutation de l’outil de gestion de code (si une modification est détectée, le build se lance) avec une vérification toutes les demi heure. La syntaxe H/30 permet de donner à Jenkins une souplesse pour qu’il puisse gérer au mieux la charge s’il faut lancer plusieurs builds.

Lancer une analyse SonarQube

Maintenant que nous avons défini notre projet, et ce qui déclenche le build, il faut dire à Jenkins ce qu’il doit faire à l’occasion de ce build. Dans notre cas, nous voulons qu’il lance une analyse avec SonarQube. Comme notre plugin est installé, nous allons pouvoir lui demander de le faire via le bouton « Ajouter une étape au build ». Dans les options, nous allons trouver « Lancer une analyse SonarQube autonome ». Il suffit de renseigner le « chemin vers les propriétés du projet » (le fichier sonar-project.properties décrit plus amplement dans l’article sur SonarQube) :

Jenkins et SonarQube

 

Résultat d’un build

Sur l’accueil de Jenkins, vous aurez un récapitulatif de tous vos projets, avec pour chacun une ligne ressemblant à cela :

recap Jenkins

 

Vous avez une bille de couleur indiquant l’état du build, un symbôle météo pour donner un parcçu des derniers build, le nom du projet, la date de lancement du dernier build, la date du dernier échec, la durée du dernier build et la possibilité de lancer un build manuellement.

En rentrant dans un projet, vous pourrez avoir l’historique des build, et en rentrant dans un build vous pourrez avoir un détail complet, notamment une sortie console détaillant tout ce qui s’est produit durant le build :

build jenkins

Projets PHP

Pour l’instant, nous utilisons surtout Jenkins pour lancer une analyse SonarQube, je suis également en train de mettre en place un lancement d’une analyse autonome de code mort avec PHPDCD, ainsi qu’une génération de documentation avec PHPDocumentor car cela suffit pour l’instant à nos besoins.

Sachez qu’il existe des « templates » PHP pour Jenkins qui utilisent Ant ou Phing permettant de prévoir un script de lancement de différents outils (PHPUnit, PHPDox, PHPMD, PHP_CodeSniffer). Vous pourrez trouver plus de détails à ce sujet en suivant ce lien ou ce lien.

J’aurai sans doute l’occasion de reparler de Jenkins et d’intégration continue au fur et à mesure de l’utilisation que nous en avons.