Téléchargé 20 fois
Téléchargé parOlivier NOEL
Migration de technologie J2EE vers PHP à M6Web
Le document présente un retour d'expérience sur la migration des technologies J2EE vers PHP par M6Web, une filiale du groupe M6, incluant l'évolution des équipes et de l'architecture entre 2007 et 2009. Les avantages de PHP tels que la flexibilité, le coût réduit et la facilité de recrutement sont mis en avant, tout comme l'importance d'un framework pour la maîtrise du code et la sécurité. La conclusion souligne une amélioration des performances et une réduction des coûts dans les projets grâce à cette migration.
Contenu connexe
Migration de technologie J2EE vers PHP à M6Web
- 1. MIGRATION DE TECHNOLOGIE J2EEVERS PHP Retour d’expérience
- 2. QUI SOMMES-NOUS ? • M6Web : filiale du groupe M6 • Ludovic BOSTRAL • responsable des Etudes & Développements Vidéo et Mobile • Olivier NOEL • architecte des solutions M6.fr actuellement en ligne • en charge des projets techniques mobiles et nouveaux écrans • Judicaël PAQUET • architecte du CMS Video (M6Replay, M6Bonus, M6VOD, ...) • Mais aussi • Richard DOS ANJOS : responsable des études et développements pour AcheterFacile.com et ses déclinaisons • Kenny DITS : responsable des études et développements pour les sites éditoriaux (Clubic, JVFR, mais aussi W9 et M6 bientôt)
- 3. ORGANISATION Sites de chaînes Thématiques Direction technique Pôle E&D, exploitation, studio M6Mobile Jeux
- 4. SITUATION AVANT SEPT2007 • Equipes • chefs de projets techniques et fonctionnels • 1 intégrateur et 2 développeurs (environnement PHP4) • Projets externalisés au forfait sous CMS Java (Jalios CMS) ou PHP (EzPublish) • Architecture d’exploitation N-Tiers infogérée par un prestataire • frontaux Apache • Base de donnée MySQL4, Oracle 8 et 9 • Middle Apache Tomcat et ATG • La plupart des sites de programmes réalisés par les webmasters
- 5. EVOLUTION APRÈS SEPT2007 • 2007 • premier projet réalisés avec Smarty (templating PHP) réalisé en octobre 2007 • 1ère version du CMS maison M6WebPortal sur le site de l’émission TopModel • 2008 • 2ème version du CMS M6WebPortal pour l’industrialisation des sites de programmes • Pekin Express, • Un diner presque parfait, • Prison Break • Rachat du groupe Cyréalis en mars 2008 • Fin 2ème semestre : démarrage du projet de refonte du portail m6.fr sur une nouvelle architecture applicative et exploitation
- 6. BILAN ANNÉE 2008 • Mise en production portail m6.fr en avril • Tous les projets sont développés en PHP : même Nouvelle Star • Equipes • 2 architectes, • environ 15 développeurs, • 3 responsables d’études et développements • Fin 2009 - début 2010 : • fusion des équipes à Paris et Lyon • Fusion des CMS : un seul CMS utilisé pour tout M6Web • basé sur le CMS historique de ex-Cyréalis, • des best-pratices de m6.fr • de l’intégration du CMS Vidéo
- 7. PROBLÉMATIQUES MÉTIERS • Contrainte marketing, produit mais également juridique • Charge • Quelques milliards de PV / mois • Non constante avec phénomène de vague • Pic de charge en quelques secondes (ex fin Nouvelle Star)
- 8. ARCHITECTURE • Logicielle : MVC Orienté Objet - ultra modulaire pour les 2 applications • Vidéos • Site Factory • Exploitation : architecture LAMP standard et géré par un cache interne
- 9. APPLICATIONS PRÉSENTES • Site factory • CMS • Gestionnaire de portails (architecture de l’information) • Vidéo • CMS spécialisé dans la gestion des vidéos • Uniquement par Webservice • Cibles • Catchup (M6Replay), • Web (M6Bonus, M6VOD), • IPTV (SFR Replay) • Interconnexion entre deux applications grâce à des flux normés en XRSS • norme définie par J PAQUET et basée sur le RSS
- 10. ORGANISATION GLOBALE Développeurs juniors n Modèles n Vues Intégrateur XHTML Développeurs n Contrôleurs spécifiques Séniors et Contrôleur général architecte Kernel
- 11. PROCESSUS • Processus de développement • SVN • Convention de codage • Normalisation • Processus projet • mise en place d’étape de validation • procédure de mise en production • Processus en constante amélioration et évolution
- 12. POURQUOI LE PHP? • Développements agiles et flexibles • Infrastructures moins couteuses (vs licence des serveurs applicatifs) • Documentation complète et communauté plus importante • Coût des équipes (dev Java vs dev LAMP)
- 13. POURQUOI UN FRAMEWORK •Maitrise • Globale du code • Surcharge et évolution plus facile et mieux maitrisées • Optimiser et répondant aux contraintes métiers • Sécurité • Indépendance vis à vis des failles • Pas d’attente de mises à jour • Facilité de recrutement : seul critère le PHP
- 14. CONCLUSION • Baisse • coûts globaux dans les projets • de TMA • des temps de développements • Internalisation => contrôle total • Hausse conséquente • QoS • Performances techniques (charge d’exploitation, ...) • Rendement global (financier, humain, ...)
- 15. OBJECTIFS 2010 • Fusion • des équipes dans la continuité de fin 2009 • des savoir faire • Internalisation de la mobilité (sites mobiles) • Travail sur les nouveaux écrans (TV connectées, IPTV, ....) • Uniformisation du parc de portails sur la SiteFactory de 15 Portails
- 16.