• Save
Hudson Aquarium Paris
Upcoming SlideShare
Loading in...5
×
 

Hudson Aquarium Paris

on

  • 3,202 views

Présentation de Romain Linolas de Valtech sur Hudson (Build Continu) à Paris le 12 décembre 2008

Présentation de Romain Linolas de Valtech sur Hudson (Build Continu) à Paris le 12 décembre 2008

Statistics

Views

Total Views
3,202
Views on SlideShare
3,158
Embed Views
44

Actions

Likes
3
Downloads
0
Comments
0

2 Embeds 44

http://blogs.sun.com 40
http://www.slideshare.net 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Hudson Aquarium Paris Hudson Aquarium Paris Presentation Transcript

    • Démonstration d’Hudson Romain Linsolas Sun Aquarium Paris – 12 décembre 2008
    • Sommaire L’Intégration Continue Qu’est-ce que c’est ? Les bonnes pratiques Les intérêts De l’importance des tests ! Démonstration d’Hudson Installation & Configuration Création d’un projet Fonctionnalités principales Fonctionnalités avancées
    • L’Intégration Continue Qu’est-ce que c’est ?
    • Définition L’Intégration Continue n’est pas un outil, mais une pratique. C’est le nom donné initialement par la communauté de l'Extreme Programming (« XP ») pour désigner la pratique de génie logicielle visant à accélérer la livraison des logiciels en réduisant le temps d'intégration.
    • Ce que l’on veut éviter ! Début de Fin de l’Itération l’Itération Intégration tardive Intégration Continue Développement Intégration
    • Architecture Serveur d’Intégration SCM (CVS, Subversion…) Continue Vérification Récupération du code Compilation + Exécution des Tests Commit Update Développeurs Génération de rapports, site du projet…
    • Cas d’erreur SCM (CVS, Subversion…) Serveur d’Intégration Continue Vérification – Récupération du code Erreur Commit Mail d’alerte Compilation + Exécution des Tests Développeur
    • Cas d’erreur - Correction SCM (CVS, Subversion…) Serveur d’Intégration Continue Vérification – Récupération du code Corrigé ! Correction Mail de confirmation Compilation + Exécution des Tests Développeur
    • Les intérêts de l’Intégration Continue (1) « Intégration »  Combiner toutes les modifications. « Continue »  Permanent ! Détection rapide des erreurs  Correction rapide ! L’I.C. ne supprime pas les bugs (hélas ) mais permet de les détecter plus rapidement ! Exécution des tests.
    • Les intérêts de l’Intégration Continue (2) Automatise les tâches laborieuses (compilation, tests, déploiements, etc.)  Réduction des risques !  Plus grande confiance dans les délivrables. Test de l’application sur un environnement sain. Génération des rapports (« metrics »), du site…
    • Bonnes pratiques (1) Maintenir un seul gestionnaire de sources Automatiser les « builds » Tests automatisés (Pratique du « TDD » : Développement par les tests). Automatisation des déploiements. « Commits » fréquents Une modification = un commit. Commiter tous les jours. Chaque commit va relancer le build sur l’I.C. Il faut des tests !! Code non couvert = bug potentiel difficile à identifier !
    • Bonnes pratiques (2) Maintenir des builds rapides Idéalement, 10 à 15 minutes maximum. Éventuellement, créer plusieurs types de builds si des tests sont trop longs. Donner une grande visibilité à l’I.C. Tout le monde doit savoir ce qu’il s’y passe. Faciliter l’accès au I.C., aux derniers exécutables créés... Réagir vite aux problèmes levés par l’I.C. Corriger une erreur récente est plus facile. Ignorer les erreurs revient à laisser les bugs persister ! Définir des standards, des règles : Au niveau codage, formatage, conventions… Définir des « règles comportementales » : Que faire quand un build échoue, que faire avant ou après un commit, etc.
    • Différents types de « builds » « Build » rapide Vérification fréquente du code : maximum toutes les heures, voire éventuellement à chaque commit. Compilation + exécution de tests unitaires. Doit se terminer en moins de 15 minutes. « Build » complet Moins fréquent (« nightly build »), plus long à terminer. Compilation + exécution de tous les tests (unitaires, fonctionnels, etc.). « Build de publication » Exécution complète. Création de rapports + création du site. Déploiement…
    • Les outils L’Intégration Continue est gérée par une application serveur dédiée. Se base sur des outils de « builds » comme Ant, Maven 2… De nombreux outils existent.
    • Hudson
    • Pourquoi Hudson ? Facilité d’installation et de configuration. Mise en place très rapide. « full web » : Pas de fichiers externe à modifier. Fonctionnalités nombreuses et puissantes. Facile et agréable à utiliser. Extensible (plugins). Évolution rapide (version 1.211) !
    • Téléchargement https://hudson.dev.java.net/
    • Installation / Démarrage Hudson.war java –jar hudson.war GlassFish Apache Tomcat
    • Démonstration ! http://localhost:8080/hudson
    • Questions ?
    • Références http://www.martinfowler.com/articles/continuousIntegration.html https://hudson.dev.java.net/ http://linsolas.developpez.com/articles/hudson/ http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix http://www.citconf.com/ Contact Romain Linsolas – Consultant romain.linsolas@valtech.fr