Présentation sur Maven 2 et petit retour d'expérience

Soirée Technique : L’intégration continue avec Maven 2
Présentation So@t License Creative Commons 2.0 – Share Alike Retour d’expérience sur la mise en œuvre de Maven dans un processus d’intégration continue

Agenda
Rappels sur l’intégration continue
Enjeux de l’intégration continue
Outils pour sa mise en œuvre
Rappels sur Maven 2
Un peu d’histoire…
Notions
Dans la vrai vie…
Exemple de mise en œuvre
Bonnes pratiques Maven
Présentation So@t License Creative Commons 2.0 – Share Alike

Présentation So@t License Creative Commons 2.0 – Share Alike Rappels sur l’intégration continue

Rappels sur l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Enjeux de l’intégration continue

Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Source: http://www.agitar.com/solutions/why_unit_testing.html Les 5% de bugs découverts après la release représentent 95% des coûts de correction

Rappels sur l’intégration continue Enjeux de l’intégration continue
Point cruciaux :
Traçabilité de la vie du projet
Reproductivité de l’environnement de compilation
Reproductivité de l’environnement technique
Présentation So@t License Creative Commons 2.0 – Share Alike Socle technique Environnement de build Intégration continue

Intégration continue ?
Processus d'automatisation des tâches récurrentes (construction, déploiement, exécutions des tests unitaires et d'intégration, ...)
Intérêt de l’intégration continue ?
Sa fréquence d'exécution!
Mise à disposition régulière de nouvelles versions d'une application
=> Meilleure visibilité!
Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike

Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Spécifications Développement, correction d’une fonctionnalité Implémentation de la fonctionnalité ou correction et des tests unitaires Compilation privée du module ou projet Enregistrement dans le SCM 1 Détection du besoin d’intégration Evènements envoyés par le SCM Scrutation du SCM Périodique, manuelle 2 Intégration Mise à jour depuis le SCM Compilation du projet Tests unitaires et d’intégration Analyses de la qualité de code 3 Historisation et publication des résultats Enregistrement des résultats Génération des rapports Notifications des résultats Publication de l’artéfact 4

Ne se résume pas seulement à la simple mise en œuvre d'un outil permettant d'automatiser la compilation!
C’est un processus qui va orchestrer le quotidien des développeurs autours de :
Un outil de construction automatisée (Ant, Maven, …),
Un unique système de gestion de sources (SVN, CVS, GIT, …),
Un serveur d'intégration continue (Hudson, Bamboo, Cruise Control, …)

L’intégration est une activité complexe…
L’effort augmente significativement avec :
le nombre d’artéfacts,
les tests d’intégration…et leurs définitions,
le nombre d’erreurs,
la qualité du code,
…
le temps écoulé depuis la dernière intégration.

L’intégration continue est apparue avec les pratiques XP avec comme motivation de remplacer les grosses et longues phases d’intégration en fin de projet par des phases plus petites et plus fréquentes
L’idée principale :
Réduire au minimum l’effort d’intégration de l’application sans altérer le processus de développement logiciel

Les builds sur les postes p0, p1, pi, pic… doivent être identiques
Ex : il faut pouvoir reproduire le build sur l’ensemble des postes de l’équipe mais aussi sur le serveur d’intégration continu
Les builds aux temps t0, t1, ti, … doivent être identiques
Ex : il faut pouvoir à tout moment reproduire le build d’une version taggée
dans l’espace p0 p1 pj pic dans le temps t1 ti t0

Le build est une opération qui paraît simple, mais dans les faits c’est une problématique compliquée et nous ne disposons toujours pas de solution qui permette d’assurer cela…

Rappels sur l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Et dans la pratique ?

Rappels sur l’intégration continue Et dans la pratique ?
Utiliser un outils de build
Utiliser un SCM
Utiliser un framework de tests unitaires
Utiliser un serveur d’intégration continue
Utiliser un framework de tests fonctionnels
Utiliser un outils de suivi de faits techniques (DM ou RA)
… Connaître son processus (du développement à la phase de livraison…)
… S’aider de l’existant et communiquer
… Apporter la culture

Rappels sur l’intégration continue Et dans la pratique ? - Outils (1/2)
Outils de build
Ant
Maven
SCM
SVN
CVS
ClearCase
GIT
Serveur d’intégration continue
Hudson
Continuum
Bamboo
TeamCity
CruiseControl

Rappels sur l’intégration continue Et dans la pratique ? - Outils (2/2)
Framework de tests unitaires
Junit
TestNG
Mockito
Framework de tests fonctionnels
Fitness
Selenium + Tellurium
Outils de suivi de faits techniques
Jira
Communiquer… intelligemment…
Wiki

Rappels sur l’intégration continue Et dans la pratique ? – En quelques mots… Présentation So@t License Creative Commons 2.0 – Share Alike Accueil d’un nouveau développeur Enregistrement des modifications Compilation, tests Analyses de code Détection du besoin d’intégration Chargement de modifications Production de code Outil de compilation Intégration continue Gestion de configuration Gestion de dépendances Compilations privées pom.xml

Rappels sur l’intégration continue Et dans la pratique ? – Pratiques et anti-pattern (1/3)
Détecter et résoudre les problèmes au plus tôt
Commiter du code qui marche fréquemment
Exécuter des builds privés
Développer de petites tâches
Commenter chaque commit
Valider le build par des tests (unitaires et fonctionnels) qui passent à 100%
Pas de test = pas d’erreur, les tests doivent être pertinents
Prendre en compte la couverture de test
Intégrer après chaque commit
Temps de build < 10 min
Distinguer les tests unitaires des tests d’intégration, fonctionnels, etc.
Exécuter une intégration complète au moins une fois par jour
Corriger les échecs de builds immédiatement ! Stopper les commits !
Adapter le système de notification à l’équipe

Reproduire le build dans le temps et l’espace
Le build doit être automatisé au maximum
L’environnement de build doit être propre
Privilégier le checkout, au moins pour l’intégration complète quotidienne
Nettoyer le dépôt local de Maven
Selon les cas, intégrer sur différentes plateformes
Dans certains l’utilisation d’un miroir du SCM peut-être utile
Anti-patterns :
Absence de référentiel de sources
Intégration sur le poste de développement
Utilisation de scripts de build différents entre le développement et l’intégration

L’amélioration de la qualité de code
L’analyse de code est à mettre en place dès le début du projet
Se fixer des objectifs raisonnables
Automatiser les tâches de relecture
Anti-patterns :
Les objectifs trop ambitieux peuvent décourager
Sélectionner les règles
Prévoir du temps dédier à l’amélioration de la qualité de code
Sentiment de flicage : les métriques ne sont pas une note
En réfléchissant un peu, il est très simple de contourner les outils d’analyse…
Excès de confiance
De bonnes métriques n’impliquent pas que l’application ne comporte pas de bogues, ou que de mauvaises pratiques n’ont pas été implémentées

Rappel sur l’intégration continue Et dans la pratique ? - Demo
Demo :
Serveur d’intégration continu (Hudson)
Outil de qualité de code (Sonar)

Présentation So@t License Creative Commons 2.0 – Share Alike Rappels sur Maven 2

Rappels sur Maven 2 Présentation So@t License Creative Commons 2.0 – Share Alike Un peu d’histoire…

Rappels sur Maven 2 Un peu d’histoire…
Mot Yiddish signifiant accumulator of knowledge
Né en aout 2001 avec le projet Alexandria puis utilisé pour simplifier le développement du projet Turbine (jakarta) – Framework de présentation de portail utilisé par Jetspeed 1
Constat :
De nombreux projets hétérogènes (ant différents, structure fichiers, …)
Une gestion des dépendances difficiles (librairies dans le SCM)

Volontés :
Avoir une manière standardisée de builder
Avoir une description du projet
Avoir une manière simple d’éditer les informations du projet
Avoir une manière simple de partager les librairies entre les différents projets
Ne plus stocker les librairies dans le SCM

Maven est un Project Management Framework
Il permet de :
Rendre le processus de build simple
Uniformiser le processus de build
Fournir des informations de projet de qualité
Fournir des directives pour les best practices development
Migrer de manière transparente à de nouvelles fonctionnalités

Rappel sur Maven 2 Présentation So@t License Creative Commons 2.0 – Share Alike Notions

Rappels sur Maven 2 Notions
Utilise la notion de projet où existent :
Un ensemble de fichiers contenant du code
[Des fichiers de configuration]
[Des licenses]
Des développeurs impliqués associés à leurs rôles sur le projet
Les dépendances
Les ressources (images, …)
Convention Over Configuration

Rappel sur Maven 2 Notions - POM
POM – Project Object Model = fichier descripteur décrivant le projet
Hérite du super-pom
Permet de normaliser

Rappel sur Maven 2 Notions - POM
Contient :
groupId (ex : fr.soat.sample)
artifactId (ex : mon-premier-module)
packaging (ex : jar)
version
name
url
description
dependency
plugin
build

Rappel sur Maven 2 Notions – Structure d’un projet
ex :
Présentation So@t License Creative Commons 2.0 – Share Alike =>

Rappel sur Maven 2 Notions – Structure d’un projet
ex 2 :
Présentation So@t License Creative Commons 2.0 – Share Alike =>

Rappel sur Maven 2 Notions – Gestion des dépendances
Gère les dépendances du projet
Gère les dépendances transitives entre projet
ex :
A (sample-war.war) dépend de B (sample-jar.jar)
B (sample-jar.jar) dépend de C (log4j.jar)
Présentation So@t License Creative Commons 2.0 – Share Alike = + <groupId>fr.soat.sample.metier</groupId> <artifactId>jar-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <name>jar-sample</name> <dependencies> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.14</version> </dependency> </dependencies> <groupId>fr.soat.sample</groupId> <artifactId>war-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>war</packaging> <name>war-sample</name> <dependencies> <dependency> <groupId>fr.soat.sample.metier</groupId> <artifactId>jar-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> </dependencies>

Rappel sur Maven 2 Notions – Gestion de la visibilité
Existe 6 types de visibilité :
Compile : (par défaut) disponible dans toutes les phases
Runtime : les dépendances de portées runtime ne sont pas nécessaires pour la compilation, uniquement pour l'exécution (ex : drivers JDBC)
Provided : utilisée pour compiler l'application, mais non déployée (ex : librairies présentes dans le classpath d’un serveur d’application)
Test : uniquement nécessaires pour compiler et exécuter les tests (par exemple Junit)
System : similaire au scope Provided mais où le jar est spécifié explicitement (ie. Son chemin dans le système de fichiers)
Import : utilisé uniquement dans le cas d’une dépendance de type pom ans la section <dependencyManagement>

Rappel sur Maven 2 Notions – Gestion de la visibilité
ex :
Présentation So@t License Creative Commons 2.0 – Share Alike <groupId>fr.soat.sample</groupId> <artifactId>war-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>war</packaging> <name>war-sample</name> <dependencies> <dependency> <groupId>fr.soat.sample.metier</groupId> <artifactId>jar-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> <scope>provided</scope> </dependency> </dependencies>

Rappel sur Maven 2 Notions – Modules et Héritage
Permet de gérer des modules (référence à un autre projet maven, c’est à dire une référence à un autre POM)
Permet de gérer des héritages (référence à un projet père pour bénéficier des caractéristique de son POM)
Présentation So@t License Creative Commons 2.0 – Share Alike <groupId>fr.soat.sample</groupId> <artifactId>project-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>pom</packaging> … <modules> <module>jar-sample</module> <module>war-sample</module> </modules> <artifactId>war-sample</artifactId> <packaging>war</packaging> <name>war-sample</name> <parent> <groupId>fr.soat.sample</groupId> <artifactId>project-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <artifactId>jar-sample</artifactId> <name>jar-sample</name> <parent> <groupId>fr.soat.sample</groupId> <artifactId>project-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </parent>

Rappel sur Maven 2 Notions – Repository
Repository global :
Un/des repositories globaux (ex : http://repo1.maven.org/maven2/ ) contiennent les dépendances officielles et sont utilisés pour construire (par téléchargement) le repository local
Repository local :
(par défaut $HOME/.m2/repository) contient des dépendances officielles et courantes et est utilisé par les projets pour chercher les dépendances. Si elles ne sont pas trouvées dans le repository local, elles sont automatiquement téléchargées à partir du/des repositories globaux

Rappel sur Maven 2 Notions – Repository
Structure des repositories :

Rappel sur Maven 2 Notions – Cycle de vie
Consiste en une série de phases où chaque phase peut réaliser une ou plusieurs actions (ou goals) liée à la phase (ex : la phase de compilation invoque un ensemble de goal de compilation)
Possibilité d’invoquer un goal directement
ex : mvn release:prepare
Présentation So@t License Creative Commons 2.0 – Share Alike <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <executions> <execution> <id>stop-tomcat</id> <phase>generate-test-sources</phase> <goals> <goal>run</goal> </goals> <configuration> <tasks> <exec dir= "/home/dev/sps-tomcat/bin" executable="sh"> <arg line= "shutdown.sh" /> </exec> </tasks> </configuration> </execution> </executions> </plugin>

Rappel sur Maven 2 Notions – Profils
Possibilité de définir ses profils (ex : dev, initdb, dev-bdd) :
Permet de se dé-corréler d’une couche non utile aux développements courants (allégement de la compilation, tests propres au développement courant, ...)
Permet de tester par rapport à son environnement
ex :
mvn install -Pdev

Rappel sur Maven 2 Notions – Configuration
${MAVEN_HOME}/conf
settings.xml
Proxy internet,
Path du repository local,
Mirroirs,
Profils,
…
${HOME}/.m2
settings.xml
Mirroirs,
Profils,
Droits

Rappel sur Maven 2 Présentation So@t License Creative Commons 2.0 – Share Alike Dans la vraie vie…

Rappel sur Maven 2 Dans la vraie vie…
Demo :
Repo proxy (Nexus)
Plugins maven
Intégration eclipse (m2eclipse)

Présentation So@t License Creative Commons 2.0 – Share Alike Exemple de mise en œuvre

Exemple de mise en œuvre Contexte (1/2)
But : mise en place d’outils pour automatiser l’exécution de tests fonctionnels
Etat des lieux :
Contient :
4 webapps
Jetspeed
2 portlets
Webservices
1 bdd postgreSQL
SCM = SVN
Procédure de livrable :
L’équipe de production récupérait les sources sur le serveur cible et exécutait les commandes :
mvn jetspeed:mvn –Pdeploy
Copiait le war des webservices
17 TUs…

Exemple de mise en œuvre Contexte (2/2)
Outils :
IntelliJ, Eclipse, Netbeans
TeamCity :
mvn clean install
Artifactory
SVN
Maven 2 mais peu de connaissances (2-3 personnes sur 10)
Procédure de déploiement sur le poste du développeur
mvn jetspeed:mvn –Pdeploy (bdd, déploiement, …)

Exemple de mise en œuvre Plan d’action – Maitriser le build
Maitriser le build
Générer des wars déployables via un mvn install (ie. s’abstraire du processus Jetspeed (au moins en parti)
Générer un livrable : utilisation du plugin Assembly et externalisation des fichiers de configuration hors des war/jar
Mettre en place les bonnes pratiques Maven
SNAPSHOT
Profile
Scope/classifier
Alléger les POM des informations inutiles
Définir un projet parent contenant toutes les informations

Exemple de mise en œuvre Plan d’action – Accélérer le développement
Utilisation de JRebel sur le poste des développeurs

Exemple de mise en œuvre Plan d’action – le processus de développement
Mettre en place un environnement dont les données sont maitrisées sur lesquels un déploiement est fait quotidiennement et automatiquement via l’utilisation du plugin Cargo
Dev-Int
Mettre en place un environnement dont les données sont maitrisées sur lesquels un déploiement est fait quotidiennement et automatiquement via l’utilisation du plugin Cargo et sur lequel un ensemble de test fonctionnellement est effectué via le framework de test Selenium
TU-Dev-Int

Exemple de mise en œuvre Plan d’action – le processus de développement Présentation So@t License Creative Commons 2.0 – Share Alike Processus de développement développement TU NOK commit TU OK Compilation + TU Compilation ou TU NOK Compilation + TU + Déploiement Auto Dev-integ Compilation + TU + TF + Déploiement Auto TU-Dev-integ Compilation ou TU ou TF NOK Compilation ou TU ou TF NOK TU = tests unitaires TF = tests fonctionnels Poste développeur SVN TeamCity

Exemple de mise en œuvre Plan d’action – Le processus de livraison
Mettre en place un environnement le plus proche possible de l’environnement cible permettant de tester le livrable via les scripts utilisés par la production
Définir le rôle de l’environnement sur lequel les tests de QA sont effectués

Exemple de mise en œuvre Plan d’action – Le processus de livraison Présentation So@t License Creative Commons 2.0 – Share Alike Processus de livraison Production Livrable Environnement installé Déploiement Correction TF NOK Livraison Environnement Installé TF = tests fonctionnels Déploiement si TF OK sur env. dev-intégration Tests MOA NOK Poste Livreur (job Serveur CI) Pré-Intégration Intégration Développeurs

Exemple de mise en œuvre Plan d’action – Les tests fonctionnels
Utilisation de Selenium
Développement d’un framework s’appuyant sur Selenium pour rendre indépendant les scénarii de test de l’interface web (API offerte sous forme de DSL)

Exemple de mise en œuvre Plan d’action – Les pratiques de codage
Mise en place de Sonar
Mais…
Mal configuré
Mal utilisé par le management
Mal compris par le management
Cette culture doit être partagée!

Exemple de mise en œuvre Plan d’action – Le livrable
Utilisation du plugin Release pour gérer le processus de livraison (création tags, déploiement sur le Remote Proxy, …)

Exemple de mise en œuvre Focus – Retour sur les fichiers de configuration
Ici, tous les fichiers de configuration se trouvent dans le classpath serveur au runtime :
Permet :
Gestion de la configuration par la production
Ne pas avoir à « dé-warer » ou « dé-jarer »
Problématique :
Ne pas avoir de doublons
Solution appliquée :
1 module pour la configuration
Utilisation du resource/filter de Maven
Utilisation du classifier test

Exemple de mise en œuvre Focus – Retour sur le jeux de données
Ici, jeux de données dépendant de la base de données
Problématique :
Séparation entre le schéma et les données de tests
Solution retenue :
Dump bdd?
Fichier sql à maintenir?
Injecteur Java?
Doit être pensé dès le départ et la problématique doit être partagée!

Exemple de mise en œuvre Focus – Retour sur le livrable
Utilisation du plugin assembly
Utilisation d’1 module
Utilisation de la gestion de la transitivité de Maven pour gérer le livrable

Présentation So@t License Creative Commons 2.0 – Share Alike Bonnes pratiques Maven

Bonnes pratiques Maven En vrac…
SNAPSHOT
Utiliser dependencyManagement
Utiliser les plugins et déclarer leur version
Utiliser pluginManagement
Utiliser les modules et les héritages
Utiliser le même numéro de version dans tout le projet
Ne pas utiliser Maven pour ce qu’il n’est pas prévu
Utiliser un repository manager (Nexus, Archiva, Artifactory, …)
Ne pas skipper les tests unitaires
Comprendre son fonctionnement

Bonnes pratiques Maven En général…
Utiliser un SCM (SVN, CVS, Git, …)
Utiliser des outils de qualité de code (Sonar, Findbugs, Pmd, Checkstyle, Cobertura, …), les configurer, regarder l’évolution et améliorer son code
Utiliser le plugin Release quand cela est possible
Utiliser un serveur d’intégration continue (Hudson, Jenkins, Continuum, Bamboo, CruiseControl, …)
Faire prendre conscience à chacun de l’importance des processus

Bonnes pratiques Maven Focus
Plugin Release
Phase prepare :
Vérification du code présent
Vérification des SNAPSHOTS
Prompt de l’utilisateur sur les versions
Vérifie la validité du projet
Tags le projet sur le SCM à la version indiquée
Itère le numéro de version
Phase perform :
Checkout du code source
Génération du livrable, de la documentation et du code source et upload sur le remote proxy maven

Commandes
-pl
-amd
-am
-N
-T

Plugin Versions
mvn versions:set –DnewVersion=xxx
mvn versions:commit
mvn versions:rollback

Présentation So@t License Creative Commons 2.0 – Share Alike Pour aller plus loin…

Pour aller plus loin…
[Web] Site officiel de maven http://maven.apache.org/
[Livre] Apache Maven – N. De loof, A. Héritier [Pearson]
[Web] BetterBuildsWithMaven – V. Massol, J. Van Zyl, B. Porter, J. Casey, C. Sanchez http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
[Web] Maven the complete reference - T. O'Brien, J. Casey, B. Fox, J. Van Zyl, M. Moser, E. Redmond, L. Shatzer http://www.sonatype.com/books/mvnref-book/reference/public-book.html
[Web] Maven : The definive guide - T. O'Brien, J. Casey, B. Fox, J. Van Zyl, E. Redmond, L. Shatzer, B. Snyder, E. Hugonnet, E. Alliaume http://www.maven-definitive-guide.fr/
[Vidéo] Vers des exigences exécutables – O. Billard, A. Bonnefoy http://www.beta.parleys.com/#id=1880&sl=1&st=5
[Vidéo] Intégration Continue – enjeux, outils et bénéfices – P. Ensarguet, T. Carré http://www.beta.parleys.com/#id=1863&sl=1&st=5
[Vidéo] Sonar – O. Gaudin http://www.beta.parleys.com/#id=678&sl=1&st=5
[Vidéo] Les frameworks open source – R. Pelisse, F. Le Droff http://www.beta.parleys.com/#id=625&sl=1&st=5

Présentation So@t License Creative Commons 2.0 – Share Alike Question ?

http://jetoile.blogspot.com	442
http://jetoile.blogspot.fr	47
http://feeds.feedburner.com	9

Présentation sur Maven 2 et petit retour d'expérience

by Khanh Maudoux on Sep 23, 2011

Accessibility

Tags

Upload Details

Usage Rights

3 Embeds 498

Statistics

Présentation sur Maven 2 et petit retour d’expérience — Presentation Transcript