Your SlideShare is downloading. ×
0
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
Mardi Gras 'Integration Continue'
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

Mardi Gras 'Integration Continue'

2,036

Published on

Présentation sur l'intégration continue du 19 Mars 2009 effectuée par Xavier Bourguignon

Présentation sur l'intégration continue du 19 Mars 2009 effectuée par Xavier Bourguignon

Published in: Technology
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,036
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
9
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. Mardi gras: Intégration Continue Présenté par Xavier Bourguignon (xavier.bourguignon@hortis.ch)
  • 2. 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 19 Mars 2009
  • 3. Terminologie utilisée Build Ensemble des étapes nécessaires à la création du livrable d'un projet Compilation, tests, packaging, … Commit Opé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. Update Opération de mise à jour du répertoire de travail local à partir du gestionnaire de source. Checkout Opération d'extraction d'une version d'un projet du gestionnaire de source vers un répertoire de travail local. 19 Mars 2009
  • 4. Terminologie Branche 19 Mars 2009
  • 5. Histoires (pas drôles) de projets sans intégration continue Un projet comme on en vit tous les jours le 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 difficile Projet .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. 19 Mars 2009
  • 6. Histoires (pas drôles) de projets sans intégration continue 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é ! Nombre d’heures requises pour corriger une anomalies – à 100 es M partir du moment où elle est détectée X rc / IB u So er 3 tn 0 ar 20 20 G 15 X 15 10 5 6,5 X 0 1X s de io n n on on tio u ati t cti Et sa ra Déploiement oit al i teg u Conception Réalisation Validation od l Exploitation Ré p In -pr Ex 19 Mars 2009 é Pr
  • 7. 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.  19 Mars 2009
  • 8. 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  19 Mars 2009
  • 9. 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é. 19 Mars 2009
  • 10. 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 19 Mars 2009
  • 11. Bonnes pratiques pour la mise en place Commencer petit Mise en place de l'infrastructure, de l'intégration continue Simple mais qui fonctionne Avoir 1 ou 2 projets pilotes Permet d'affiner la plateforme et le discours Préparation à accueillir de nouveaux projets Communiquer Communiquer 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é 19 Mars 2009
  • 12. Comparatif de Apache Continuum, Hudson et Atlassian Bamboo 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 19 Mars 2009
  • 13. Comparatif de Apache Continuum, Hudson et Atlassian Bamboo 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 19 Mars 2009
  • 14. 19 Mars 2009
  • 15. 19 Mars 2009
  • 16. 19 Mars 2009
  • 17. 19 Mars 2009
  • 18. 19 Mars 2009
  • 19. 19 Mars 2009
  • 20. 19 Mars 2009
  • 21. 19 Mars 2009
  • 22. 19 Mars 2009
  • 23. 19 Mars 2009
  • 24. 19 Mars 2009
  • 25. Installation et configuration Standalone ✔ ✔ ✔ Webapp ✔ ✔ ✔ n/a Derby Postgres MySql MySql Base de données MS SQL Server MS SQL Server Oracle (en cours) Oracle Fichier XML Configuration Interface Web Interface Web Interface Web 19 Mars 2009
  • 26. Gestionnaire de sources supportés Bamboo ClearCase (plugin) ✔ ✔ ✔ CVS ✔ ✔ ✔ Git (plugin) ✔ Mercurial (plugin) ✔ ✔ ✔ Perforce (plugin) ✔ ✔ ✔ PVCS (plugin) ✔ Subversion ✔ ✔ ✔ Team Foundation (plugin) ✔ Server Visual Source Safe (plugin) ✔ ✔ 19 Mars 2009
  • 27. Types de build supportés Bamboo Ant ✔ ✔ ✔ Ligne de commande ✔ ✔ ✔ (sh ou bat) Maven ✔ ✔ ✔ NAnt (plugin) ✔ ✔ MsBuild (plugin) ✔ ✔ Rake (Ruby) (plugin) ✔ Phing (PHP) (plugin) ✔ 19 Mars 2009
  • 28. Système de notification supportés Bamboo Email ✔ ✔ ✔ Jabber ✔ ✔ ✔ MSN ✔ Nabaztag (plugin) ✔ RSS ✔ ✔ Sametime (plugin) ✔ System Tray (plugin) ✔ Twitter (plugin) ✔ 19 Mars 2009
  • 29. Notre Nabaztag 19 Mars 2009
  • 30. 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) ✔ 19 Mars 2009
  • 31. 19 Mars 2009
  • 32. 19 Mars 2009
  • 33. 19 Mars 2009
  • 34. 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 (plugin) ✔ Manager FishEye ✔ ✔ Sventon ✔ ViewCVS 19 Mars 2009 ✔
  • 35. Atlassian IDE Connector 19 Mars 2009
  • 36. Intégration de Hudson et Netbeans 19 Mars 2009
  • 37. Intégration de Hudson et JIRA 19 Mars 2009
  • 38. 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. Agent 1 Projet A Master Agent 2 Projet B Projet C Agent 3 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 19 Mars 2009
  • 39. 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 19 Mars 2009
  • 40. File fingerprint 19 Mars 2009
  • 41. Retour d'expérience sur Hudson 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 19 Mars 2009
  • 42. Retour d'expérience sur Hudson 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 19 Mars 2009
  • 43. 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) 19 Mars 2009
  • 44. Retour d'expérience sur Hudson, plugins utilisés Emma, FindBugs, Task Scanner, Warnings 19 Mars 2009
  • 45. Retour d'expérience sur Hudson, plugins utilisés Mantis 19 Mars 2009
  • 46. Retour d'expérience sur Hudson, plugins utilisés 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) 19 Mars 2009
  • 47. Retour d'expérience sur Hudson, plugins utilisés Disk Usage, pour suivre la consommation d'espace disque de chaque job 19 Mars 2009
  • 48. Retour d'expérience sur Hudson 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 19 Mars 2009
  • 49. 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é ! 19 Mars 2009
  • 50. Questions ? 19 Mars 2009

×