Mardi Gras 'Intégration Continue

Mardi gras: Intégration Continue

Présenté par Xavier Bourguignon ([email protected])

Mardi gras 'Intégration Continue' 220/03/2009

Sommaire

Histoires (pas drôles) de projets sans intégration continue

Historique et objectif

Principes

Bonnes pratiques

Comparatif de Apache Continuum, Hudson et Atlassian Bamboo

Retour d'expérience sur Hudson

Quels gains attendre de la mise en place de l'intégration continue ?

Questions


Terminologie utilisée

BuildEnsemble des étapes nécessaires à la création du livrable d'un projet

Compilation, tests, packaging, …

CommitOpération de validation des modifications réalisées dans le répertoire de travail local et de propagation dans le gestionnaire de source d'où il est issu.

UpdateOpération de mise à jour du répertoire de travail local à partir du gestionnaire de source.

CheckoutOpération d'extraction d'une version d'un projet du gestionnaire de source vers un répertoire de travail local.


Terminologie

Branche



Un projet comme on en vit tous les joursle syndrôme du 'je comprends pas, ça marche sur mon poste !'

• commits partiels

• fichiers de configuration dépendants du poste de travail

Résultat: équipe régulièrement bloquée ½ journée

Un cas plus difficileProjet .Net, 25 personnes

Sur au moins 3 releases : Impossible de faire le build pour l'équipe de test. Perte : 1 journée avec 6 personnes en attente et 2 dév pour reprendre les commits 1 par 1.

Sur au moins 2 releases : Build ok. Livraison équipe de test. 2 jours de tests (6 p) et bug bloquant. Livraison en urgence d'un patch et commit. Release après une semaine de test et build passe pas. 2 jours de reprise du patch pour 2 dev. 2 jours équipe de test au chômage technique. Ensemble des tests de la semaine à repasser car pas confiance dans la constitution de la version précédente.

Résultat: 42 jours/h perdus.



Waterloo ...Projet Java, 60 développeurs:

6 mois de développement.

3 tentatives pour faire une release se soldant par un échec.

Décision: constituer une équipe de 6 personnes pour effectuer cette tâche !

Résultat: 2 ans de retard.

Constat

Plus une erreur est détectée tard et plus le coût de correction est élevé !

1 X

6,5 X

15 X

100 X

Conception Réalisation ValidationDéploiementExploitation

Sour

ces

Gartn

er /

IBM

2003

0

5

10

15

20

Etudes

Réalisati

on

Integratio

n

Pré-pr

oduction

Exploit

ation

Nombre d’heures requises pour corriger une anomalies – à partir du moment où elle est détectée

Source : http://www.nist.gov


Historique et Objectif

L'intégration Continue n'est pas un outil, mais une pratique issue de XP.

Déjà pratiqué par IBM dans les années 60 pour le développement de OS/360.

Objectif:Vérifier de façon automatique et à chaque modification de code source que le résultat des modifications ne produit pas de régression de l'application en cours de développement

Avantages: prévient rapidement en cas de code incompatible ou manquant

test immédiat des unités modifiées

les problèmes d'intégration sont détectés et réparés de façon continue, évitant les problèmes de dernière minute

une version est toujours disponible pour test, démonstration ou distribution.


Principes définis par Martin Fowler

Maintenir un dépôt unique de code source versionné

Automatiser les compilations

Rendre les compilations auto-testantes

Tout le monde committe tous les jours

Tout commit doit compiler la branche principale sur une machine d'intégration

Maintenir une compilation courte

Tester dans un environnement de production cloné

Rendre disponible facilement le dernier exécutable

Tout le monde doit voir ce qui se passe

Automatiser le déploiement


Bonnes pratiques sur le plan technique

Séparer en 2 jobs: continuous build : déclenché à chaque commit, compilation + tests unitaires.

10 mn maximum

nightly build : déclenché à heure fixe toutes les nuits, compilation, test unitaires, rapports de qualité (PMD, Checkstyle), packaging, déploiement sur plateforme de dév, tests fonctionnels

Une livraison à effectuer: un job spécifique : déclenché manuellement, compilation, tests unitaires, rapports

de qualités, packaging, déploiement sur plateforme de recette, tests fonctionnels

Faire l'intégration continue de la base de données.

Installer la solution d'intégration continue sur un serveur dédié.


Bonnes pratiques sur le plan humain

Définir des règles comportementales: que faire quand un build échoue ?

que faire avant et après un commit ?

Seul ceux qui ne commit pas ne peuvent pas casser le build ! Il est normal de casser le build de temps en temps, mais il n'est pas normal de le laisser casser

Annoncer à l'équipe que vous avez cassé le build et que vous vous en occupez

Ne doit pas être utilisé pour stigmatiser, mais pour responsabiliser !L'intégration continue est une sécurité pour le développeur

Installer un rituel divertissant pour motiver les développeurs à faire attention au build

Celui qui casse le build de nuit amène les croissants pour l'équipe

Mettre en place le jeu de l'intégration continue


Bonnes pratiques pour la mise en place

Commencer petitMise en place de l'infrastructure, de l'intégration continue

Simple mais qui fonctionne

Avoir 1 ou 2 projets pilotesPermet d'affiner la plateforme et le discours

Préparation à accueillir de nouveaux projets

CommuniquerCommuniquer sur les intérêts pour que tout le monde sache que cela existe

Donner du support: guide d'utilisation, bonnes pratiques, aide à mettre en place

Le nombre de projets commence à être conséquent, le serveur ne tient plus la charge

Envisager la mise en cluster, le build distribué



Open Source et gratuit

Soutenu par la fondation Apache

1ère version en 2005, dernière version 1.2.3

Open Source et gratuit

Kohsuke Kawaguchi, employé par SUN

1ère version en 2007, dernière version 1.292

Open Source et Payant (1200 à 8000$ selon version)

Atlassian (JIRA, Confluence)

1ère version en 2007, dernière version 2.2



Les axes de comparaison:L'ergonomie

L'installation et la configuration

Les gestionnaires de sources supportés

Les types de builds supportés

Les systèmes de notifications supportés

Les rapports de tests et de qualités supportés

L'intégration avec d'autres outils

Les capacités de répartition de charge













Installation et configuration

Standalone ✔ ✔ ✔

Webapp ✔ ✔ ✔

Base de données

DerbyMySql

MS SQL ServerOracle (en cours)

n/a PostgresMySql

MS SQL ServerOracle

ConfigurationFichier XML

Interface WebInterface Web Interface Web


Gestionnaire de sources supportés

Bamboo

ClearCase ✔ ✔ (plugin) ✔

CVS ✔ ✔ ✔

Git ✔ (plugin)

Mercurial ✔ ✔ (plugin) ✔

Perforce ✔ ✔ (plugin) ✔

PVCS ✔ (plugin)

Subversion ✔ ✔ ✔

Team Foundation Server

✔ (plugin)

Visual Source Safe ✔ ✔ (plugin)


Types de build supportés

Bamboo

Ant ✔ ✔ ✔

Ligne de commande (sh ou bat)

✔ ✔ ✔

Maven ✔ ✔ ✔

NAnt ✔ (plugin) ✔

MsBuild ✔ (plugin) ✔

Rake (Ruby) ✔ (plugin)

Phing (PHP) ✔ (plugin)


Système de notification supportés

Bamboo

Email ✔ ✔ ✔

Jabber ✔ ✔ ✔

MSN ✔

Nabaztag ✔ (plugin)

RSS ✔ ✔

Sametime ✔ (plugin)

System Tray ✔ (plugin)

Twitter ✔ (plugin)


Notre Nabaztag


Rapports de test et de qualités supportés

JUnit ✔ ✔ ✔

PHPUnit ✔

NUnit ✔ (plugin) ✔

TestNG ✔ ✔

MsTest ✔ (plugin) ✔

PMD ✔ (plugin)

CheckStyle ✔ (plugin)

FindBugs ✔ (plugin)

Sonar ✔ (plugin)

Clover ✔ (plugin) ✔

Cobertura ✔ (plugin)

Emma ✔ (plugin)





Intégration avec d'autres outils

Eclipse ✔ (plugin)

Intellij IDEA ✔ (plugin) ✔ (plugin)

Netbeans ✔ (plugin)

Visual Studio

JIRA ✔ (plugin) ✔

Mantis Bug Tracker ✔ (plugin)

Selenium ✔ (plugin)

Borland SilkCentral Test Manager

✔ (plugin)

FishEye ✔ ✔

Sventon ✔

ViewCVS ✔


Atlassian IDE Connector


Intégration de Hudson et Netbeans


Intégration de Hudson et JIRA


Répartition de la charge

Principe : des agents installés sur d’autres serveurs prennent à leur charge certains builds et

fournissent le résultat au serveur principal.

Fonctionnalité disponible avec les 3 outils- en version alpha pour Continuum

- avec Hudson, on spécifie quel build sur quel agent pour équilibrer la charge

- Bamboo distribue les builds en fonction des compatibilités entre le build et l'agent (jdk 1.4 sur un agent, 1.5 sur un autre)

- agent sur des instances Amazon EC2 avec la version 2.2 de Bamboo

Agent 1

Agent 2

Agent 3

Projet A

Projet B

Projet C

Master


Avantages et inconvénients de chaque solution

support de Maven (prepare et perform release depuis l'interface web)

build distribué en version alpha

les plugins (plus de 100 disponibles)

file fingerprint (marquage des jars pour suivre leur utilisation par d'autres builds)

external jobs (possibilités de monitorer des jobs externes)

release très fréquentes (trop ?)

intégration avec les produits Atlassian (JIRA, FishEye, Clover)

intégration dans Intellij IDEA

support Atlassian

payant


File fingerprint



Contexte:Une équipe de 10 développeurs pendant 2 ans.

Reprise du code d'un projet très similaire.

Un serveur dédié 'devFactory' avec: Hudson

Mantis Bug Tracker

Sventon

Subversion

Un serveur avec 2 environnements: Test, mis à jour toutes les nuits

Recette, mis à jour à chaque release



3 types de builds mis en place:Continuous Build:

compilation et tests unitaires

exécuté à chaque commit sur la branche principale

durée: 9mn

Nightly Build:

compilation, tests unitaires, rapports qualités, packaging, déploiement en environnement de test, tests fonctionnels,

exécuté toutes les nuits à 23h sur la branche principale

durée: 1h

Release Build:

compilation, tests unitaires,packaging, déploiement en environnement de test, tests fonctionnels,

exécuté manuellement sur la branche de livraison

Durée: 40 mn

Script de livraison sur le FTP du client et tag sur la version livrée


Retour d'expérience sur Hudson, plugins utilisés

Batch Task, permet de lancer des scripts supplémentaires sur un build donné (transfert du livrable sur le FTP du client et tagging de la version livrée)



Emma, FindBugs, Task Scanner, Warnings



Mantis



Continuous Integration Game, pour faire adhérer l'équipe (+1 point par build ok, -10 pour un build cassé, +4 pour un nouveau test qui passe, -4 pour un test en erreur)



Disk Usage, pour suivre la consommation d'espace disque de chaque job



Les difficultés rencontrées:L'intégration continue de la base de données

Les commits à la sauvette en fin de journée sans vérifier le résultat

1ère livraison difficile: développement sous windows, déploiement sous Solaris

Tentative de stigmatisation des casseurs de build par le management

Les succès:Jamais l'équipe n'a rencontré le syndrome 'je comprends pas, ça marche sur mon poste'

Plus de problème d'intégration après la 1ère livraison car passage de l'environnement de test sous Solaris.

Processus de livraison automatisé

Les développeurs juniors n'imaginent pas une seconde faire un projet sans IC


Quels gains attendre de la pratique de l'intégration continue ?

Le coût de mise en place:Installer la plateforme 1 à 2 jours (si sécurité)

'Maven-iser' ou 'Ant-iser' un projet 1 à 2 jours

Faire une documentation 1 jour

Offrir du support 20% d'une personne

Les gains:Selon IBM, vos développements seront 60% plus rapides et vous en réduirez les coûts de 25 %

Syndrome du 'ça marche chez moi !' ½ journée par équipe et par quinzaine

Cas difficile 42 jours maximum

Waterloo 1 an ?

Mais vous gagnerez surtout en sérénité et en visibilité !


Questions ?

Technology

Mardi Gras 'Intégration Continue