Your SlideShare is downloading. ×
0
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Hudson Aquarium Paris
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Hudson Aquarium Paris

2,028

Published on

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

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,028
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. Démonstration d’Hudson Romain Linsolas Sun Aquarium Paris – 12 décembre 2008
  2. 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
  3. L’Intégration Continue Qu’est-ce que c’est ?
  4. 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.
  5. 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
  6. 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…
  7. 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
  8. 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
  9. 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.
  10. 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…
  11. 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 !
  12. 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.
  13. 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…
  14. 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.
  15. Hudson
  16. 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) !
  17. Téléchargement https://hudson.dev.java.net/
  18. Installation / Démarrage Hudson.war java –jar hudson.war GlassFish Apache Tomcat
  19. Démonstration ! http://localhost:8080/hudson
  20. Questions ?
  21. 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

×