Voici quelques infos sur SourceSup et le projet WA11Y - Accessibilité numérique du Web

Le projet vise à développer des composants permettant d'aider à la recette d'accessibilité numérique du web, selon le référentiel RGAA v2.2 voire 3.0 qui doit sortir bientôt.

Ce référentiel (cf http://www.references.modernisation.gouv.fr/rgaa-accessibilite) est dérivé du référentiel WCAG 2.0 du W3C (http://www.w3.org/TR/WCAG20/). Le RGAA présente 61 critères regroupés en 4 "principes", avec 3 niveaux d'exigence : A, AA et AAA. Chaque critère donne lieu à un certain nombre de tests proposés par le référentiel. Ces tests sont regroupés par thèmes (images, formulaires, tableaux, liens, multimédia, etc).

Pour le niveau A, nous avons 129 tests (mais certains thèmes, comme le multimedia, ne sont pas prioritaires). Les composants doivent mettre en œuvre certains de ces tests (prioritairement images, liens, tableaux, titres, formulaires).

Les promotions des années 2010-2011, 2011-2012, 2012-2013 et 2013-2014 se sont focalisées sur la production d'un logiciel de recette en accessibilité web qui effectue une série de tests propre à un référentiel.

La promotion 2014-2015 se focalise dans un logiciel de génération d'un site statique web, base de connaissance pour le programmeur afin de comprendre comment les tests se font et donc savoir comment corriger son application web pour qu'elle passe un test particulier d'un certain référentiel. L'objectif prioritaire était la génération automatique des pages d'accueil, référentiel et critères. Les objectifs secondaires sont :

• Les éléments sont modifiables depuis un fichier XML.
• Les éléments hors critères sont aussi modifiables depuis le programme. Les critères et tests sont modifiables depuis le programme.
• Le site généré possède un nombre d'élément minimal, et est conforme aux bonnes pratiques d'accessibilité (html, css, javascript). Par minimal, on entend pas d'élément non utilisé dans ces fichiers.

Projet Wa11y sur SourceSup, utilisation de Subversion, Maven, Jenkins et SonarQube

Rappels SVN

SVN (Pour Subversion) est un logiciel de gestion de sources et de contrôle de versions. Il peut être assimilé en anglais à SCM pour Source Control Management system. Ce type de programmes a plusieurs fonctions, notamment :

• Garder un historique des différentes versions des fichiers d’un projet
• Permettre le retour à une version antérieure quelconque
• Garder un historique des modifications avec leur nature, leur date, leur auteur, …
• Permettre un accès souple à ces fichiers, en local ou via un réseau
• Permettre à des utilisateurs distincts et souvent distants de travailler ensemble sur les mêmes fichiers.

Un livre en français est consultable.

Notions

Dépôt (repository)

Un dépôt SVN est l’emplacement central où sont stockées toutes les données relatives aux projets gérés.

On accède au dépôt via une une URL locale ou distante (dans notre cas : https://subversion.cru.fr/wa11y ou cette adresse qui semble être communiquée en priorité https://subversion.renater.fr/wa11y maintenant). Le dépôt contient l'historique des versions des fichiers stockés, les logs enregistrés lors des modifications, les dates et auteurs de ces modifications, etc.

Un dépôt apparaît de l'extérieur comme un système de fichiers composé de répertoires au sein desquels on peut naviguer, lire et écrire selon les permissions accordées.

Copie de travail (working copy)

La copie de travail est un répertoire situé en local sur le poste de l'utilisateur et qui contient une copie d'une révision donnée des fichiers du dépôt.

C'est cette copie qui sert de base de travail et qui est modifiée en local avant d'être importée (sauvegardée) vers le dépôt.

Révisions

Chaque modification faite au dépôt constitue une révision. Le numéro de révision commence à 1 et augmente de 1 à chaque opération.

Sa valeur n'a aucune importance, mais c'est un indicateur qui permet de revenir à une version donnée d'un ou plusieurs fichiers.

Checkout (co)

Le checkout est l'opération qui consiste à récupérer pour la première fois les fichiers déjà existant au sein d'un projet du dépôt vers un répertoire de travail local.

Cette opération ne se fait en général qu'une fois par projet. Le résultat est une copie de travail.

Import

L'import consiste à placer dans le dépôt des fichiers locaux déjà existants pour y créer un nouveau projet.

Cette opération ne se fait en général qu'une fois par projet.

Update

L'update consiste à synchroniser la copie de travail locale avec le dépôt en récupérant la dernière version des fichiers du dépôt.

C'est à cette occasion que des conflits de version peuvent apparaître.

Commit (ci)

Un commit consiste à mettre à jour le dépôt à partir de la copie de travail locale. Une nouvelle révision est alors créée.

Un log ou commentaires (simple message texte contenant une description des modifications effectuées) doit être saisi à cette occasion. Les commentaires pourront ensuite être lus par les autres membres du groupe de travail lorsqu'ils récupèreront les fichiers du serveur.

À noter que pour qu'un commit soit possible, il faut que la copie de travail corresponde à la dernière version du dépôt (modifications locales exceptées).

Si ce n'est pas le cas, il est nécessaire d'effectuer d'abord un update et de résoudre les conflits éventuels avant de réessayer le commit.

Export

La fonction d'export, contrairement au checkout, ne va faire que récupérer les données sans appliquer le contrôle de version.

Commentaires lors du commit

Ces commentaires sont très utiles pour que le programmeur suivant qui récupère les données, d'un simple coup d’œil sur les commentaires laissés, puisse savoir ce qui a été fait sur les fichiers.

Exemple de commentaire utile : Correction orthographique du compte rendu final.

Il n'est pas utile de spécifier certains renseignements dans les commentaires notamment quels fichiers ont été modifiés. Lors du téléchargement des fichiers sur le serveur, on sait quels fichiers ont été modifiés / créés / supprimés. Lorsque l'on va sur la fenêtre des logs, le nom de la personne, le numéro de version lors de son commit ainsi que les fichiers qu'il a créés / modifiés / supprimés sont affichés automatiquement, le commentaire est là pour ajouter une information en plus sur ce que l'on a fait à ces fichiers. Il est donc complètement inutile d'ajouter dans son commentaire ce que la personne peut lire plus clairement et plus rapidement sur la fenêtre.

Merge

C’est l’opération qui permet de mettre à jour un fichier local qui a été modifié avec les mises à jour du repository. Cette opération est déclenchée quand le fichier a été modifié en local et qu’il y a également des modifications sur la version du dépôt.

Branche

C’est en fait une sous-version (dérivation) de la version principale. Si on a une seule version tout au long du développement, on n’aura pas de branches, mais si on doit faire une sous-version d’une version spécifique, on devra alors créer une nouvelle branche qui évoluera alors indépendamment de la branche principale

Tag

C’est une capture du repository à un moment précis. Par exemple, pour la beta2 de notre projet, on va faire un tag « beta2″ et y copier le contenu de la branche sur laquelle on travaille. Un tag n’est pas destiné à évoluer, c’est une version figée.

Utilisation de base

L'interfaçage entre Eclipse et SVN et CVS a déjà été traité dans ce lien.

Généralement un serveur SVN contient un ensemble de dépôts ou repository. Un repository peut contenir plusieurs projets même si c'est plus simple de n'en mettre qu'un. Dans ce cas, à la racine d'un dépôt svn à unique projet, on retrouve trois répertoires : trunk, tags, branches. Si le dépôt contient plusieurs projets, ces derniers sont des répertoires à la racine qui vont eux contenir les sous-répertoires trunk, tags, branches chacun.

Répertoire TRUNK

C'est le répertoire principal, celui dans lequel on va travailler pour faire évoluer le projet.

Répertoire TAGS

La notion de tags correspond en partie à celle de release, c'est à dire de marquage d'une certaine révision du projet comme composant une version du projet. Une fois que le développement a atteint une certaine stabilité, on pourra par exemple créer un tag pour marquer la sortie de la version 1.0. Ceci permettra de revenir facilement à cette version, indépendamment du numéro de révision sous-jacent correspondant.

Dans ce répertoire on va placer les versions figer du projet, des snapshots de version stable. Par exemple la version 1.0, puis 1.1,… Il faut considérer ce répertoire comme étant en lecture seule comme une sorte d'historique des différents versions.

Répertoire BRANCHES

Une « branche » est en général créée lorsqu'un développement « secondaire » est mis en route, que ce soit pour ajouter une nouvelle fonctionnalité ou parce que certains développeurs souhaitent essayer de prendre une autre direction pour certains aspects du développement. Une branche peut, au bout d'un certain temps, soit être à nouveau fusionnée dans le « tronc », soit disparaître, soit donner lieu à un nouveau programme.

On va retrouver ici, une zone de travail différentes du TRUNK, qui permettra de faire évoluer des versions en parallèle du TRUNK. Par exemple lorsque l'on doit effectuer une correction sur la version 0.6, alors que l'on travail déjà sur la version 0.7, on pourra placer une copie de TAGS/0.6 dans BRANCHES/0.6.x; une fois le travail terminé on pourra créer un TAGS/0.6.1 basé sur BRANCHES/0.6.x.

Procédure Subversion SourceSup avec Eclipse et avec Jenkins

Retrouver/réinitaliser son mot de passe SVN de SourceSup

La connexion CAS au projet sourcesup WA11Y - Accessibilité numérique du Web nécessite de choisir Université de Bretagne-Sud.

Pour connaître son login SVN sur sourcesup, aller dans l'onglet SVN/Git du projet Wa11y. Il correspond à l'information cloner. De plus, on prend note de l'URL du dépot SVN du projet wa11y : https://subversion.renater.fr/wa11y.

Pour recréer le mot de passe SVN, il faut cliquer le lien Mon compte en haut à droite.

Le bouton Donnez-moi un nouveau mot de passe permet de régénérer un mot de passe aléatoire qui sera affiché à l'écran. Il faut le copier.

Ce mot de passe copié sera utilisé en tant que ancien mot de passe dans la procédure de changement de mot de passe accessible depuis le bouton Modifiez mon mot de passe.

UTF-8 et Eclipse

Malheureusement, le réglage par défaut dans Eclipse est spécifique pour une plate-forme. Il y a eu de grands débats à ce sujet sur le tracker de bug, mais certaines des personnes clés semblent penser que la mise par défaut aux encodages spécifiques à Windows / Unix / Mac est plus sage que de la mise en UTF-8 pour le monde entier. Bien sûr, tout le monde peut changer, mais la plupart des gens ne sont pas conscients de ce paramètre, dans la pratique la plupart des projets ont leur encodage par défaut défini sur spécifique Windows CP1252 ... (ou paramètres spécifiques linux / mac ).

La forge SourceSup est sous linux. Pour rendre indépendant de la plateforme le build depuis Eclipse sur Windows 7 par le maven embarqué dans l'environnement Eclipse local et le build depuis SourceSup, il vaut mieux forcer l'encodage UTF-8 dans Eclipse.

Le menu Windows / Preferences et l'entrée General > Workspace permet de forcer l'encodage par défaut à Other / UTF-8. Lors de la création d'un nouvel espace de travail (workspace), c'est la première chose à changer. Vous devriez en prendre l'habitude car il est préférable d'opter pour Unicode / UTF-8 dès le début afin de pouvoir oublier ce sujet plutôt que d'être bloqué par la suite.

Le menu Windows / Preferences et l'entrée General > Text Editors > Spelling permet de forcer l'encodage par défaut pour les corrections à UTF-8.

Lorsque l'on édite les propriété du projet courant, Resource > Text file encoding / Other / UTF-8.

Si vous souhaitez partager votre projet avec d'autres, vous courez le risque de les voir oublier de mettre correctement leurs paramètres d'espace de travail et qu'ils introduisent des fichiers codés à tort dans votre projet quand ils créent de nouveaux fichiers. Donc, pour être sûr, il pourrait être intelligent pour définir vos paramètres du projet à "Other: UTF-8" au lieu de "Inherited from container", parce que ces paramètres du projet seront partagés avec le projet alors les paramètres de l'espace de travail ne le sont pas.

Les nouveaux fichiers seront encodés en UTF-8. S'il y a des caractères interdits dans les fichiers existants, il faut les corriger.

Maven et SourceSup

Le fichier racine pom.xml nécessaire à maven doit conprendre le plugin maven-compiler-plugin car contrairement à Eclipse qui, par défaut, à l'option Build automatiquely, sourcesup doit compiler le projet "à la main". Sous SourceSup, les plugins maven-compiler-plugin et javadoc sont sensibles à UTF-8 d'où la présence de encoding au niveau du plugin et la présence de project.build.sourceEncoding et de project.reporting.outputEncoding dans les properties.

Voici un exemple de fichier pom.xml :

<project>
  <modelVersion>4.0.0</modelVersion>
  <name>Contact</name>
  <artifactId>fr.lps2im.contact</artifactId>
  <groupId>fr.lps2im</groupId>
  <version>1.0.0-SNAPSHOT</version>

  <properties>
    <junit.version>4.11</junit.version>
    <easymock.version>3.3.1</easymock.version> 
    <apache.commons.version>3.2.1</apache.commons.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
        <artifactId>junit</artifactId>
	<version>${junit.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.easymock</groupId>
      <artifactId>easymock</artifactId>
      <exclusions>
        <exclusion>
	  <artifactId>cglib</artifactId>
	  <groupId>cglib</groupId>
        </exclusion>
      </exclusions>
      <version>${easymock.version}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>${apache.commons.version}</version>
    </dependency>
    <dependency>
      <groupId>commons-collections</groupId>
      <artifactId>commons-collections</artifactId>
      <version>${apache.commons.version}</version>
    </dependency>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>18.0</version>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.2</version>
        <configuration>
           <source>1.6</source>
           <target>1.6</target>
           <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
      <plugin>
	<inherited>true</inherited>
	<artifactId>maven-source-plugin</artifactId>
	<version>2.4</version>
	<executions>
	  <execution>
	    <id>attach-sources</id>
	    <goals>
	      <goal>jar</goal>
	    </goals>
	  </execution>
	</executions>
      </plugin>
      <plugin>
        <inherited>true</inherited>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>2.10.1</version>
        <executions>
          <execution>
            <id>attach-javadocs</id>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

SVN et Eclipse

Connecter son projet au dépôt SVN

Pour connecter son projet Java qui se construit sans erreur à un répertoire distant d'un référentiel subversion :

• On sélectionne le projet dans l'explorateur de projet.

• On fait un clic droit de la souris et dans le menu contextuel, on utilise la commande Team / Share project....

• On choisi l'option SVN, disponible si on a installé le plugin SubEclipse.

• Le workspace ne connaissant pas encore le dépôt SVN de Wa11y, on ne peut que choisir create a new repository location

• Dans l'url, il faut entrer https://subversion.renater.fr/wa11y.

• Pour le Folder Name, il faut utiliser le bouton Select....

Pour parcourir l'arborescence du dépôt, il faut se connecter grâce au login (information cloner et le mot de passe déterminés plus haut.

On peut alors parcourir l'arborescence et choisir le bon répertoire du dépot.

Une fois le bouton OK utilisé, le chemin est renseigné. Ici il s'agit du répertoire distant ic-2014/mdu/contact-service.

Une importation initiale se lance afin de récupérer en local d'éventuels fichiers se trouvant déjà dans le répertoire distant.

La commande Team / Commit permet de valider ses changement (régulièrement en XP avec l'intégration continue).

On peut choisir ce que l'on veut valider.

L'opération SVN Check In se fait en tâche de fond.

Déconnecter son projet du dépôt SVN

Pour déconnecter le projet java du référentiel (en vue de le connecter à un autre répertoire distant du référentiel) :

• On sélectionne le projet à déconnecter du dépôt :

• On utilise dans le menu contextuel la commande Team / Desconnect....

• On confirme la destruction des informations spécifiques SVN qui étaient dans le projet du workspace courant afin de le nettoyer.

On est alors libre de lier à nouveau le projet à un autre dépôt SVN et/ou à un autre répertoire distant.

Le Commit (marche à suivre et précautions)

Une fois qu'on a modifié des fichiers, il faut basculer ces modifications au sein du dépôt pour qu'elles soient accessibles aux autres utilisateurs. Dans la fenêtre Synchronize, faites un clic droit sur les fichiers à envoyer sur le dépôt SVN et cliquez sur Commit.

Toute opération de commit s'effectue en indiquant un message décrivant les modifications effectuées (ici directement dans la ligne de commande). Il est possible d'effectuer cette opération sur un répertoire entier, ou sur seulement un ou plusieurs fichiers.

Vous devrez impérativement faire un update AVANT votre commit (sinon vous aurez une ou plusieurs révisions de décalage et vos modifications auront de fortes chances de provoquer des conflits en permanence!!)

Pour éviter d'avoir une version inutilisable du code sur le dépôt, vous êtes priés de ne faire un commit que si votre code est compilable !!! Sinon, mettez les lignes inachevées en commentaire avant le commit ou ne faites pas de commit tant que le code n'est pas "stable" !

Si des modifications ont eu lieu par un autre utilisateur du dépôt depuis le dernier update, un message d'erreur le signale.

Il faut alors effectuer un nouvel update et résoudre d'éventuels conflits avant de relancer le commit.

Dernière remarque : en intégration continue, les opérations de commit sont régulières (plusieurs fois par jour) pour éviter de nombreux conflits.

Comparer les versions d'un fichier

Une fonction intéressante est de pouvoir comparer notre version avec une autre. Nous allons encore modifier notre classe. Ensuite, utiliser le menu contextuel Compare With du projet et choisissez Base Revision, c’est-à-dire la dernière révision actuelle de ce fichier. Vous pouvez aussi choisir une autre révision voire un fichier d’une autre branche. Vous avez donc une interface qui vous compare tout d’abord, la structure des deux fichiers si elle a changé et ensuite le fichier en entier et vous verrez très clairement les différences entre les deux versions.

Admettons maintenant que vous n’êtes pas content des changements apportés à votre fichier et que vous aimeriez revenir à la version précédente. Vous avez deux manières de faire. Soit tout simplement Team > Revert qui vous fait revenir à la dernière version, mais vous pouvez aussi spécifier à quelle version vous voulez revenir en faisant dans le menu contextuel Replace With et en choisissant précisément le moment auquel vous voulez revenir.

Résolution des conflits

Il faut maintenant penser que vous n’êtes pas seul sur ce projet, il faut donc récupérer aussi les modifications de vos collègues. Pour cela, rien de plus simple, il vous suffit de faire un update d’un fichier. S’il y a eu des modifications, le programme va directement les intégrer dans votre fichier. N’ayez pas peur de perdre vos propres modifications non encore sur le repository, s’il y a des modifications des deux côtés, le programme va automatiquement faire un merge des deux fichiers pour en faire une nouvelle version qui contient les modifications des 2 personnes.

Les conflits peuvent intervenir au moment d'un update, lorsque des modifications ont été faites à la fois dans la copie de travail et dans le dépôt.

S’il y a conflit, c’est-à-dire que le programme n’arrive pas à merger correctement les 2 révisions, le fichier va être marqué comme étant en conflit.

Dans ce cas, deux nouveaux fichiers font leur apparition dans votre copie de travail dans le dossier parent avec des noms basés sur le fichier ayant un conflit par exemple MyFile.

Si vous ne voyez pas ces derniers dans votre vue Explorer, cliquez-droit sur le dossier parent et choisissez Actualiser.

Dans l'exemple précédent, on se retrouve avec :

• MyFile.mine : Une copie du fichier tel qu'il se trouvait dans votre copie de travail, en local, avant de faire l'update. C'est la version que vous souhaitiez commiter avant de détecter un conflit ;
• MyFile.rVERSION_NUMBER : Une version du fichier pour la révision 42 par exemple, c'est à dire lors de votre dernier update. C'est la version qui a servi de base pour les deux utilisateurs du dépôt qui ont travaillé en parallèle ;
• MyFile.rVERSION_NUMBER+ : Une version du fichier pour la révision 43 par exemple, c'est à dire la version actuellement dans le dépôt. Il s'agit de la version modifiée par un autre utilisateur, commitée avant votre update, et dont le contenu est à l'origine du conflit.
• MyFile : Il s'agit d'une version qui, en quelque sorte « résume » les trois autres en faisant apparaître en commentaires les différences entre versions au sein d'un seul fichier.

Dès lors, le travail consiste à éditer le fichier MyFile jusqu'à ce que le conflit soit résolut. Une fois ce travail terminé, on peut alors effectuer le commit final.

Vous avez dans le menu contextuel Team et choisissez la fonction Edit conflicts... qui va vous aider à résoudre les conflits, une fois le conflit résolu, il vous suffit d’utiliser la fonction Mark Resolved... sur le fichier pour que le conflit soit marqué comme résolu.

La copie de travail locale doit apparaître dans le volet de gauche avec la version le plus récent du dépôt SVN sur la droite. Le but ici est d'obtenir la une copie de travail locale contenant le code "correct". Fusionner tout qui est dans la version SVN sur la droite qui doit être présent dans la nouvelle version. Eclipse ne vous permettra pas de faire des modifications dans la version SVN. Lorsque vous avez terminé, Enregistrez. Fermez l'onglet Edit conflicts. Vos modifications devraient migrer vers le fichier de travail local. Remarque: si vous modifiez conflits nouveau (avant de commiter), vous risquez de perdre les fusions que vous avez faites la première fois.

Mais rassurez vous les conflits n’arrive pas très souvent, c’est surtout dans les gros projets avec un grand nombre de personnes travaillant dessus et faisant beaucoup de modifications que le risque augmente. Pour le diminuer, faire des commits régulièrement.

Visualiser l'historique des révisions d'un fichier

Vous pouvez aussi visualiser l’historique des révisions d’un fichier. Pour cela, dans le menu contextuel Team, choisissez show history. Vous verrez ainsi apparaître une vue contenant la liste des révisions avec à chaque fois l’auteur de la révision, la date et le commentaire. Il vous suffit de cliquer sur une des révisions pour avoir le commentaire en entier et le path du fichier dans l’affichage du bas. Si vous cliquez droit sur une révision, vous aurez accès à d’autres actions directement en rapport avec la révision, vous pouvez revenir depuis ici à une ancienne version ou voir le fichier tel qu’il était lors de la révision. Vous pouvez aussi rafraîchir pour vérifier si d’autres changements ont eu lieu.

Explorer le repository

Une autre possibilité très intéressante est de pouvoir explorer le repository SVN. Pour cela, rien de bien compliqué, il vous suffit d’aller dans le menu « Window » et d’ouvrir la perspective « SVN Repository Exploring ».

Dans le panneau de gauche, choisissez le repository que vous voulez explorer. Depuis là, vous verrez l’arborescence de tous vos fichiers et packages. Vous pouvez bien sûr ouvrir des fichiers et cela va vous ouvrir le fichier qui se trouve actuellement sur le repository en lecture seule. En cliquant droit sur le fichier de votre choix et en choisissant « show in ressource history », vous avez accès à l’historique du fichier dans la vue du bas. C’est aussi depuis cette perspective que vous pourrez supprimer des fichiers et des dossiers que vous auriez ajouté par erreur sur votre repository. Vous pouvez aussi renommer et déplacer les fichiers.

C’est également depuis là que vous pouvez copier vos sources vers une nouvelle branche ou un tag. Il vous suffit pour cela d’utiliser la fonction « Branch/Tag ».

Enfin, vous avez la possibilité de faire un checkout d’un dossier précis depuis cette vue. Le checkout est le fait de récupérer tous les fichiers du repository ou d’un dossier de celui-ci. Vous pouvez donc faire un checkout d’une branche en particulier ou alors d’un dossier spécifique au lieu de faire un checkout complet. Pour ce faire, il vous suffit de choisir le dossier source de votre choix et d’y cliquer droit puis d’utiliser la fonction « checkout ». Vous pouvez ensuite choisir entre effectuer le checkout dans un nouveau projet ou alors dans un projet existant.

Merge entre une branche et le trunk sur SVN

Dans un monde idéal, nous n’aurions jamais à faire ce travail fastidieux et usant pour nos nerfs. Malheureusement, les projets informatiques étant ce qu’ils sont, il est fréquent de travailler sur 2 branches différentes et la nécessité des merges arrive donc toujours sur la table.

Prenons le cas d’un projet avec 2 versions : - Trunk : C’est la version qui est actuellement en production et n’a pas évolué depuis. - version_2 : C’est la branche qui contient les évolutions correspondant à la version 2 de l’application.

Imaginons maintenant que notre branche « version_2″ a été validé et doit être mise en production. Dans ce cas, nous souhaitons rapatrier (« merger ») toutes les modifications qui ont été faite dans cette branche directement dans le trunk.

Pour cela, il faut :

1. Sélectionner le projet cible (ici le trunk) dans votre « project explorer » d’Eclipse.
2. Faire « clic droit > Team > Merge »
3. Remplir les informations de merge

Les informations importantes de cette page sont :

• La destination (ou cible) qui se situe en bas de la page et est un rappel du projet précédemment sélectionné (ici, le trunk).
• Tout le reste de l’écran correspond à la source et à la définition de ce qu’on souhaite récupérer.

Pour cela, il faut :

a. Commencer par chercher la branche source (ici version_2) grâce au bouton « select » tout en haut à droite.

b. Choisir le numéro de révision à partir duquel on veut récupérer les modifications en utilisant le bouton « select » à côté. Généralement ce numéro de version correspond au dernier merge ou à la création de la branche et dans ce cas, seul les commentaires lors des commit SVN peuvent vous aider. (Attention, toutes les révisions ne sont pas chargés par défauts mais seulement les 25 premières, il faut cliquer sur « charger tout » ou « charger les 25 suivantes » pour accéder aux anciennes révisions).

c. Indiquer la révision jusqu’à laquelle on souhaite récupérer les modifications (dans notre cas, nous avons coché l’option « Merge to head revision » qui signifie qu’il va jusqu’à la révision courante et donc inclus les dernières modifications).

1. Simulation du merge

Une fois la configuration de l’écran précédent finie, il est possible de simuler un merge en cliquant sur « Dry run ». Si le merge renvoie des réusltats, ils apparaitront directement dans la console derrière la popup. Cela permet de vérifier les fichiers impactés et si le merge semble correct.

1. Lancer le merge

Si la simulation renvoie des résultats satisfaisant, il suffit alors de lancer le merge directement grâce au bouton du même nom.

1. Comiter le merge

Une fois le merge finalisé. le projet en local doit contenir toutes les modifications récupéré de la branche. Ensuite, nous sommes dans une configuration de comit classique sur SVN.

Remarque importante : Lorsque vous comitez un merge, essayer autant que possible de comiter l’ensemble en une fois en précisant bien dans les commentaires qu’il s’agit d’un merge de version m à n. Ce commentaire sera le seul moyen lors du prochain merge de déterminer la révision à partir de laquelle il faut merger.

Autres scénarios d'utilisation de SVN via Subclipse

Vous avez modifié un fichier et voulez enregistrer vos modifications sur le serveur?

Faites un Commit du fichier concerné (si votre code compile, faites un Update puis un Commit du projet entier seuls les modifications seront synchronisées) puis un Update

Vous voulez obtenir les dernière modifications apportées par les autres membres de l'équipe

Faites un Update du projet (dans la perspective Team Synchronizing ou directement clic-droit sur le projet Team > Update)

Vous voulez comparer votre version locale avec une des versions disponibles sur le SVN

Par exemple pour revoir les modifications que vous avez apportées successivement au fichier (pour retrouver l'origine d'un bug ou revoir les changements apportés par une autre personne dans le fichier sur lequel vous travaillez actuellement).

Faites un clic-droit sur le fichier puis Compare With | Latest from Repository ou Compare With | Revision...

Vous voulez remplacer votre version locale par une des versions disponibles sur le SVN

Par exemple si vous avez fait plein de "mauvaises" modifications consécutives et que vous voulez revenir à une version plus ancienne...

Faites un clic-droit sur le fichier puis Replace With | Revision... vous pourrez ensuite choisir la révision adéquate du fichier.

Vous voulez déplacer un fichier / paquetage / dossier...

Faites un clic-droit sur le fichier/paquet puis Team | Copy choisissez le nouvel emplacement, puis supprimez le fichier/paquetage.

ATTENTION! Ceci est le seul moyen de conserver l'historique des révisions du fichier une fois que vous aurez déplacé ce dernier ! Si vous déplacer le fichier par drag&drop ... il sera considéré comme une suppression de l'ancien fichier suivie de la création d'un nouveau fichier dans le nouvel emplacement et les modifications antérieures seront perdues (comme sur un dépot CVS... BREF, NE FAITES PAS DE DEPLACEMENTS PAR DRAG&DROP!!!)

SVN et Jenkins

Création de Credentials

Par rapport à la formation TDD du début janvier, Jenkins peut à nouveau utiliser Subversion comme gestionnaire de source mais il faut au préalable définir un credential non dépendant d'un domaine qui représente vos informations de connexion au référentiel Subversion de SourceSup.

Je choisis Global credentials :

A gauche, je choisis le bouton Add Credentials.

L’affichage est buggé :

Mais en appuyant sur le bouton ? de la description, il redevient convenable, ce qui me permet de rentrer mon login et mon mot de passe pour le référentiel subversion de sourcesup.

J’appuie sur le bouton OK. On remarque que l’affichage étrangement signale que c’est vide Mais si j'utilise le bouton Configurer, j'obtiens la confirmation que le credential non restreint que je viens de créer existe bien.

Création d'un build

Ce préalable étant fait, je vais configurer un build sous jenkins. Pour cela, dans le menu Jenkins à gauche, j'appuie sur le lien Nouveau Item.

Je renseigne le nom du build et son type (le plus simple est de choisir un projet maven).

Une fois renseigné ces informations basique, la configuration du build apparaît. Elle peut sembler complexe. Le nom du build est à nouveau éditable ainsi que sa Description.

Configuration des droits :

Il est judicieux d'accorder des droits à anonymous si je veux avoir des notifications des builds dans Eclipse (qui semble mal gérer les credentials de Jenkins) ?

De plus, il faut ajouter tous les membres de l'équipe qui ont un compte sous sourcesup. A noter que pour que chaque membre accède au tableau de bord de Sonar, il faut au préalable qu'il lance un build manuellement.

Configuration de Subversion :

Puisque un credentials a été créé au préalable, il est disponible dans la liste de choix.

Pour l'URL, il faut renseigner l'URL du dépôt (https://subversion.renater.fr/wa11y) concaténée avec le répertoire distant (ici /ic-2014/mdu/contact-service).

On peut garder Utiliser "svn:update" autant que possible.

Environnements de Build : configuration du module xvfb

Si on fait des test avec awt / Swing / SWT, la chaîne de build étant sous linux, il faut qu'elle ait le module xvfb déjà installé.

Dans ce cas apparaît l'écran suivant de configuration :

Il faut cocher Start Xvfb before the build, and shut it down after.

Si on appuie sur le bouton Avancé... :

Il faut cocher Let Xvfb choose display name.

Ne pas oublier dans le point suivant de mettre le Goals et options à clean install ou à clean install -Dmaven.test.skip=false.

En ayant configuré ainsi xvbf, on évite le message d'erreur Xvfb jenkins No X11 DISPLAY variable was set, but this program performed an operation which requires it.

Configuration de Maven :

Puisque nous avons choisi au tout début créer un projet maven, maven pour le projet se configure directement.

Au niveau de Goals et options, la valeur clean install -Dmaven.test.skip=true permet d'éviter d'exécuter les tests lorsque ces derniers nécessitent l'installation d'un module jenkins supplémentaire Xvfb pour Linux (OS de la plateforme renater). En effet son absence, provoque l'échec des tests pour l'IHM Swing, ce qui empêche l'installation du build puis son analyse par sonar.

Si on avait choisi créer un projet free-style, l'emploi de maven pour le projet nécessite la commande Ajouter une étape au pré-build / Invoquer les cibles Maven de haut niveau

Les cibles sont dans l'ordre clean, test et install.

Dans les deux cas, parmi les options supplémentaires de maven accessibles depuis le bouton Avancé..., il faut vérifier la présence de -X dans les options de la JVM pour avoir le mode debug.

Configuration de Sonar :

Puisque nous avons choisi au tout début créer un projet maven, l'analyse sonar se configure en tant que Ajouter une action après le build / Sonar. Si on avait choisi créer un projet free-style, l'analyse Sonar aurait été configurée avec le bouton Ajouter une étape au build qui ouvre une liste de menus dans laquelle nous aurions choisi Lancer une analyse Sonar autonome comme expliqué ici.

On valide la configuration du build.

Lancement manuel d'un build depuis le portail Jenkins

Le lien Lancer le build permet de provoque manuellement la construction du build.

Le tableau de bord Sonar quand aucun build n'a été construit avec succès :

Lorsque le build est vert :

Après une première construction sans erreur lancée manuellement par le propriétaire du build, le résultat de l'analyse Sonar est disponible via le lien Sonar pour cet utilisateur. Chaque membre de l'équipe doit lancer au moins une fois un build sans erreur manuellement pour accéder au tableau de bord Sonar.

Le tableau de bord Sonar devient informatif :

SonarQube

SonarQube (précédemment Sonar) est une solution basée sur un certain nombre d’outils existants (Checkstyle, PMD, FindBugs, JaCoCo, …) qui vise à fournir une analyse complète de la qualité du code via du reporting selon les axes suivants (source : Wikipédia) :

• Identification des duplications de code
• Mesure du niveau de documentation
• Respect des règles de programmation
• Détection de bugs potentiels
• Évaluation de la couverture du code par les tests unitaires
• Analyse de la répartition de la complexité

L’ensemble de ces statistiques/métriques permet d’avoir un feedback de manière ponctuelle ou dans la durée puisqu’un historique est disponible et permet de surveiller l’évolution d’un projet. Voyons maintenant ce qu’il est possible de faire en combinant cela à Eclipse et Maven.

Installation basique d'un serveur SonarQube local

Télechargez la dernière version LTS (4.5.2) de SonarQube pour la dézipper dans C:\eclipse-jee-juno-SR2-win64\tools. Placez-vous dans votre dossier SonarQube dézippé. Si vous n’avez pas installé de JRE, il vous faut modifier une ligne du fichier conf/wrapper.conf pour lui indiquer le chemin complet de l’exécutable Java, par exemple :

wrapper.java.command=C:/eclipse-jee-juno-SR2-win64/tools/jdk/bin/java

Il faut aussi éditer conf/sonar.properties et activer/modifier les lignes :

sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
sonar.jdbc.url=jdbc:h2:tcp://localhost:9092/sonar
sonar.embeddedDatabase.port=9092
sonar.web.context=/sonar
sonar.web.port=9090

Vous pouvez ensuite aller dans le sous-dossier bin et utiliser le script de démarrage correspondant à votre environnement (bin/windows-x86-64/StartSonar.bat). Une fois le démarrage effectué vous avez accès à l’interface web à l’adresse http://localhost:9090/sonar.

Vous y trouverez via le menu Quality Profiles l’ensemble des règles qui vont être jouées sur votre code.

Vous pouvez récupérer les paramétrages du serveur pour configurer à l'identique les plugins Eclipse pour PMD, FindBugs et CheckStyle comme alternative au plugin SonarQube pour Eclipse. Pour le portail Sonar de renater : Profils qualité > Sonar way (Java) > Liens permanents.

L'accès au profil de qualité courant du projet est directement accessible depuis la page Sonar du projet en bas.

Exemple pour le serveur Sonar du serveur statdeci2 de l'Université de Bretagne-Sud :

Analyser avec le plugin Eclipse avec le serveur distant et local

Cette première méthode va vous afficher le résultat d’analyse en local dans Eclipse. Une documentation du plugin Eclipse SonarQube est disponible().

Les analyses déclenchées par le plugin SonarQube d'Eclipse sont toujours en mode de prévisualisation incrémentielle (voir http://www.sonarqube.org/analysis-vs-preview-vs-incremental-preview-in-sonarqube/). Cela signifie que les résultats ne sont pas publiés sur le serveur maître SonarQube renater dans notre cas. Pensez à plusieurs développeurs qui travaillent sur le même projet, ayant tous un code un peu différent localement et qui souhaitent vérifier la qualité avant de le pousser dans la forge jenkins-sonar renater munie d'un gestionnaire de contrôle de source (aussi improprement appelée SCM pour Software Configuration Management alors que le gestionnaire de version n'est en fait qu'un sous-ensemble de SCM).

Seul le code déjà poussé dans la SCM devrait être analysé et publié sur le serveur SonarQube renater. Cela se fait habituellement par une tâche périodique (les serveurs d'intégration continue sont bons pour ça).

La première chose à vérifier est que le plugin pointe bien vers votre serveur SonarQube pour pouvoir y récupérer les règles à jouer sur le code. Pour cela, ouvrez le menu Window > Preferences > SonarQube > Servers. Vous y retrouverez votre serveur local par défaut (mais à modifier) et disposez de l’option d’en ajouter d’autres.

Les réglages pour le serveur renater :

• L'URL à rentrer : https://sourcesup.renater.fr/sonar
• mon utilisateur renater est : michel.dubois@univ-ubs.fr avec le mot de passe que j'ai défini plus haut.

J'appuie sur le bouton Test Connection qui doit me renvoyer Successfully connected!.

Les réglages pour le serveur local :

On se connecte au serveur local SonarQube avec la commande Log in.

Autant, avant, créer un utilisateur identique avec le droit de faire des previews à l'aide l'utilisateur admin / admin qui a les droits d'administration sur le serveur local.

La commande Settings / General permet de préciser les plugins exclus lors de l'analise en mode preview. On peut ajouter au défaut le plugin mantis qui perturbe cette phase pour le serveur renater.

Prenons note du nom de la property sonar.preview.excludePlugins et de sa valeur par défaut (buildstability,devcockpit,pdfreport,report,scmactivity,views,jira,buildbreaker).

On va ajouter un utilisateur grâce à la commande Users / add new user.

On crée un utilisateur en tout point identique à notre utilisateur sur le serveur renater.

On obtient :

Dans l'écran des Global permissions, on affecte à l'utilisateur les droits previews :

On peut alors créer le serveur local dans Window > Preferences > SonarQube > Servers.

• L'URL à rentrer : https://sourcesup.renater.fr/sonar
• Mon utilisateur renater est : michel.dubois@univ-ubs.fr avec le mot de passe que j'ai défini plus haut.

J'appuie sur le bouton Test Connection qui doit me renvoyer Successfully connected!.

Vous devez ensuite activer la nature SonarQube sur votre projet Maven existant. Pour cela, utiliser sur le projet le menu Clic droit > Maven > Update Project … puis confirmez sur la fenêtre qui s’affiche.

Si vous faites un nouveau clic droit sur le projet, vous constaterez que vous disposez maintenant d’un menu SonarQube pour lancer l’analyse :

De plus de nouvelles vues sont disponibles :

Si on lance l'analyse avec le serveur renater, on a une erreur :

08:57:36.074 WARN  - sonar.binaries and sonar.libraries are deprecated since version 2.5 of sonar-java-plugin, please use sonar.java.binaries and sonar.java.libraries instead
08:57:36.092 INFO  - Base dir: C:\eclipse-jee-juno-SR2-win64\workspace.4.2-64bits\contact-service
08:57:36.092 INFO  - Working dir: C:\eclipse-jee-juno-SR2-win64\workspace.4.2-64bits\.metadata\.plugins\org.eclipse.core.resources\.projects\contact-service\org.sonar.ide.eclipse.core
08:57:36.093 INFO  - Source paths: src/main/java
08:57:36.094 INFO  - Test paths: src/test/java
08:57:36.095 INFO  - Binary dirs: target/classes
Caused by: Access to the secured property 'sonar.mantis.login.secured' is not possible in preview mode. The SonarQube plugin which requires this property must be deactivated in preview mode.

Il faut définir la propriété sonar.preview.excludePlugins enrichie de mantis dans Window > Preferences > SonarQube > Preview Analysis Properties.

• Mettre au niveau de Name : sonar.preview.excludePlugins
• Mettre au niveau de Value : buildstability,devcockpit,pdfreport,report,scmactivity,views,jira,buildbreaker,mantis

A noter que l'on fixe ici pour les properties pour le mode preview commune à tout le workspace.

Pour les properties du mode preview spécifiques à un projet, il faut les fixer grâce à la commande Clic Droit > Properties > Preview Analysis Properties.

Par défaut dans une analyse en prévisualisation, la console n'apparaît qu'en cas d'erreur. Pour changer cela, la propriété sonar.verbose est utile pour notre projet.

• Mettre au niveau de Name : sonar.verbose
• Mettre au niveau de Value : true

On lance l'analyse en mode preview avec la commande Clic Droit > SonarQube > Analyze.

Une fois l’analyse effectuée, les différents problèmes sont remontés dans un onglet contextuel dédié Sonar Issues, qui vous permet d’accéder rapidement au code correspondant pour effectuer les corrections nécessaires :

En plus d'afficher les défauts sur votre code le plugin SonarQube pour Eclipse ferme également le cercle défini dans l'ouvrage SonarQube in Action de Campbell & Papapetrou chez l'éditeur Mannings avec des fonctionnalités de gestion des défauts.

Vous pouvez afficher les défauts qui vous ont été assignés, les commenter ou les marquer comme résolus.

[INFO] [08:30:13.121] Source paths: pom.xml, src/main/java, target/generated-sources/annotations
[INFO] [08:30:13.122] Test paths: src/test/java, target/generated-test-sources/test-annotations
[INFO] [08:30:13.122] Binary dirs: target/classes

Analyser avec un goal Maven sur le serveur local

Voici le contenu du fichier C:\Users\duboism\.m2\settings.xml pour le serveur local :

<settings>
  <proxies/>
  <profiles>
    <profile>
      <id>sonar</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <sonar.jdbc.url>
           jdbc:h2:tcp://localhost:9092/sonar
        </sonar.jdbc.url>
        <sonar.jdbc.driverClassName>org.h2.Driver</sonar.jdbc.driverClassName>
        <sonar.jdbc.username>sonar</sonar.jdbc.username>
        <sonar.jdbc.password>sonar</sonar.jdbc.password>
        <sonar.host.url>http://localhost:9090/sonar</sonar.host.url>
      </properties>
    </profile>
  </profiles>
</settings>

Cette seconde méthode ne vous affichera rien en local (à part la sortie console Maven) mais va publier le résultat d’analyse directement sur le serveur SonarQube. Notez que c’est en général un serveur d’intégration continue qui s’acquitte de cette tâche, mais nous allons ici utiliser une configuration de lancement Maven intégrée à Eclipse. Ouvrir tout d’abord sur votre projet le menu Clic droit > Run As > Run Configurations … sélectionner Maven Build dans la liste puis faire Clic Droit > New et renseigner les 3 paramètres suivants :

• Name : Maven Sonar
• Base directory : ${project_loc}
• Goals : clean install sonar:sonar -Dmaven.test.failure.ignore=true

Cette tâche sera ensuite réutilisable pour vos autres projets Maven sans devoir rééditer la configuration. Vous pouvez maintenant la lancer en cliquant sur le bouton Run.

[INFO] 
[INFO] --- sonar-maven-plugin:2.5:sonar (default-cli) @ fr.lps2im.contact ---
[INFO] SonarQube version: 4.5.2
INFO: Default locale: "fr_FR", source code encoding: "UTF-8"
INFO: Work directory: C:\eclipse-jee-juno-SR2-win64\workspace.4.2-64bits\contact-service\target\sonar
INFO: SonarQube Server 4.5.2
[INFO] [08:30:00.894] Load global referentials...
[INFO] [08:30:01.344] Load global referentials done: 452 ms
[INFO] [08:30:01.361] User cache: C:\Users\duboism\.sonar\cache
[INFO] [08:30:01.372] Install plugins
[INFO] [08:30:01.544] Install JDBC driver
[INFO] [08:30:01.551] Create JDBC datasource for jdbc:h2:tcp://localhost:9092/sonar
[INFO] [08:30:04.265] Initializing Hibernate
[INFO] [08:30:06.965] Load project referentials...
[INFO] [08:30:08.912] Load project referentials done: 1947 ms
[INFO] [08:30:08.912] Load project settings
[INFO] [08:30:09.717] Loading technical debt model...
[INFO] [08:30:09.762] Loading technical debt model done: 45 ms
[INFO] [08:30:09.766] Apply project exclusions
[INFO] [08:30:10.319] -------------  Scan Contact
[INFO] [08:30:10.344] Load module settings
[INFO] [08:30:11.348] Loading rules...
[INFO] [08:30:12.498] Loading rules done: 1150 ms
[INFO] [08:30:12.550] Configure Maven plugins
[INFO] [08:30:12.729] Compare to previous analysis (2015-02-02)
[INFO] [08:30:12.756] Compare over 30 days (2015-01-03, analysis of 2015-02-02 00:01:27.87)
[INFO] [08:30:12.757] No quality gate is configured.
[INFO] [08:30:13.088] Initializer FindbugsMavenInitializer...
[INFO] [08:30:13.117] Initializer FindbugsMavenInitializer done: 29 ms
[INFO] [08:30:13.118] Base dir: C:\eclipse-jee-juno-SR2-win64\workspace.4.2-64bits\contact-service
[INFO] [08:30:13.118] Working dir: C:\eclipse-jee-juno-SR2-win64\workspace.4.2-64bits\contact-service\target\sonar
[INFO] [08:30:13.121] Source paths: pom.xml, src/main/java, target/generated-sources/annotations
[INFO] [08:30:13.122] Test paths: src/test/java, target/generated-test-sources/test-annotations
[INFO] [08:30:13.122] Binary dirs: target/classes
[INFO] [08:30:13.122] Source encoding: UTF-8, default locale: fr_FR
[INFO] [08:30:13.122] Index files
[INFO] [08:30:13.278] 7 files indexed
[INFO] [08:30:13.497] Quality profile for java: Sonar way
[INFO] [08:30:13.523] Sensor JavaSquidSensor...
[INFO] [08:30:13.631] Java Main Files AST scan...
[INFO] [08:30:13.637] 6 source files to be analyzed
[INFO] [08:30:14.128] Java Main Files AST scan done: 497 ms
[INFO] [08:30:14.132] Java bytecode scan...
[INFO] [08:30:14.134] 6/6 source files analyzed
[INFO] [08:30:14.199] Java bytecode scan done: 67 ms
[INFO] [08:30:14.200] Java Test Files AST scan...
[INFO] [08:30:14.200] 1 source files to be analyzed
[INFO] [08:30:14.273] 1/1 source files analyzed
[INFO] [08:30:14.274] Java Test Files AST scan done: 73 ms
[INFO] [08:30:14.322] Package design analysis...
[INFO] [08:30:14.343] Package design analysis done: 21 ms
[INFO] [08:30:14.453] Sensor JavaSquidSensor done: 930 ms
[INFO] [08:30:14.453] Sensor QProfileSensor...
[INFO] [08:30:14.458] Sensor QProfileSensor done: 5 ms
[INFO] [08:30:14.459] Sensor InitialOpenIssuesSensor...
[INFO] [08:30:14.476] Sensor InitialOpenIssuesSensor done: 17 ms
[INFO] [08:30:14.476] Sensor ProjectLinksSensor...
[INFO] [08:30:14.486] Sensor ProjectLinksSensor done: 10 ms
[INFO] [08:30:14.487] Sensor VersionEventsSensor...
[INFO] [08:30:14.508] Sensor VersionEventsSensor done: 21 ms
[INFO] [08:30:14.508] Sensor FileHashSensor...
[INFO] [08:30:14.511] Sensor FileHashSensor done: 3 ms
[INFO] [08:30:14.511] Sensor SurefireSensor...
[INFO] [08:30:14.512] parsing C:\eclipse-jee-juno-SR2-win64\workspace.4.2-64bits\contact-service\target\surefire-reports
[INFO] [08:30:14.743] Sensor SurefireSensor done: 232 ms
[INFO] [08:30:14.743] Sensor Maven dependencies...
[INFO] [08:30:14.823] Sensor Maven dependencies done: 80 ms
[INFO] [08:30:14.823] Sensor CPD Sensor (wrapped)...
[INFO] [08:30:14.824] JavaCpdEngine is used for java
[INFO] [08:30:14.825] Cross-project analysis disabled
[INFO] [08:30:14.948] Sensor CPD Sensor (wrapped) done: 125 ms
[INFO] [08:30:15.689] Execute decorators...
[INFO] [08:30:16.605] Store results in database
[INFO] [08:30:17.408] ANALYSIS SUCCESSFUL, you can browse http://localhost:9090/sonar/dashboard/index/fr.lps2im:fr.lps2im.contact
[INFO] [08:30:17.768] Executing post-job class org.sonar.plugins.core.issue.notification.SendIssueNotificationsPostJob
[INFO] [08:30:17.770] Executing post-job class org.sonar.plugins.core.batch.IndexProjectPostJob
[INFO] [08:30:17.785] Executing post-job class org.sonar.plugins.dbcleaner.ProjectPurgePostJob
[INFO] [08:30:17.800] -> Keep one snapshot per day between 2015-01-05 and 2015-02-01
[INFO] [08:30:17.802] -> Keep one snapshot per week between 2014-02-03 and 2015-01-05
[INFO] [08:30:17.803] -> Keep one snapshot per month between 2010-02-08 and 2014-02-03
[INFO] [08:30:17.804] -> Delete data prior to: 2010-02-08
[INFO] [08:30:17.813] -> Clean Contact [id=1]
[INFO] [08:30:17.819] <- Clean snapshot 22
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 33.827s
[INFO] Finished at: Mon Feb 02 08:30:18 CET 2015
[INFO] Final Memory: 29M/391M
[INFO] ------------------------------------------------------------------------

Une fois le traitement terminé (build success dans la console), rafraichissez la page http://localhost:9090/sonar de votre serveur SonarQube local pour y consulter un tableau de bord de votre projet :

Il faut cliquer sur le projet.

Ce Dashboard technique qui affiche les indicateurs pour chacun des 7 péchés du développeur :

1. Duplication de code ;
2. Mauvaise distribution de la complexité
3. Mauvais design (cycles de dépendances)
4. Pas de tests unitaires
5. Pas de respect des standards
6. Bugs potentiels (FindBugs)
7. Pas ou trop de commentaires

Les éléments du tableau de bord les plus importants sont l'indice de qualité, facteur de complexité, complexité (en bas à gauche), les mesures de couverture de test (couverture des tests unitaires et succès de test unitaires). Ensuite viennent les possibles violations de sécurité (Possibly Security violations), Indice d'interdépendance entre packages (Package Tangle Index) et Dépendances à couper (Dependencies to cut), sont certainement à portée de main afin de garder des paquetages propres et des dépendances faiblement couplées. Sur la même note, LCOM4 pour Lack of Cohesion in Methods (manque de cohésion dans les Méthodes - la valeur la plus basse est la meilleure) et complexité mettent également en lumière comment vos classes, méthodes et fonctions sont faiblement couplées. Tous ces composants sont de bons indicateurs de la qualité des logiciels et reflètent le soin mis dans le code sous-jacent écrit avec la qualité constamment à l'esprit !

La vue Points chauds (Hotspot) perce maintenant plus loin dans quelques autres aspects importants de l'analyse et met en évidence les domaines qui nécessitent plus d'attention ou si un défaut est proche de son point limite - soit a déjà traverser la limite maximale autorisée ou a besoin d'un peu plus de rabotage pour répondre aux exigences. Cette vue priorise donc les maintenances à effectuer.

La vue OUTILS / Design donne une ventilation des dépendances des paquets entre eux et met en évidence les cycles de dépendances. C'est une des choses les plus complexes à faire sur un moyen ou grand projet.

Le drilldown sur les défauts permis par OUTILS / Défaults (TOOLS / Issues Drilldown) est un tableau de bord donnant suffisamment de renseignements pour savoir ce qui ne va pas et où aller et comment y remédier. Il archive les vieux défauts et ceux qui ont été résolus, et donne une mesure de la gravité de Bloquant à Info.

D'autres écrans existent :

• Le Dashboard de management SQALE qui calcule la dette technique (ce module est payant).
• Le nuage Cloud présente de façon mélangée les noms des classes de l’ensemble du projet : les noms les plus gros et les plus rouges sont ceux à corriger en premier.
• La page Time machine permet de voir la progression de la qualité du code dans le temps.

SourceSup Jenkins et Eclipse

Se tenir informé de l’état de son (ses) build(s) est primordial dès lors que l’on utilise un environnement d’intégration continue. Quand on a de la chance on a un buildwall dans son espace de travail au milieu des développeurs… sinon c’est un peu du chacun pour sa peau.

Ma solution préférée (différente des mails et autre moyen de notifications) consiste à monitorer Jenkins depuis son IDE Eclipse

Il existe un connecteur mylyn pour Jenkins (et aussi Hudson). Celui-ci permet de suivre le statut des jobs que l’on choisit et bien plus encore.

Installation

Pré requis : Le plugin Mylyn doit être installé. Pour ma version d’Eclipse (Juno), le connecteur est disponible dans le répository mylyn. Direction Help > Install new software... > Mylyn for Eclipse Juno > Mylyn Integrations > Mylyn Build Connector: Hudson/Jenkins pour dérouler le processus d’installation et redémarrage d’Eclipse. L'URL exacte du dépôt est http://download.eclipse.org/mylyn/releases/latest.

Configuration

Une nouvelle entrée est disponible dans les préférences d’Eclipse : Eclipse > Preferences > Mylyn > Builds

On peut :

• Rafraichir le statut des builds toutes les X minutes ou seulement lorsque la vue "Build" est active.
• Changer le type de notification disponible, par défaut un changement de statut du build ouvrira une popup dans dans la fenêtre d’Eclipse.

Il suffit ensuite d’ajouter une instance Jenkins :

• Afficher la vue Mylyn > Builds, on obtient l’écran suivant : Vue Builds dans Eclipse.

• On clique sur create a build server, sélectionner Hudson (support Jenkins),
• Renseigner les informations nécessaires, puis cliquer sur Validate pour vérifier que la connexion s’effectue correctement,
• Sélectionner les jobs à surveiller : Configuration de la connection Jenkins.

Les jobs sélectionnés sont maintenant disponible dans la vue Builds.

Utilisation

Exemple de notification pour être prévenu de l’état du build :

En double cliquant sur un job dans la vue Builds, on obtient une fiche Mylyn :

Dans le cas d'un build réussi :

la fiche Mylin est :

Parmis les fonctionalités sympa, on peut :

• Lancer un build,
• Obtenir le contenu de la console Jenkins dans la vue console d’Eclipse :

• Charger les résultats des tests dans la vue JUnit. C’est très pratique quand des tests ont échoués, ceux-ci se retrouvent directement liés aux sources dans le workspace ;

et plein d’autres choses dont je me sert moins souvent…