Obsolescence d'une plateforme

Présentation réalisée à l'AFUP Lyon sur la gestion de l'obsolescence d'une plateforme technique

Transcript

1. AFUP-Lyon 25/03/2018 L’obsolescence d’une plateforme Guillaume Thirard Étude de cas : TCL.fr
2. Qui suis-je ? ❖ Guillaume Thirard ❖ Expert technique chez Micropole - Lyon ❖ @Melfo01
3. Contexte ❖ On travaille pour des clients pendant plusieurs années ❖ Durant lesquelles les projets évoluent avec des corrections et évolutions ❖ Ce qui génère naturellement une dette technique.
4. Le cas de TCL.FR ❖ 2ème site le plus visité de la région ❖ En moyenne : 50 000 visiteurs / jour ❖ Des pics de connexion : ❖ En journée : 07h30 - 09h00 et 17h00 - 19h00 ❖ Problème sur le réseau : 150 000 visiteurs / jour ❖ 5 langues ( fr, en, es, it, de)
5. Le cas de TCL.FR ❖ Quelques fonctionnalités : ❖ Recherches d’itinéraires ❖ Horaire à l’arrêt - Temps réel ❖ Alertes trafics ❖ Paiement des PV ❖ Demandes d’attestations ❖ …
6. Le site TCL.fr
7. Rapport d’obsolescence ❖ Alerter le client sur le vieillissement de sa plateforme : ❖ Architecture serveurs : Versions des logiciels utilisés, Nombre de serveurs, … ❖ Architecture logiciels : Mise à jour CMS, librairies utilisées, … ❖ Communication avec d’autres plateformes : Certificat mobiles, …
8. Rapport d’obsolescence ❖ Faire des préconisations ❖ Ajouter de la valeur ajoutée grâce à de nouveaux cas d’usage ❖ Nouvelles technologies permettant d’améliorer des développements anciens ❖ Budget
9. 1ère étape : Documenter ❖ Récupérer les configurations de tous les logiciels ❖ Référencer : ❖ les packages installés (extensions PHP, Vhost, Config Varnish / Nginx /…) ❖ les différents développements ❖ l’architecture serveurs, les environnements, … ❖ les flux réseau
10. 2nde étape : Construire ❖ Définir l’architecture cible (Logiciel + Serveur) ❖ Créer la nouvelle architecture serveur ❖ Mettre à jour des outils de développement / déploiement / … ❖ Automatiser le plus de choses possible
11. 3ème étape : Tester ❖ Tester la plateforme - tests unitaires / fonctionnels ou à la main ❖ Créer un cahier de recette complet du site internet ❖ Tester la communication avec tous les outils tiers ❖ Tester la performance de la plateforme avec des tests de montée en charge
12. 4ème étape : Basculer ❖ Mettre en place une procédure de bascule avec les rôles de chaque acteur ❖ Etablir les risques (coupure / rollback / perte de données / …) ❖ Tester en amont toutes les étapes pour mettre des temps sur chacune afin d’avoir une roadmap définie ❖ Réaliser la bascule le Jour J en croisant les doigts
13. Conclusion ❖ Pouvoir continuer à faire des mises à jour ❖ Travailler avec de nouvelles technologies ❖ Ajouter de la valeur ajoutée aux contributeurs ❖ Sécuriser les mises en ligne grâce au déploiement continu
14. Merci On en discute ?