At2008 Grenoble Hugonnet Sanlaville Public
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

At2008 Grenoble Hugonnet Sanlaville Public

on

  • 1,770 views

Orange Labs - Retour d'expérience Agile Tour 2008

Orange Labs - Retour d'expérience Agile Tour 2008

Statistics

Views

Total Views
1,770
Views on SlideShare
1,768
Embed Views
2

Actions

Likes
0
Downloads
45
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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

At2008 Grenoble Hugonnet Sanlaville Public Presentation Transcript

  • 1. Mise en place d'outils d'ingénierie logicielle pour industrialiser le développement Agile chez Orange Labs Emmanuel Hugonnet Architecture J2EE Silverpeas [email_address] +33-(0)476248658 Rémy Sanlaville Expert Senior en Ingénierie Logicielle   Orange Labs [email_address]
  • 2. Introduction
  • 3. Pourquoi des outils d’ingénierie logicielle à Orange Labs Services 2006 1982 Infrastructure 2001 1994 1988 Professionnalisation du développement pour offrir des services reconnus et de qualité 
  • 4. Outils d’ingénierie logicielle et agilité ?
  • 5. Outils d’ingénierie logicielle et agilité ?
    • L’humain est au premier plan mais il a besoin d’outils pour réaliser au mieux ses tâches.
      • Les outils ne sont qu’un moyen et pas un but
      • Les outils pour une démarche d’amélioration continue
  • 6. Build
  • 7. Build - Définition Le build peut aller de la compilation (incrémentale) à la génération d’un package en passant par la génération de fichiers de source, le lancement de tests (unitaires, d’intégration…), l’analyse du code source, la génération d’un site web et de rapports… D’une certaine manière, le build englobe l’ensemble des actions souhaitées prenant en entrée des fichiers sources pour produire un résultat souhaité. Généralement, nous attendons d’un outil de build qu’il puisse automatiser et optimiser ces actions. Pas de définition précise…
  • 8. Build - Problématique
    • Reproductibilité dans le temps et dans l’espace (sans modification du source…)
    Il faut aussi définir ce que veut dire identique… Les builds aux temps t0, t1, ti… doivent être identiques Par exemple, il faut pouvoir à tout moment reproduire le build d’une version taggée Les builds sur les postes p0, p1, pj, pic… doivent être identiques Par exemple, il faut pouvoir reproduire le build sur l’ensemble des postes de l’équipe, du serveur d’intégration continue… dans le temps t1 ti t0 p0 dans l’espace p1 pj pic
  • 9. Build - Problématique
    • Reproductibilité dans le temps et dans l’espace (sans modification du source…)
    Cela paraît simple mais dans les faits c’est une problématique compliquée et nous ne disposons toujours pas de solution qui permette d’assurer cela… Qu’est-ce qui influence le build ? … artefacts build Dépendances Outils de build options de compilation compilateur… Plateforme d’exécution OS Variables d’environnement Fichiers sources code source ressources Facteurs humains Ressources externes xml schéma… wsdl Repositories maven Base de données…
  • 10. Build – Pourquoi Maven 2 ? Les fichiers sources du projet Les fichiers générés du projet Le fichier de description du projet (POM) code source java tests unitaires Conventions plutôt que configuration Standardisation du système de fichiers Facilite le passage d’un projet à un autre, la communication…
  • 11. Build – Pourquoi Maven 2 ? Conventions plutôt que configuration Standardisation du système de fichiers Standardisation du cycle de vie Facilite le passage d’un projet à un autre, la communication…
  • 12. Build – Pourquoi Maven 2 ? Conventions plutôt que configuration Standardisation du système de fichiers Standardisation du cycle de vie Standardisation du site web du projet ... Facilite le passage d’un projet à un autre, la communication…
  • 13. Build – Pourquoi Maven 2 ? Maven suit une approche déclarative et se focalise sur une abstraction de haut niveau du projet appelé le Project Object Model (POM). Un conducteur n'a pas à connaître la mécanique de sa voiture pour conduire Modélisation du build Modélisation vs scripting décrivez ce que vous voulez faire (le quoi) pas le comment ! POM
  • 14. Build – Pourquoi Maven 2 ? Problématique complexe et qui n’est pas toujours bien maîtrisée voir abordée => le changement de version d’une dépendance directe peut devenir une tâche complexe. Maven 2 apporte une aide précieuse même s’il ne résout pas tous les problèmes Graphe de dépendances du plugin scmchangelog-maven-plugin Gestion des dépendances
  • 15. Build – Pourquoi Maven 2 ? … Repositories Release, Snasphot … Automatise la récupération des dépendances, facilite l’intégration continue (les dernières versions sont tout de suite disponibles)… Réutilisation Plugins Template de projet (archétypes) … Améliore la productivité, mise en place de recommandations d’entreprise…
  • 16. Build – Plateforme Maven 2 à Orange Labs Central Central snapshot Codehaus … pom.xml <project> </project> <repository> <id>codehaus</id> <name>codehaus repository</name> <url>http://repository.codehaus.org/</url> </repository> <repositories> <repository> <id>apache.snapshot</id> <name>apache.snapshot repository</name> <url>http://people.apache.org/maven-snapshot-repository/</url> </repository> </repositories> […] […]
  • 17. Build – Plateforme Maven 2 à Orange Labs Central Central snapshot Codehaus … <parent> <groupId>com.francetelecom</groupId> <artifactId>corporate</artifactId> <version>1.4</version> </parent> […] Proxy Maven 2 pom.xml <project> </project> Central setting.xml <settings> <mirrors> <mirror> <id>FranceTelecomMaven2Proxy</id> <mirrorOf>central</mirrorOf> <name>France Telecom Maven2 repositories</name> <url>https://maven2.rd.francetelecom.fr/proxy/</url> </mirror> </mirrors> […] </settings> Central snapshot Codehaus … inhouse inhouse snapshot
  • 18. Build – Plateforme Maven 2 à Orange Labs
  • 19. Build – Plateforme Maven 2 à Orange Labs
  • 20. Build – Plateforme Maven 2 à Orange Labs
  • 21. Build – Plateforme Maven 2 à Orange Labs
  • 22. Build – Plateforme Maven 2 à Orange Labs
  • 23. Build – Plateforme Maven 2 à Orange Labs
  • 24. Build – Plateforme Maven 2 à Orange Labs
  • 25. Build – Bilan
    • Maven 2
      • On a toujours réussi à mettre en place le processus build même pour des contextes très complexes
      • Adoption de plus en plus forte de Maven 2 au sein de France Télécom. Les utilisateurs de Maven 2 ne souhaitent pas revenir en arrière
      • Site web du projet à jour (généré par le serveur d'intégration continue)
      • Bonnes pratiques plus facile à divulguer (pom, archetypes…)
    • Plate-forme Maven 2 du Groupe France Télécom
      • Industrialisation réussie : proxy Maven 2, site web, forum actif, support en place…
      • Utilisation quotidienne par de nombreux projets
      • Pas de soucis particuliers (montée en charge, disponibilité… ) juste des demandes d'évolution
      • Devenu une recommandation au niveau Groupe
    Utilisation de la plate-forme Maven 2 sur plusieurs projets industriels et avec de nombreuses technologies (Java/ J2EE, JMS, Web Services, Castor, SSO, IMS, SIP, Osgi, Smart Environment…) Aspects positifs :
  • 26. Build – Bilan Difficultés rencontrés :
    • Maven 2
      • Documentation pas toujours suffisante
      • Tests d'intégration pas bien pris en compte avec Maven 2.0.x
      • Gestion des projets multi-modules (release, site web)
      • Intégration avec Eclipse (difficulté de synchronisation, problème de reproductibilité…)
      • Philosophie et manière de travailler pas toujours bien comprises/acceptées (problème plutôt humain que technique)
    • Plate-forme Maven 2 de France Télécom
      • Industrialisation de Maven 2 : on est parti de zéro sans référence dans le domaine (architecture physique, sauvegarde, proxy Maven 2, contrôle d'accès pour le déploiement, site web codex, support…)
      • Conflits d'intérêt : vision projet (vision locale) vs cohérence de la plate-forme (vision globale)
      • Problématique liée à l'évolution de la plate-forme (assurer la compatibilité ascendante)
      • Ouverture de la plate-forme pour les sociétés externes (Propriété Intellectuelle)
    Utilisation de la plate-forme Maven 2 sur plusieurs projets importants et avec de nombreuses technologies (Java/ J2EE, JMS, Web Services, Castor, SSO, IMS, SIP, Osgi, Smart Environment…)
  • 27. Intégration Continue
  • 28. L’Intégration Continue … une pratique de développement logiciel où les membres d’une équipe intègrent leur travail fréquemment, habituellement chacun au moins une fois par jour – ce qui entraine plusieurs intégrations par jour. Chaque intégration est validée par un ‘build’ automatique (ce qui inclut les tests) pour détecter les erreurs d’intégration aussi vite que possible ... http://www.martinfowler.com/articles/continuousIntegration.html Martin Fowler
  • 29. Intégration Continue - Problématique Source: http://www.agitar.com/solutions/why_unit_testing.html Les 5% de bugs découverts après la release représentent 95% des coûts de correction Module1 Module2 Modulei Développement Intégration
  • 30. Intégration Continue - Problématique Les 5% de bugs découverts après la release représentent 95% des coûts de correction Détecter au plus tôt les problèmes pour les corriger au plus tôt Module1 Module2 Modulei Développement Intégration Intégration Continue Module1 Module2 Modulei Intégration Intégration Développement Intégration Intégration Intégration Intégration
  • 31. Intégration Continue - Les enjeux
    • Corriger les bugs au plus tôt S’assurer que l’intégration de code ‘nouveau’ ne casse pas le composant logiciel.
    • Améliorer la qualité du code et la cohérence de l’équipe Toute l’équipe avance en parallèle et chacun suit les apports des autres.
    • Voir en ‘temps réel’ l’état du projet En produisant des rapports et en les diffusant à chaque ‘commit’ toute l’équipe peut suivre l’état d’avancement du projet.
    • Avoir un logiciel prêt à être déployé Obtenir des ‘builds’ répétables et reproductibles dans le temps et l’espace.
  • 32. Intégration Continue - Concepts Evènements de déclenchement SCM
    • Modifications au niveau du gestionnaire de configuration (SCM)
      • le SCM est scruté périodiquement par le serveur d'IC (&quot;polling&quot; )
      • le serveur d'IC attend un évènement envoyé par le SC
    Intervention humaine sur le serveur d'intégration continue (IC) Périodiquement En cascade (le build d'un projet lance le build d'un ou plusieurs autres projets) API Distante (Web Service, Jabber...)
  • 33. Intégration Continue - Concepts Appel d’actions Evènements de déclenchement Outils de build Outils de build (Ant, Maven 1, Maven 2…) Scripts shell, bash
  • 34. Intégration Continue - Concepts Appel d’actions Evènements de déclenchement Rapports Artéfacts Notifications Comment : Mail, Messagerie instantanée, Flux RSS, Widgets, …
  • 35. Intégration Continue - Concepts Comment : Mail, Messagerie instantanée, Flux RSS, Widgets, … Qui : Liste de destinataires, plusieurs listes possibles; le(s) dernier(s) comiters Appel d’actions Evènements de déclenchement Quand : Systématiquement après chaque build, Conditionnel (échec, qualité de code…) Rapports Artéfacts Notifications
  • 36. Intégration Continue - Concepts Appel d’actions * Evènements de déclenchement Rapports Artéfacts Notifications
  • 37. Intégration Continue - Workflow Développeur checkout, update Intégration Continue construit déploie teste analyse informe Rapports Artéfacts Notifications développe teste compile Outils de build checkout, commit, update, merge SCM
  • 38. Intégration Continue - Problématique
    • Problématique : améliorer la productivité des développeurs
    2' 4' 1' 10' x' compilation tests unitaires packaging site web 8' tests d'intégration … 2' 4' 1' 10' x' compilation tests unitaires packaging site web 8' tests d'intégration … 2' 4' 1' 10' x' compilation tests unitaires packaging site web 8' tests d'intégration … x 40 x 20 x 1 x 0 x 0 x … x 25 x 25 x 1 x 1 x 2 x … x 45 x 10 x 1 x 0 x 0 x … 2' 4' 1' 10' x' compilation tests unitaires packaging site web 8' tests d'intégration … 2' 4' 1' 10' x' compilation tests unitaires packaging site web 8' tests d'intégration … 2' 4' 1' 10' x' compilation tests unitaires packaging site web 8' tests d'intégration … x 30 x 15 x 5 x 2 x 2 x … x 20 x 20 x 3 x 1 x 4 x … x 35 x 5 x 5 x 0 x 0 x … 2' 4' 1' 10' x' compilation tests unitaires packaging site web 8' tests d'intégration … x 20 x 20 x 15 x 2 x 15 x … Intégration Continue
  • 39. Intégration Continue à Orange Labs
    • Objectifs
      • Choix d'un serveur d'intégration continue à recommander
      • Mise en place de bonnes pratiques ainsi qu'un support
      • Mise en pratique sur les projets
      • Faciliter la mise en place d'un serveur d'intégration continue dès le lancement du projet
  • 40. Intégration Continue à Orange Labs
    • Choix d'un serveur d'intégration continue
      • Réalisation d'une grille d'évaluation
      • Audits de 10 projets pour remplir la grille et pour identifier les différentes pratiques
    Hudson
  • 41. Intégration Continue à Orange Labs
    • Assurer la traçabilité
      • Lancer le build à chaque modification du SCM pour savoir quel est le commit qui a posé problème
      • Commiter très fréquemment (une modification = un commit) pour identifier quelle modification, quel(s) fichier(s) sont à l'origine du problème
      • Disposer de builds rapides (max 15 minutes)
      • Disposer d'un serveur puissant : gains partagés par l’ensemble de l’équipe
    • Assurer la reproductibilité
      • La référence est la machine d’intégration : plus de « ça marche chez moi » !!!
      • Mise en place d'un &quot; Nightly Build&quot; qui repart de zéro (checkout complet du SCM, suppression du repository local de maven 2…)
    • Avoir le souci du produit fini
      • Valoriser les rapports et intégrer la qualité dans la notion de &quot;terminé&quot;
      • Artéfacts prêts à être déployés et validés sur l(es)'environnement(s) cible(s)
      • Disposer d'une version de démonstration la plus à jour possible
    Bonnes pratiques
  • 42. Orange Labs - Recherche & Développement - titre de la présentation – date Retour Projets
  • 43. Retour d'expériences – Améliorer la qualité
    • Détecter les problèmes au plus tôt pour les corriger au plus tôt
    • Améliorer la qualité
  • 44. Retour d'expériences – Améliorer la qualité
  • 45. Retour d'expériences – Améliorer la qualité
  • 46. Retour d'expériences - Documentation à jour
  • 47. Retour d'expériences - Documentation à jour
  • 48. Retour d'expériences - Documentation à jour
  • 49. Bilan et Perspectives
  • 50. Bilan - Agilité On passe de la compilation continue à l’exécution continue vers la production continue Manifesto for Agile Software Development
    • Automatisation des tâches répétitives
    Individuals and interactions over processes and tools
    • Le logiciel est bien validé et testé en exécution
    Working software over comprehensive documentation
    • Transparence et visibilité : des rapports visibles par tous
    Customer collaboration over contract negotiation
    • Intégration continue des changements en réduisant les risques
    Responding to change over following a plan
    • La qualité est traitée comme un élément à part entière
    Craftmanship over Execution
  • 51. Bilan – Oranges Labs
    • Industrialisation d’outils d’ingénierie logicielle (build, intégration continue, gestion de configuration…) réussie
    • Recommandation au niveau du groupe France Télécom (Orange Labs, ROSI, Orange Business Services…)
    • Mise en place de bonnes pratiques qui sont suivies et qui ont une influence bénéfique sur les projets
    • Les projets sont demandeurs pour utiliser ce qui a été mis en place et souhaitent aller plus loin
    • Initialisation d'une chaîne globale d’outils d’ingénierie logicielle 1 outil + 1 outil > 2 outils
    • L’ingénierie logicielle rentre dans la culture d’entreprise
    Aspects positifs
  • 52. Bilan – Oranges Labs
    • Beaucoup de travaux à mener en parallèle et à coordonner (Build, Intégration Continue, Analyse statique de code, Gestion de configuration, Virtualisation, Tests, Gestion des exigences….)
    • Certains sujets comme les rapports/métriques sont difficiles à conceptualiser et demandent beaucoup de temps et d’expériences
    • Industrialiser un outil demande un travail important et beaucoup de compétences
    • Prise en compte de l’ensemble des contraintes du groupe France Télécom
    Difficultés rencontrés
  • 53. Perspectives Développeur Outils de build Intégration Continue Configurations optimisées pour les tâches d'intégration packaging, tests d'intégration, métriques, site web du projet… Configurations optimisées pour les tâches du développeur hot-deploy, tests unitaires, analyse statique de code… SCM Commit par issue Tracker
  • 54. Perspectives Développeur Intégration Continue SCM Tracker Outils de build le SCM est utilisé comme simple support d'archivage. Le projet n'est pas dans un état stable et ceci est la dernière préoccupation des développeurs. les échecs sont immédiatement corrigés, commits fréquents. http://www.agile-swiss.org/wiki/index.php?title=Integration_continue Mise en place de sondes/capteurs Prévenir plutôt que guérir Est-ce que les développeurs commits régulièrement ?
  • 55. Perspectives Développeur Intégration Continue SCM Tracker Outils de build Mise en place de sondes/capteurs Prévenir plutôt que guérir
  • 56. Perspectives Mise en place d'un tableau de bord projet Maîtrise de son projet avancement, qualité… Développeur Intégration Continue SCM Tracker Outils de build
  • 57. Oui c’est possible !!!
  • 58. Questions?