Axel Charpentier Responsable R&D Betclic

Présentation au sujet: "Axel Charpentier Responsable R&D Betclic"— Transcription de la présentation:

1

2 Axel Charpentier Responsable R&D Betclic
Retours d'expérience : Mise en place de TFS 2010 et utilisation des outils de développement Florent: Introduction objectifs sessions Axel Charpentier Responsable R&D Betclic Florent Santin Consultant ALM Access it IDF date

3 Présentation Betclic Créé en 2005 à Londres, BetClic fait partit d’un groupe français en forte croissance, présent dans le domaine des jeux en ligne et des paris sportifs sur Internet. BetClic est devenu en six ans seulement l’un des opérateurs les plus importants de ce secteur en Europe, avec plus de 1,5 millions de joueurs inscrits.. BetClic opère plusieurs sites dans différents pays conformément à leur législation respective Axel: Présentation Betclic Blabla blabla date

4 Contexte technique En 2 ans, de 5 développeurs à 40 Développeurs
10 Chefs de projet 15 Testeurs 8 DBA Besoin d’organisation des développements: Historiquement: TFS 2008 Contrôle de code source basique (archivage/extraction) Utilisation d’un élément de travail personnalisé Système de build externe Axel: Présentation organisation technique La DSI Betclick est organisée avec : - Pole de dev - Pole de test (QA) - Pole R&D - Pole DBA - L’IT Ops Le pole développement est organisés par projet et nom par produit, (un projet pouvant couvrir de 1 à N produit) principalement pour remonter des indicateur de cout au contrôle de gestion. -> Objectif Faire travailler tout ce petit monde ensemble le mieux possible grâce a TFS en gardant un niveau de qualité constant. date

5 Pourquoi TFS 2010? Nouvelles fonctionnalités du produit
Nouvelle organisation: méthode Agile Meilleures implication des testeurs Meilleure intégration avec Visual Studio 2010 / .NET 4.0 Axel :C’est toi qui presente ca ? date

6 Avant / après Florent: état des lieux avant intervention

7 Avant / après + + Florent: objectif intervention ?

8 Contraintes liées à la migration
Interruption de service impossible (trop d’intervenants) Cycle de projet non interruptible (corrections en production) Besoin de former les équipes avant utilisation Beaucoup d’intervenants! Florent a Axel: quelles sont les contraintes imposées pour arriver à l’objectif? Axel : Pas d’interruption de service, interruption de service pour personnes est beaucoup trop couteuse Refactoring de la structure des sources (un gros TP avec tous les sources dedans, a plusieurs TP organiser par produits) Formation sur le nouvelle structure des sources et des workspaces. date

9 Roadmap de migration Migration technique Réorganisation sources
Migration serveur TFS 2008 vers serveur collection « old » dans TFS 2010 Aucune modification sur la structure des Team Projects et du code source Le serveur TFS 2008 peut être arrêté Pas de changement d’habitudes de travail (juste nouveau serveur) Réorganisation sources Une collection « production » est créé dans TFS 2010 Les projets sont copiés depuis la dernière branche de la collection  « old » vers la collection « production » Les développeurs doivent refaire leurs espaces de travail, découvrir la nouvelle structure de sources Pas d’impact pour les chefs de projets Migration Work Items Les chefs de projets utilisent les noueaux Work Items Si requis Les chefs de projets extraient les work items dans la collection « Old » avec Excel et les réinjectent dans la collection « production » Pas d’impact pour les développeurs Peut s’effectuer chef de projet par chef de projet, sur plusieurs jours Sensibilisations testeurs Les testeurs sont sensibilités et formés aux outils de tests Microsoft Ils peuvent mettre en place les tests et les automatiser 04/10 17h Interruption de service pour devs Les développeurs sont formés à TFS 2010 et à la nouvelle structure du code source 12/10 9h Interruption de service pour devs 1 journée Les chefs de projet sont formés à la nouvelle méthode et à l’utilisation des nouveaux Work Items 19/10 9h Pas d’interruption de service Florent: Présentation de la roadmap, brique par brique Slide volontairement illisible: objectif, faire apparaitre les différentes briques Migration technique: dissocier la migration de la réorganisation Pas d’interruption de service date

10 Retour d’experience: contrôle de code source
Migration technique: Migration vers Visual Studio 2010 / .NET 3.5! Installation du serveur Migration des sources TFS dans une nouvelle collection de TFS 2010 Arrêt de l’ancien serveur Migration et restructuration des projets un à un par les leaders techniques Florent: Concrètement, comment est ce que cela s’est passé Très bien, aucun problème techniques tous les éléments de TFS 2008 ont été correctement migrés dans 2010 (aucune erreur) Afin d’honorer de faciliter la migration et eviter l’interruption de services des choix sur la migration ont du être fait : Pas de migration de l’historique de sources Migration de tout le contenu des TFS 2008 dans une collection Archive dans 2010 et mise en stand by de l’ancien serveur (au cas ou) Pas de migration automatique de WI, car changement total de structure (passage de full custom a MSF Agile) -> Gros risque, car transformation lourde, choix du passage a la nouvelle gestion de projet avec le nouveau WI après une Release pre-determinée./ date

11 Retour d’experience: Contrôle de code source
Impact après migration: Travail sur contrôle de code source: stratégie de branching, tests unitaires, couverture de code Builds: Plus difficiles à mettre en œuvre dans le contexte, nécessite un travail en plein temps sur un contexte comme Betclic Points positifs: CodeUI Test, prise en main très rapide Gated-Checkin Axel: ce que nous avons encore à faire Gros travail sur la stratégie de branching, il est fondamental de bien la penser pour adresser le maximum de cas, bien sur il cette stratégie est en fonction de la manière dont chaque société gère le cycle de vie de ses produits Build dans 2010 TeamBuild est un outils dont les fonctionnalités sont extrêmement riches et permet de faire tout ce qu’on veut sans imposer de limite, dommage que la réalisation pèche un peu, l’éditeur de WF de build reste assez fastidieux. Clairement dans le contexte d’un gros SI, un ressources dédié a la customisation de TFS est quasiment indispensable. date

12 Retour d’experience: Gestion de projet
Beaucoup d’interrogation au niveau du management: Utilisation de TFS comme outil de gestion de portefeuille de projets != outil de suivi des développement Importance du découpage en projets VS produit Mise en place du produit au travers du changement de process: vers l’agilité Florent + Axel: echanges sur TFS pour la gestion de projet Axel: retour d’experience sur le découpage projet vs produit: importance du team project! - Dans le cas de Betclick illustrer la problématique Produit/projet et comment on l’a adressée = Un TP dedié aux artefact projet avec une gestion des Area pour matérialiser les projets. - TFS n’est pas un outils de gestion de portefeuille de projet, il ne gère pas en natif les phase de conception et de definition du besoin, TFS seul n’est donc pas suffisant pour piloter un projet dans son ensemble (On explore des pistes : Sharepoint/Project Serveur) date

13 Retour d’experience: Gestion de projet
Les points positifs: Les éléments de travail liés Reports natifs de gestion de projet « A chacun son outil » Les points négatifs: Pas de DashBoard natif multi projets d’équipes Amalgame entre un outils de PPM et de suivie du dev Florent a Axel: si on doit résumer en points positifs et négatifs? Positif : TFS est un outils formidable permettant de créer un vrai usine logicielle de bout en bout (du codage a la release) Beaucoup de fonctionnalités fournit « out of the box » (trop d’ailleurs) Extensibilité très simple avec les API TFS Intégration des outils de test dans le processus projet (tests unitaires, tests fonctionnelles automatisés, test de charge….) Négatif : Pas de cockpit de pilotage multi TemProject permettant d’aggreger des indicateurs sur plusieurs projets (même si ca reste faisable un modifiant les rapports) que ca soit a destination de CP ou du Release Management. Trop de fonctionnalité « out of the box » on a tendance a croire que TFS n’a pas besoin de customisation, c’est faux TFS ne peut répondre à toutes les problématiques en particulier sur la gestion de projet. Pour mettre en place toutes l’usine logicielle (Agent de build, Agent de Test Labs…) le cout est beaucoup plus élevé que la simple licence date

14 Chantiers à venir… Chaine de Build complète
Des développements aux portes de la production Tests, tests et tests Labs Management: en cours d’étude Chantier en agilité qui continue… Florent a Axel: que reste t il a faire, quelle est votre roadmap Continuer à mettre en place tous les types de build (Nightly/Integration/Deploiment ect….) incluant MSDeploy et différente métriques de code (TU, Code coverage…) Mise en place des labs et des tests fonctionnelles auto (CodedUITest) Modification des rapports pour la gestion de projet Cockpit de pilotage pour le Release Management date

15 Conclusion Déjà 6 mois d’écoulés, le travail continu
Très bon outil mais, dans un contexte de SI important: Le vrai travail débute « après » l’installation du produit… … mais quasiment tout les scénarios de personnalisation sont couverts Une mise en place par étape est recommandée! Axel conclu sur le premier bloc Florent rappel d’y aller par étape date

16 Utilisation des outils de développement
09/02/2011 Karine GUERIN Unit manager Hotel IT Amadeus Depuis 11 ans dans le developpement logiciel, d’abord pour l’industrie spatiale pour le CNES et Alcatel space. Depuis 4 ans chez amadeus, dans la division hotel IT reponsable d’une equipe qui developpement base exclusivement sur des technologies microsoft. But de la presentation : retour d’experience sur les technos et ouitls , influence sur l’organisation de l’equipe et le cycle de developpement, detail sur la collaboration entre designer et developer. Transition : l’agenda

17 Agenda Présentation d’Amadeus Le projet Le cycle de développement
Implémentation de Kanban Conclusion Presentation Amadeus Quelques mots sur l’historique du projet et l’organisation de l’equipe, les outils utilises cyle de developemtn maintenant consolide apres 3 ans et demie et evolution vers la formalisation de ce cycle avec une methode agile : Kanban

18 Compagnie cree en 1987 et aujourd’hui:numero 1 des GDS dans le monde : GDS : global distribution system. Centralisation des offres de produits de voyage et de tourisme et distribution sur les canaux de vente : agence de voyages, site internet (opodao, expedia, site de compagnies aeriennes). Societe cosmopolite, bureau commerciaux partout dans le monde, siege social a Madrid, centre de production en Allemagne a Erding, Centre de developpement a Nice, Toronto, sydney … Amadeus en quelques chiffres : Plus de employee dans le monde 677 milions de de transactions en 2009 500 copagnies aeriennes, 95% de la capacite mondiale hotel 4000 personnes sur le centre de development a Nice Distribution + Valeur ajoute : calcul de routes (direct ou reaccomodation), de tarifs. Distribution activite traditionnelle d’Amadeus sur mainframe a ses debuts, maintenant C++ sur linux. Depuis les annees 2000, se potionne dans lIT dans l’industrie du voyage et du tourisme IT dans l’industrie du voyage = gestion d’inventaire , centrales de reservations dans l’industrie aeriene, hoteliere. IT => autres technologies et se positionne comme acteur technologique se positionnant sur des technologies plus innovantes Le projet Amadeus Hotel Call center fait partie de l’offre centralisee de 1a pour l’industrie hoteliere : CRS + PMS + IBE + Call Center + canaux de disctribution classique. Transition : hotel IT call center date 18

19 Le projet , l’équipe, les outils
Création de l’équipe fin 2007, technologies pilotes dans 1A, autonomie complète Outillage Visual Studio 2008/2010 Expression Blend 3 TFS 2008/2010 ClickOnce Creation de l’equipe en 2007, techno pilote dans 1A, aucune competence .net ou microsoft Obligation de resultat => preuve Autonomie “pas de support des equipes de prod Exister au sein d’une organisation a forte culture C++, java et linux => Equipe en charge des etudes fonctionnelles et graphiques, developpement, gestion de configuration, gestion des deployment en production Outillage . Depuis : 1iere version winform + windows workflow (4 mois en prod) foundation, activite = fonctionnalite pour creer des flows customise => architecture par composant pour construire une application custom ensuite WPF + CAB, PRISM. Migration successful. Transition : apres toutes les phases, presentation de l’architecture actuelle

20 L’architecture Architecture orientee composant : chargement de modules fonctionnels en fonction de qui est necessaire pour la chaine implementee : ex profile + Pas de dependences statiques entre les modules 1 module est compose de vue en WPF, use case fonctionnel et d’une couche de communication en WCF qui permet une connection en http aux serveurs Amadeus, le tout articule par PRISM Pas dependances statiques entre les couches, MVVM +translator VOM-BOM BOM-message TRANSITION : architecture decouplee qui permet de decoupler egalement les activies dans l’equipe

21 Le cycle de développement
Cycle de développement classique Analyse fonctionnelle Etude graphique Implémentation collaborative Tests fonctionnels et graphiques Detail du flow iteratif graphique puis illustration avec les mockups

22 Low fi

23 First implementation : seulement Visula studio
Limiter la generation de code

24 Second implementation
Visual studio + blend Integration directe du xaml Contact reservation : grid tranformee en label fait par blend Changement de position : workspace WPF preparee par le developeur

25 Sejours : tab to combox box fait dans blend , visual studio pour ajustement
Tranformations des boutons avec Blend

26 Le cycle de développement
Spécialistes fonctionnels et techniques recentrés sur le domaine de compétence mais en étroite collaboration Convergence rapide vers les solutions graphiques avec maitrise des couts Qualité et prédictibilité Element essentiel : sepcialistes …. Qui permet convergence …. Et augmentation de la productivite + qualite et predictibilite Transition : techno => decouplage technique => decouplage fonctionnel => outillage = agilite

27 Implémentation de Kanban
Agilité et réactivité naturellement induite par l’outillage Cycle de développement mature => Choix de Kanban Utilisation de Visual WIP, tableau Kanban pour TFS : en cours, principalement pour automatiser le calcul des métriques Specificite technique => specificitte organisationnelle Optimiser encore plus Interrogation et agilite naturelle Limiter le changement => Kanban, appuie sur le processus existant, pas d’iteration, amelioration continue Apport de Kanban : formalisation du process atypique chez 1A, visibilite car 3 metiers dans la meme equipe, autonomie, possibilite de mesurer donc d’amaeliorer

28 Tableau Kanban

29 Conclusion Outillage sophistiqué et pertinent => cycle intrinsèquement agile Equipe réactive, concentrée sur son cœur de métier et très motivée Fonctionnalités denses, étude précise pour choisir ce qui est utile et rentable Prochaines étapes : Finalisation de l’implémentation de Kanban Exploitation de la suite 2010 Partage des composant avec une application legacy Ajouter photo du Kanban board

30 Ressources Des questions ?
Retrouvez-nous au Village Dév sur les stands W10 / W11 / W12 ! Visual Studio France Abonnements MSDN Groupe Facebook Visual Studio en France

31 MSDN et TechNet : l’essentiel des ressources techniques à portée de clic
Portail administration et infrastructure pour informaticiens Portail de ressources technique pour développeurs

32