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
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.
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) !