46
INTÉGRATION DE HUDSON, MAVEN, SUBVERSION ET SONAR GL5 G1_2011/2012 INSAT 1

Sonar-Hodson-Maven

Embed Size (px)

Citation preview

Page 1: Sonar-Hodson-Maven

INTÉGRATION DE HUDSON, MAVEN,

SUBVERSION ET SONAR

GL5 G1_2011/2012

INSAT

1

Page 2: Sonar-Hodson-Maven

PLAN

Introduction

Maven

Subversion

Hudson

Sonar

Conclusion

2

Page 3: Sonar-Hodson-Maven

I. INTRODUCTION

Les outils de gestion de la qualité tout au long du cycle de vie visent l’optimisation

des performances et l'efficience des entreprises dans la réussite de leurs projets.

Parmi les produits les plus souvent cités, figurent ceux issus de l’Open Source, et

ensuite, ceux issus des catalogues Microsoft, Mercury, IBM et Serena..

Tout au long de notre exposé, nous allons essayer d’illustrer quelques unes des

fonctionnalités présentées à travers des exemples intégrant à la fois Maven 3,

Hudson 2.1.2, Subversion 1.6.15 et Sonar 2.9 tantôt sur une machine windows 7

et tantôt sur une machine mac OSX SnowLeopard.

A travers cet exposé nous allons tenter de mettre en exergue l’adaptabilité de ces

différents outils et leurs nombreuses possibilités d’utilisation.

3

Page 4: Sonar-Hodson-Maven

II. MAVEN

Plan:

Historique

Principes de Maven

Cycle de vie

Fonctionnalités

4

Page 5: Sonar-Hodson-Maven

1) HISTORIQUE DE MAVEN

Maven 1est né en 2002.

Il est d’abord apparu comme sous-projet du projet Jakarta Alexandria, avant

de trouver refuge au sein du projet Apache Turbine.

Il est devenu un projet Apache à part entière en 2003.

Les défauts de Maven 1 l'ont empêché de véritablement percer dans le

monde Java. Toutefois, Maven 1 a permis de roder les principaux

mécanismes de Maven 2, et en particulier son principe de cycle de vie.

Maven 2 sort en version finale à la fin de l'année 2005. Cette version

apporte:

Performances

Stabilité

Fonctionnalités

etc.

Maven 2 n'offre toutefois aucune compatibilité avec son prédécesseur

et oblige ainsi les équipes de développement à réécrire tout ou partie de leur

fichier de configuration .

5

Page 6: Sonar-Hodson-Maven

1) HISTORIQUE DE MAVEN

Quelques problèmes rencontrés avec Maven 2 :

• Complexité d’intégration d’autres outils avec Maven 2

• Le pom.xml est trop verbeux.

• Trop grande utilisation de plugins.

• Documentation "officielle" peu fournie et assez peu intuitive.

• XML parfois redondant, même en utilisant l'héritage.

• Support pas encore parfait dans les IDE, mais les choses s'améliorent.

• Développement et support des plugins "officiels" inégaux.

• Manque de souplesse, de rigueur sur certains principes (difficile de sortir du

cycle de vie par exemple). 6

Page 7: Sonar-Hodson-Maven

1) HISTORIQUE DE MAVEN

Les nouveautés de Maven 3:

Réécriture du coeur de Maven

Rétrocompatibilité

Maven apprend d'autres langues

Composition des pom

Extensibilité de Maven

Construction du plan de build

Accès aux repositories et gestion des dépendances

Maven Shell

Support des IDE, de l’intégration continue, au sein des gestionnaires de

repositories

7

Page 8: Sonar-Hodson-Maven

2) PRINCIPES DE MAVEN

1. Convention over configuration

Portabilité et standardisation des projets

Meilleure lisibilité et compréhensibilité des projets

2. Exécution déclarative

Description du projet (dépendances, plugins) sous forme xml

Le fichier de configuration POM.xml est déclaratif

3. Réutilisation de la logique du build

Encapsulation de la logique du build dans des modules appelés plugins

Exécution de ces plugins dans un ordre défini par le « build life cycle »

Réutilisabilité de ces modules

4. Organisation cohérente des dépendances

Toute utilisation d’artéfacts dans une application Maven doit être signalée

dans le POM.xml.

Maven se charge du management et de l’organisation de ces dépendances.

8

Page 9: Sonar-Hodson-Maven

3) CYCLE DE VIE DE MAVEN

9

Page 10: Sonar-Hodson-Maven

3) CYCLE DE VIE DE MAVEN

Voici les phases du cycle de vie par défaut :

1. Validate: valider si le projet est correct et toutes les informations nécessaires

sont disponibles

2. Compile: compiler le code source du projet

3. Test: test du code source compilé en utilisant un cadre approprié pour tester

l'unité.

4. Package: prendre le code compilé et le package dans son format distribuable,

comme un JAR.

5. Integration-test: processus et déployer le package si nécessaire dans un

environnement où les tests d'intégration peuvent être exécutés

6. Verify: exécuter un contrôle permettant de vérifier si le package est valable et

répond aux critères de qualité

7. Install: installer le paquet dans le dépôt local, pour une utilisation en tant que

dépendance à d'autres projets au niveau local

8. Deploy: fait dans un environnement d'intégration ou de libération, des copies à

l'emballage final de la garde à distance pour le partage avec d'autres

développeurs et des projets.

10

Page 11: Sonar-Hodson-Maven

3) CYCLE DE VIE DE MAVEN

Il y a deux autres phases du cycle de vie de maven :

Clean life cycle : efface les anciens fichier buildés

pre-clean

clean

post-clean

Site life cycle: génère la documentation du site pour ce projet

Pre-site

Site

Post-site

Site-deploy

11

Page 12: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build

Modularisation du projet

Gestion des dépendances

Vérification de la qualité du code source

Développement piloté par les tests

Automatisation des tests d’acceptation

Automatisation du déploiement

12

Page 13: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build:

Traduire la liste des tâches quotidiennes à faire sous forme de script.

L'automatisation du build offre une gamme d'avantages:

• l'accélération du build

• l'élimination des mauvais builds

• la normalisation dans les équipes et les organisations,

• une efficacité accrue, et améliorations dans la qualité du produit.

13

Page 14: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build

Modularisation du projet:

La modularisation du projet répond au besoin des grandes entreprises de

diviser une application en plusieurs modules et ce tout en offrant la

possibilité de travailler avec les mêmes ressources telles que les base de

données existantes, les réseaux etc. Lorsqu’on parle de modularisation , on

parle de projet parent et de projet fils et donc de fichier POM parent et de

fichiers POM fils.

14

Page 15: Sonar-Hodson-Maven

Exemple de fichier POM parent

<dependencyManagement>

<dependencies>

<dependency>

<groupId>mysql</groupId>

<artifactId>mysql-connector-java</artifactId>

<version>5.1.2</version>

</dependency>

<dependencies>

</dependencyManagement>

Exemple de fichier POM fils

<dependency>

<groupId>mysql</groupId>

<artifactId>mysql-connector-java</artifactId>

</dependency>

Le fichier POM Parent contient la définition complète de la

dépendance.

Mais tous les modules fils qui nécessitent cette dépendance

contiennent un bout de la définition de la dépendance et ce pour

éviter les conflits de versions.15

Page 16: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build

Modularisation du projet

Gestion des dépendances:

Cette fonctionnalité est universellement reconnue comme étant l’une des

meilleures fonctionnalités de Maven. Il serait intéressant de présenter cet

aspect de Maven pour les projets multi modulaires.

Dans les projets multi modulaires, les dépendances peuvent être définies dans

le fichier POM parent et peuvent être héritées à partir des fichiers POM fils

de la façon et au moment voulus. Le fait d’avoir une seule source de

définition des dépendances rend le versioning des dépendances plus simple

et ainsi les dépendances des grands projets sont organisées et gérables

dans le temps.

16

Les dépendances de Maven disposent de 6 scopes possibles, à savoir:

Compile: disponible par défaut dans le classpath

Provided: suppose que soit le jdk, soit l’environnement apporte cette dépendance.

Runtime: dépendances nécessaires lors du runtime et sont spécifiées dans le runtime

classpath.

Test: Dépendances nécessaires pour la compilation et l’exécution des tests.

System: la dépendance est toujours disponible.

Import: importe les dépendances spécifiées dans le POM incluse via l’élément

<dependencyManagement>.

Page 17: Sonar-Hodson-Maven

Définir la

liste des

dépendance

s

Interroger le

repository local

pour trouver les

dépendances

utilisées.

Interroger

les

repositories

distants.

Télécharger

depuis un

repository distant

les dépendances

absentes du

repository local.

Utiliser la

dépendance

pour construire

le projet

Page 18: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build

Modularisation du projet

Gestion des dépendances

Vérification de la qualité du code source:

Le plug-in Apache Maven PMD exécute automatiquement l'outil d’analyse du

code sur le code source et génère un rapport de site avec des résultats.

Dans une configuration typique, la génération échoue si PMD

détecte les problèmes de qualité de la source.

• pmd:pmd crée un site PMD de reporting basé sur les règles et la

configuration du plugin.

• pmd:cpd génère un rapport de l’outil CPD de détéction des copier/coller.

• pmd:check vérifier si le rapport PMD est vide, sinon il fait échouer le

build.

• pmd:cpd-check vérifie si le rapport CPD est vide, sinon le build échoue.18

Page 19: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build

Modularisation du projet

Gestion des dépendances

Vérification de la qualité du code source

Développement piloté par les tests:

Pour Apache Maven les tests unitaires et les tests d'intégration font partie

intégrante du cycle de vie du build, permettant ainsi aux programmeurs et

aux équipes de facilement mettre en œuvre la pratique du TDD (Test Driven

Development).

19

Page 20: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build

Modularisation du projet

Gestion des dépendances

Vérification de la qualité du code source

Développement piloté par les tests

Automatisation des tests d’acceptation:

Selenium est un framework d'automatisation des tests très populaire qui

fonctionne avec un grand nombre de technologies, y compris Java, C #,

Ruby, Groovy, Python, PHP et Perl.

Afin d'écrire des tests d'automatisation, Selenium fournit l'IDE sélénium, qui est

un plugin pour Mozilla Firefox qui permet surtout d'enregistrer et de rejouer

les tests et de les exporter dans différents langages, y compris Java.

Le plugin Selenium Maven vous permet de spécifier des tests

d’automatisation créé pour Selenium dans votre Projet Maven et de les

intégrer avec le cycle de vie du build deMaven.

20

Page 21: Sonar-Hodson-Maven

Le démarrage du serveur de Selenium nécessite la synchronisation avec la

phase de test de pré-intégration du cycle de vie du build.<plugins>

<plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>selenium-maven-plugin</artifactId>

<executions>

<execution>

<phase>pre-integration-test</phase>

<goals>

<goal>start-server</goal>

</goals>

<configuration>

<background>true</background>

</configuration>

</execution>

</executions>

</plugin>

</plugins>

21

Page 22: Sonar-Hodson-Maven

Cependant, pour exécuter les tests Selenium, nous aurons également besoin

de démarrer le serveur d'applications Web voici un exemple avec Jetty.

<plugin>

<groupId>org.mortbay.jetty</groupId>

<artifactId>maven-jetty-plugin</artifactId>

<version>6.1.10</version>

<executions>

<execution>

<id>start-jetty</id>

<phase>pre-integration-test</phase>

<goals> <goal>run</goal> </goals>

<configuration>

<scanIntervalSeconds>0</scanIntervalSeconds>

<daemon>true</daemon>

</configuration>

</execution>

<execution>

<id>stop-jetty</id>

<phase>post-integration-test</phase>

<goals> <goal>stop</goal> </goals>

</execution>

</executions>

</plugin> 22

Page 23: Sonar-Hodson-Maven

4) FONCTIONNALITÉS DE MAVEN

Automatisation du build

Modularisation du projet

Gestion des dépendances

Vérification de la qualité du code source

Développement piloté par les tests

Automatisation des tests d’acceptation

Automatisation du déploiement:

Le plugin Maven Deploy est utilisé pour ajouter des artefacts (s) à un repository

distant pendant la phase de déploiement de cycle de vie du build.

Ce plugin introduit deux objectifs:

deploy: deploy: Pour déployer un projet et tous ses artefacts

deploy: deploy -file: Pour déployer un seul fichier d’artefact

23

Page 24: Sonar-Hodson-Maven

III. SUBVERSION

Plan:

Présentation

SVN vs CVS

24

Page 25: Sonar-Hodson-Maven

1) PRÉSENTATION DE SUBVERSION

La gestion de versions est une activité qui consiste à maintenir

l'ensemble des versions ou révisions d’un logiciel ou autre document.

On peut ainsi mieux suivre et gérer le contenu, ou en restaurer une

version antérieure, notamment si on fait une erreur dans la version la

plus récente. Le suivi des versions est particulièrement indiqué

lorsque plusieurs personnes collaborent à un projet ou lorsqu'un

travail passe par plusieurs étapes de développement et de révision.

Subversion est un logiciel de gestion de sources et de contrôle de

versions.Il se veut comme successeur logique de CVS et nous provient

du monde de l'open source

25

Page 26: Sonar-Hodson-Maven

1) PRÉSENTATION DE SUBVERSION:

INSTALLATION DE SUBVERSION

L’installation de SVN passe par plusieurs étapes:

télécharger le plus récent svn-x.y.z-

télécharger le plus récent setup.exe,

télécharger le plus récent SVNService.zip

télécharger l'installeur le plus récent de TORTOISEsvn à savoir

TortoiseSVN-1.3.0.5416-svn-1.3.0.msi.

26

Page 27: Sonar-Hodson-Maven

1) PRÉSENTATION DE SUBVERSION:

NOTIONS DE BASE

Repository:

Un dépôt (Repository) Subversion est l’emplacement central où sont

stockées toutes les données relatives aux projets gérés. Le dépôt est

accédé via une URL locale ou distante.

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.

27

Page 28: Sonar-Hodson-Maven

1) PRÉSENTATION DE SUBVERSION:

LES COMMANDES CLIENT

28

Page 29: Sonar-Hodson-Maven

1) PRÉSENTATION DE SUBVERSION:

GESTION DES CONFLITS

il y a 4 différentes manières de résoudre ce genre de

conflits:

Retarder la résolution de conflit

Fusionner les conflits à la main

Copier un fichier dans le fichier actif

Annuler les changements

29

Page 30: Sonar-Hodson-Maven

2) SVN VS CVS

Subversion présente les mêmes fonctionnalités de CVS, à savoir :

La consultation et la possibilité de restauration des anciennes versions d'un fichier.

Les raisons des modifications apportées et les auteurs de celles-ci.

Les modifications de versions sont stockées sous forme de delta (différence entre deux versions) pour les fichiers.

Mais il a également quelques spécificités qui lui sont propres :

Tracer les versions de répertoires, de fichiers et de droits sur les fichiers.

Renommer un fichier ou un répertoire tout en conservant son historique.

Les propagations de version (commit) sont atomiques. Une propagation réussit uniquement si tous les fichiers de la version sont correctement propagés.

Les numéros de versions concernent une propagation et non les fichiers eux-mêmes.

Subversion peut se coupler avec le protocole HTTP Webdav/deltaV.

Les sauvegardes par delta sont aussi possibles sur les fichiers binaires.30

Page 31: Sonar-Hodson-Maven

IV. HUDSON

Plan:

Présentation de l’intégration continue

Outils de l’intégration continue

Présentation de Hudson

31

Page 32: Sonar-Hodson-Maven

1) PRÉSENTATION DE L’INTÉGRATION

CONTINUE

Pour que l'Intégration Continue puisse se faire correctement, il faut:

Partager les sources du projet via un serveur de gestion de

contrôle des sources SCM tel que CVS ou SVN.

L’équipe de développement postent régulièrement les

modifications apportées au code.

Disposer de tests unitaires qui seront exécutés par Junit ou

TestNG.

32

Page 33: Sonar-Hodson-Maven

1) PRÉSENTATION DE L’INTÉGRATION

CONTINUE

Les intérêts de l’Intégration Continue:

Vérification fréquente du code, et de sa bonne compilation.

Réalisation des tests unitaire et / ou fonctionnels, voire tests

d'intégration.

Mise à disposition éventuelle d'une version testable comportant les

dernières modifications du code.

Possibilité de créer des rapports périodiques exprimant la qualité du

code, la couverture des tests, etc. Si le projet est configuré pour Maven,

alors on pourra créer le site du projet qui contiendra l'ensemble de ces

rapports.33

Page 34: Sonar-Hodson-Maven

2) OUTILS DE L’INTÉGRATION CONTINUE

Anthill Pro.

Atlassian Bamboo.

Build Forge.

Cruise Control : l'un des outils d'IC les plus anciens et plutôt

populaire.

Apache Continuum : l'outil " officiel " de la communauté Maven.

Hudson

Luntbuild (et Luntbuild pro).

JetBrains TeamCity.34

Page 35: Sonar-Hodson-Maven

3) PRÉSENTATION DE HUDSON:

DÉFINITION

Hudson est un outil open source d'intégration continue, fonctionnant dans un

conteneur de servlets, ou en mode autonome avec son propre serveur Web

embarqué.

Effectuer des builds et des tests: Ant, Maven, MSBuild, …

Check out du code source: Subversion, Mercurial, …

Réaliser des tests unitaires: Junit

Notifier les utilisateurs: E-mail, RSS, …

Gérer la qualité du code: CheckStyle

35

Page 36: Sonar-Hodson-Maven

3) PRÉSENTATION DE HUDSON:

FONCTIONNALITÉS PRINCIPALES

Indicateurs:

Statut d’un projet

Santé d’un projet

Tendance d’un projet

Maître et esclaves

Matrice de configuration

Gestion des utilisateurs

Sécurité

Rapports de tests

Hudson dispose de la possibilité d'étendre ses capacités grâce à l'ajout de

plugins et à la gestions de ceux-ci mais également grâce à la création de

nouveaux plugins36

Page 37: Sonar-Hodson-Maven

V. SONAR

Plan:

Présentation du contrôle de la qualité

Présentation de Sonar

37

Page 38: Sonar-Hodson-Maven

1) PRÉSENTATION DU CONTRÔLE DE

QUALITÉ

Sonar offre une solution performante du contrôle de la qualité d‘un logiciel.

Dans le monde informatique en général, et en Java en particulier, la qualité

d'une application va être directement liée à la qualité du code

exécution de tests unitaires

analyse de la couverture du code par ces tests

vérifications du respect des règles de codage, etc.

Le contrôle de la qualité va donc pousser l'équipe de développement à

adopter et à respecter certains standards de développement.

Le but : rendre le code plus sûr, mais de permettre d'y déceler les erreurs le

plus rapidement possible et donc de les corriger ! 38

Page 39: Sonar-Hodson-Maven

2) PRÉSENTATION DE SONAR:

HISTORIQUE ET FONCTION

Sonar est un outil open source initialement développé par la société

suisse Hortis.

Depuis novembre 2008, c'est la société suisse SonarSource qui se

charge du développement et du support de Sonar.

Le but principal de cet outil est de fournir une analyse complète de

la qualité d'une application en fournissant de nombreuses

statistiques (ou métriques) sur ses projets.

Ces données permettent ainsi d'évaluer la qualité du code, et d'en

connaître l'évolution au cours du développement.

39

Page 40: Sonar-Hodson-Maven

2) Présentation de Sonar: Architecture

une base de

données, qui

stocke et

historise les

informations sur

les projets

surveillés par

Sonar

le serveur web

qui permet la

navigation et la

consultation des

analyses

réalisées sur les

projets

un exécuteur (basé

sur Maven 2/3, Ant

ou un exécuteur

Java) dont le but

sera de lancer un

certain nombre

d'outils d'analyse, et

d'en agréger les

résultats éventuellement un

plugin pour

Eclipse qui offre

une meilleure

intégration des

données de Sonar

dans son outil de

développement.

40

Page 41: Sonar-Hodson-Maven

2) PRÉSENTATION DE SONAR:

PRINCIPALES FONCTIONNALITÉS Tableau de bord complet des différents projets suivis.

Détection rapide du code à risque.

Mesures quantitatives : nombre de classes, duplication de code, etc.

Mesures qualitatives : couverture et taux de réussite des tests, complexité du code, respect des

règles de codage...

Historiques des statistiques

Support de plus de 600 règles de qualité.

Gestion de profils pour les règles de codage.

Visualisation du code source, surlignant les violations des règles de codage.

Fonction "Time machine" permettant de comparer plusieurs versions d'une application.

Identification des points faibles d'un projet.

Support des plugins.

41

Page 42: Sonar-Hodson-Maven

3) FONCTIONNEMENT DE SONAR:

OUTILS EXTERNES

Afin d'analyser un projet Java, Sonar va se baser en partie sur des outils

externes, dont :

42

Page 43: Sonar-Hodson-Maven

3) FONCTIONNEMENT DE SONAR:

VISUALISATION DES DONNÉES

Liste des projets

Vue d’un projet

Les métriques

Visualisation du code source:

le nom du projet

sa version

la taille du projet

le taux de respect des règles

quand a été réalisé le dernier build

les principaux liens (vers l'application, le site du projet, le serveur

d'intégration continue, le serveur de gestion des sources, etc.)

les éventuelles alertes sur le projet ; etc.

Vue « Dashboard»

Vue « Components»

Vue "Violations drilldown»

Vue « Time Machine»

Vue "Clouds«

Vue "Design«

Vue "Hotspots«

Vue "Libraries"

Vue "Settings«

Vue "Project Roles"

43

Page 44: Sonar-Hodson-Maven

4) INTÉGRATION DE SONAR

Si votre projet utilise déjà Maven 2 ou 3, le plus simple est de faire appel au

plugin Maven de Sonar. La première chose à faire est de définir quelques

paramètres Maven à placer de préférence dans son fichier settings.xml.

Nous redéfinissons là les paramètres de connexion à la base de données,

ainsi que l'URL du serveur Sonar.

Il suffit ensuite de lancer la commande suivante : mvn sonar:sonar

Nous venons de voir comment lancer l'analyse Sonar manuellement. Mais il est

bien plus profitable de faire réaliser cette tâche automatiquement, grâce à un

outil d'intégration continue comme Hudson.

44

<profile>

<id>sonar</id>

<activation>

<activeByDefault>true</activeByDefault>

</activation>

<properties>

<!-- example pour mysql -->

<sonar.jdbc.url>jdbc:derby://localhost:1527/sonar;create=true

</sonar.jdbc.url>

<sonar.jdbc.driverClassName>org.apache.derby.jdbc.ClientDriver

</sonar.jdbc.driverClassName>

<sonar.jdbc.username>sonar</sonar.jdbc.username>

<sonar.jdbc.password>sonar</sonar.jdbc.password>

<!-- server on a remote host -->

<sonar.host.url>http://127.0.0.1:9000/</sonar.host.url>

</properties>

</profile>

Page 45: Sonar-Hodson-Maven

VII. CONCLUSION

Cet exposé nous a permis de mettre en avant la mise

en œuvre de la forge de développement et ce dans le

but de garantir la qualité logicielle.

Ces outils présentant l’avantage d’être assez faciles

d’utilisation et de configuration, néanmoins plusieurs

problèmes surviennent lors de leur mise en pratique et

ce à cause de facteurs externes : en l’occurrence

l’utilisation des serveurs d’application, l’installation de

mysql.. etc 45

Page 46: Sonar-Hodson-Maven

Merci pour votre attention

46