Intégration continue Nouvelle version

site officiel : http://jenkins-ci.org/

1. Introduction

1.1. Définition

L'intégration continue est un ensemble de pratiques qui consiste à vérifier qu'à chaque changements du code source, ceux-ci n'entrainent pas de régression de l'application. Cela permet de détecter le plus tôt possible les problèmes et ensuite d'avertir les équipes de développement. L'intérêt est d'intégrer de manière régulière le travail de chaque développeur, et ainsi d'éviter de mettre en commun d'un coup les développements de plusieurs personnes, ce qui provoque souvent des problèmes.

Pour que l’intégration continue puisse se faire, il faut que les sources du projet soient hébergées sur un gestionnaire de contrôle de source (SCM) tel que SVN ou Git. Les développeurs doivent prendre l’habitude d’envoyer très régulièrement leur modifications au SCM afin que le serveur d’intégration puisse analyser le code de l’application. Mettre en place des tests unitaires complets est fortement conseillé, car ils seront lancés par le serveur d’intégration continue.

1.2. Pré-requis

Avoir les sources du projet hébergés sur un SCM, prendre le temps de coder des tests unitaires, et prendre l’habitude de poster régulièrement ses modifications.

1.3. Avantages

  • connaitre rapidement et régulièrement les problèmes de compilation, les tests unitaires qui échouent
  • connaitre la dernière version stable de l'application

2. Plugin Intégration continue SourceSup

Ce plugin permet à un projet SourceSup d'utiliser un ensemble d'outils présent sur la forge relatifs à l'intégration continue. Ces outils sont :

  • Jenkins
  • Sonar
  • Nexus

Ils permettent d'avoir un cycle d'intégration continue plus complet, d'analyser le code source des projets et de mettre à disposition des artéfacts sur des dépôts.

Le plugin se compose de 6 onglets :

  • La page d'accueil qui présente les informations générales du plugin, et indique aussi si le projet SourceSup est rattaché à des dépôts Nexus.
  • L'onglet “vue Jenkins”, permet d'afficher l'outil Jenkins dans une iframe, afin de garder l'interface de SourceSup pour garder l'accès au reste de la forge.
  • L'onglet “vue Sonar”, permet d'afficher l'outil Sonar dans une iframe, afin de garder l'interface de SourceSup pour garder l'accès au reste de la forge.
  • L'onglet “vue Nexus”, permet d'afficher l'outil Nexus dans une iframe, afin de garder l'interface de SourceSup pour garder l'accès au reste de la forge.
  • L'onglet “Administration Nexus, visible seulement par les administrateurs du projet, permet de créer des dépôts sur Nexus, attaché au projet SourceSup. Il est possible aussi de les supprimer.
  • L'onglet “Administration Jenkins”, visible seulement par les administrateurs du projet, permet de créer un job sur Jenkins, attaché au projet SourceSup. Il est possible aussi de lancer ce job ainsi que de le supprimer.

2.1. Activation

Ce plugin s'active comme tous les autres dans la partie “Administration” d'un projet, au niveau de l'onglet “outils”. Il suffit de cocher la case “plugin intégration continue” et de valider le formulaire pour que le plugin soit accessible aux membres du projet.

2.2. Création d'un job Jenkins

Le plugin SourceSup va faciliter la création d'un job sur le serveur Jenkins. En effet il suffit de donner un nom de job, valider le formulaire, et un job sera créé sur Jenkins. Il est possible que la création échoue si le nom du job indiqué est déjà pris, dans ce cas un message d'erreur est affiché précisant cette erreur.

Les membres du projet SourceSup obtiennent automatiquement les droits sur ce job, et peuvent le consulter, le lancer. Les administrateurs peuvent modifier la configuration

3. Jenkins

3.1. Authentification

L'accès à Jenkins se fera par la plateforme SourceSup, il n'y a donc pas de création de compte utilisateur propre à Jenkins. Une fois identifié sur SourceSup via la fédération d'identité, l'utilisateur sera aussi identifié sur Jenkins lorsqu'il voudra y accéder.

3.2. Projets privés

Les dernières versions des plugins Subversion et Git de Jenkins utilisent des Credentials, permettant de s'authentifier sur un serveur SVN ou Git par exemple.

3.2.1. Credentials

Afin d'utiliser les dépôts Subversion et Git privés, il faut utiliser les credentials pourvu à cet effet :

Subversion
  • utiliser le credential : “jenkins”
Git
  • utiliser le credential : “jenkins ssh”

Une vérification est effectuée pour s'assurer que le job créé par un projet SourceSup a le droit de récupérer les sources du dépôt indiqué.

3.3. Utilisation

3.3.1. Création de job

L'utilisation du serveur Jenkins, passe par la création de jobs. Le but d'un job est de builder un projet et d'effectuer un ensemble d'actions, avant ou après le build ( récupérer les sources du projet à partir du SCM, publier les résultats, analyser le code via le serveur Sonar, etc…). Le build peut être simple, ou plus complexe et exécuter des actions maven / ant ou autres.

3.3.2. Paramétrage de job

Les jobs sont paramétrés à la création avec la liste des utilisateurs du projet SourceSup. Pour rajouter à la main un autre utilisateur, indiquer le mail de celui-ci et donner lui les droits en cochant les cases correspondantes.

Pour rendre votre job public, accessible de tout le monde, vous pouvez donnez des droits à l'utilisateur Authenticated, ou bien Anonyme.

Les résultats des builds des jobs sont sauvegardés, et historisés. Il est possible et même recommandé de supprimer les builds trop vieux concernant d'anciennes versions du projet. Pour cela cocher la case “supprimer les anciens builds” et indiquer le nombre de build que vous voulez garder. Il est possible aussi d'indiquer combien de temps vous désirez garder vos anciens builds, en nombre de jours.

Le gestionnaire de source est indispensable, il faut choisir entre SVN et Git, indiquer ensuite l'URL du dépôt. En effet l'intégration continue n'a pas de sens si les sources du projet ne sont pas fournies. Exemple avec SVN :

Les builds peuvent être déclenché à la main par l'utilisateur, ou bien automatisé.

Exemple d'un build déclenché tous les jours, et qui va scruter toutes les heures le dépôt pour voir si des modifications ont eu lieu.

3.3.3. Ajout d'action Maven / Ant / appel de scripts

Pour faire appel à une action d'un gestionnaire de build, il suffit d'ajouter une étape au build et de sélectionner l'action voulue. Pour Maven, choisissez “Invoquer les cibles Maven de haut niveau”, et indiquer ensuite la commande à lancer.

3.3.3.1. Exemple d'action Maven : site-deploy

1: Ajouter le plugin dans le build du pom

  <build>
    <plugins>
     <plugin>
       <artifactId>maven-site-plugin</artifactId>
       <version>3.4</version>
       <dependencies>
         <dependency>
           <groupId>org.apache.maven.wagon</groupId>
           <artifactId>wagon-webdav-jackrabbit</artifactId>
            <version>3.1.0</version>
         </dependency>
            </dependencies>
      </plugin>
      <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-project-info-reports-plugin</artifactId>
            <version>2.8</version>
       </plugin>
     </plugins>
  </build>

2: Rajouter une description de déploiement site dans distributionManagement :

  <distributionManagement>
      <site>
          <id>sourcesup-dav</id>
          <url>davs://sourcesup.renater.fr/nom-unix-du-projet/</url>
      </site>        
  </distributionManagement>

3 : Invoquer une cible de haut niveau maven (site et deploy): mvn site-deploy

Vous pouvez aussi lancer des actions maven / ant à partir de l'étape de build “exécuter un script shell”. Pour cela, ajouter cette étape, et dans le champ texte qui apparait, écrire la commande voulue. Exemple : mvn clean install. Cette commande sera alors lancée dans le workspace du projet lors du build du job.

3.3.4. Lancement d'un job

Pour lancer l'exécution d'un job, cliquer sur le lien “lancer un build”. L'exécution se met alors dans la file d'attente des exécutions et sera lancée quand son tour viendra. Les résultats sont visibles graphiquement, un rond vert indique que le build a réussi, un rond rouge indique l'échec. Pour avoir des détails, le lien “sortie console” permet de voir les logs de l'exécution.

Un historique des builds est disponible, celui garde les logs et résultats de tous les builds précédents.

Pour Sonar, il sera important qu'un utilisateur ayant les droits sur le job lance le build une fois à la main. Cela permettra de donner les droits à cet utilisateur d'administrer les résultats de l'analyse sur le serveur Sonar. Les builds pourront ensuite être lancé automatiquement. Si une analyse a déjà été lancé automatiquement, il suffit de lancer le build du job à la main une fois pour avoir les droits au niveau du serveur sonar.

3.4. Mise à jour / Ajout de plugins

Jenkins sera régulièrement mis à jour avec les sorties officielles des nouvelles version du serveur. Un redémarrage du serveur Jenkins peut être nécessaire pour la prise en compte des plugins / mises à jour, un mail préviendra les utilisateurs dans ce cas.

Vous pouvez voir tous les plugins disponibles sur le site de Jenkins : liste officielle des plugins Jenkins

Pour ajouter un plugin qui ne serait pas installé sur notre plateforme, vous pouvez demander son installation à l'équipe de SourceSup à : support. La demande sera étudiée et le plugin sera installé si son utilité pour la plateforme est avérée.