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.
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 :
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 :
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. Ce 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) :
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 :
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). Il vérifie 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 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) :
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 :
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. 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 :
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. Ils permettent 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 aurons.
