Breadcrumbs

Gestion de l’intégration continue avec jenkins

Introduction

Jenkins est un serveur d’intégration continue très en vogue, notamment pour les projets Java développés avec maven, développé sous les licences MIT et Creative Commons CC-BY-SA. Il s’appelait originellement Hudson, mais a été renommé suite à un différent entre Oracle, société détentrice du nom, et la communauté open-source. Voir http://doc.ubuntu-fr.org/jenkins.

Article issu de : http://www.scub-foundation.org/accueil/documentation/tutorial-gestion-de-l-integration-continue-avec-jenkins/

Site Officiel

Vous trouverez le site officiel de Jenkins à l’adresse suivante : http://jenkins-ci.org/.

Autre lien interessant

http://linsolas.developpez.com/articles/hudson/

Wikipédia

Je vous invite à consulter les articles français et anglais de la célèbre encyclopédie Wikipédia à propos de Jenkins.

Tutoriel

Nous verrons ici comment installer et utiliser Jenkins. Dans ce tutoriel vous aurez besoin du serveur d’application Jetty.

Objectif

L’objectif est d’automatiser des builds périodiques sur l’ensemble des projets et de générer des données d’analyse du code. Pour effectuer une analyse du code performante, nous allons utiliser la plateforme de gestion de la qualité Sonar. Pour rendre accessible les données de reporting basique à tous, nous mettrons en place un site de rapports en utilisant Maven.

Installation avec des paquets

Ne pas faire ce type d’installation pour la suite du tutoriel.

Ajoutez la clé publique du dépot de jenkins :

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -

Ajoutez la source de mise à jour :

sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'

Rechargez la liste des paquets :

sudo apt-get update

Installez le paquet :

sudo apt-get install jenkins

Changez la variable d’environnement de jenkins (export évite d’avoir à redémarrer la machine):

export JENKINS_HOME=/opt/jenkins

Pour arrêter jenkins :

sudo /etc/init.d/jenkins stop

Pour lancer jenkins :

sudo /etc/init.d/jenkins start

Installation avec le .war

Ce type d’installation est préférable pour la suite du tutoriel.

Changez la variable d’environnement de jenkins (export évite d’avoir à redémarrer la machine):

export JENKINS_HOME=/opt/jenkins

Par défaut, Jenkins intègre des plugins qui nous seront inutile :

  • plugin CVS
  • plugin translation
  • plugin ant
    • Ouvrez jenkins.war puis WEB-INF puis plugins.
    • Supprimez ant.hpi, cvs.hpi et translation.hpi.
    • Copiez jenkins.war dans l’autoload de Jetty :
      dans mon cas /opt/jetty/webapps
    • Créer un fichier jenkinx.xml dans /opt/jetty/contexts qui contiendra les lignes suivantes :
        <Configure class="org.eclipse.jetty.webapp.WebAppContext">
        <Set name="contextPath">/jenkins</Set>
        <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/jenkins.war</Set>
       
        <Get name="securityHandler">
          <Set name="loginService">
            <New class="org.eclipse.jetty.security.HashLoginService">
                  <Set name="name">Jenkins Realm</Set>
                  <Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set>
            </New>
          </Set>
        </Get>
       
      </Configure>
    • Démarrez Jetty avec la commande
      /etc/init.d/jetty start.
    • Accédez à Jenkins avec l’adresse http://localhost:8080/jenkins.

Pour changer le répertoire principal de Jenkins :

sudo usermod -m -d /opt/jenkins jenkins

Pour l’installation sous windows faire comme indiqué ici.

Si on démarre le serveur d’application avec l’utilisateur root, la variable d’environnement est ignorée et le répertoire de travail de Jenkins sera alors /root/.jenkins.

Configurez Jenkins

Allez dans la rubrique Administrer Jenkins puis Configurer le systême.

Il est important de fixer le nombre de builds pouvant être effectués simultanément, dans notre cas, nous ne seront jamais confrontés à des exécutions parallèles de build.

Nb d’exécuteurs : 1

L’utilisation d’un délais d’attente est conseillée lorsque l’on utilise CVS pour la gestion des source ce qui n’est pas notre cas.

Période d’attente : 0

Dans Configuration des projets Maven :

Local Maven Repository : Local to the workspace

Pour éviter d’avoir à renseigner plusieurs fois les données d’authentification de subversion.
Dans subversion :

Vérifiez que l’option Update default Subversion credentials cache after successful authentication est cochée.

Dans Maven :

Configurez Maven. Si vous possédez déjà une version de Maven :

        • Cliquez sur Ajouter Maven.
        • Décochez « Install automatically« .
        • Remplissez Nom et MAVEN_HOME. Par Exemple :
          • Nom : maven
          • MAVEN_HOME : /home/tlebigre/Scub-Foundation/scub-foundation/programs/maven/

Création et configuration d’un Job

Schéma de fonctionnement d’un job standard

Configuration générale

Pour ne pas occuper un espace trop important, nous pouvons choisir de supprimer les anciens builds en définissant le nombre de build que l’on souhaite conserver ainsi qu’un nombre de jour maximal durant lequel le build sera conservé. Les résultats étant stockés dans la base de données associée à Sonar, ce n’est pas nécessaire d’avoir un archivage au niveau de jenkins.

On note également plusieurs paramètres utiles tel que :

        • Désactiver ce build : l’exécution du job sera automatisée, l’utilisation de ce paramètre. permettra de stopper les exécutions sans modifier la configuration du planning.
        • Désactivation du build si certaines de ses dépendances sont concernées par un autre build en amont ou en aval.

Configuration de la connexion à Subversion

        • Cliquez sur Nouveau Job
        • Donnez un nom au job :
          • Nom du Job : JobTest
        • Selectionnez Construire un projet maven2/3
        • Cliquez sur ok

        • Dans Gestion de code source :
          • Sélectionnez Subversion
          • Remplissez l’URL du répertoire, par exemple :
          • Il se peut que vous ayez à renseigner le login et le mot de passe de la connection au svn. Par exemple :
            • login : sfguest
            • mdp : sfguest123

Déclenchement automatique du build

Dans Ce qui déclenche le build :

On peut planifier différent builds dans une même journée, par exemple si on renseigne le paramètre planning avec la chaîne suivante : 0 10,12,14,16,18 * * * , le build sera exécuté 5 fois dans la journée à 10H,12H,14H,16H et 18H. Voir ci-dessous :

Le build

Dans Build :

Cochez les mêmes cases que sur l’impression d’écran.

Complétez :

        • POM Racine : pom d’un projet du workspace
        • Goals et options : un goal

Ici le goal a renseigné lors du build est install scub-foundation-jetty:undeploy_deploy, il permet le déploiement de l’application dans Jetty.

Construction incrémentale – ne faire la construction (build) que pour les modules changés : La construction incrémentale permet d’accélérer les builds, chaque module ne sera pas reconstruit à chaque fois.

Désactive l’archivage automatique des artefacts : La désactivation de l’archivage des artefacts permet de réduire les ressources nécessaires dans la mise en place de l’intégration continue. Sinon il y a l’archivage automatique de tous les artifacts générés par le projet.

Désactive le lancement des projets en aval : Cela désactive les actions qui pourraient être faites après le build.


Construire les modules en parallèle :
Si cette option est sélectionnée, Jenkins lancera les builds de chaque module comme des builds séparés. Sur un projet avec un grand nombre de modules ou sur un projet où les modules prennent du temps pour se construire, cette option permet d’accélérer le build dans sa globalité, puisque les sous-modules peuvent être construits en parallèle.
Si cette option n’est pas cochée, Jenkins construira le projet comme lors d’un lancement classique en ligne de commande.

Utilise un repository Maven privé, dans notre cas :

        • Strategy : Local to the workspace

Cela permet de spécifier le type de repo. Chaque job possède ainsi sont propre workspace, bien qu’en termes de ressource cela soit coûteux, c’est absolument indispensable pour assurer l’intégrité des builds.

Send e-mail for each failed module :
Envoie un e-mail lors de l’échec de build d’un module.

Effectue la résolution de dépendances pendant la lecture du POM : La résolution des dépendances se fait automatiquement grâce au POM.

Exécuter sans environnement graphique : Si le build ne nécessite pas un accès à l’environnement graphique (s’il n’utilise que des outils en ligne de commande) cette option peut être activée.

Analyse les plugins pendant la lecture du POM Jenkins analyse les plugins utilisés grâce aux dépendances spécifiées dans le POM.

Utiliser un répertoire de travail spécifique : Pour chaque job, Jenkins alloue un « répertoire de travail » unique. Il s’agit du répertoire où le code est placé en provenance de l’outil de gestion de configuration et où les builds ont lieu. En règle générale, vous devriez laisser Jenkins allouer et nettoyer les répertoires de travail, mais dans certaines circonstances, cela peut poser problème. Cette option vous permet de spécifier le répertoire de travail manuellement.

Voici le résultat après le lancement du build :

Source: http://www.scub-foundation.org/accueil/documentation/tutorial-gestion-de-l-integration-continue-avec-jenkins/

Add comment


Security code
Refresh

Go to Top
Template by JoomlaShine