Expériences de refonte

Actualité ekino -

Voici deux exemples de chantiers de refonte qui montrent que, de l'autre côté du décor, les choix ne sont pas forcément les mêmes mais toujours à adapter au projet.

Article paru le :
Article paru le :

Article co-écrit avec Romain Mouillard.

Cette année encore, Ekino était présent au Symfony Live Paris 2014. Toujours aussi bien organisé autour de conférences toutes plus intéressantes les unes que les autres, nous avons choisi de retenir celle de François Zaninotto : la migration continue vers Symfony. Basée sur la refonte du site 20minutes.fr, il nous expose les méthodologies et outils employés pour migrer une application monolithique en une suite cohérente de “modules”, chacun adapté à la fonctionnalité à laquelle il doit répondre.

Nous allons ici exposer deux expériences Ekino de refonte, chacune avec des approches différentes de celle présentée par François Zaninotto.

Refonte technique de Digiposte

La première d’entre elle concerne la refonte technique de Digiposte, le service de coffre fort numérique de La Poste. Ce projet de refonte initié fin 2012 a été préparé pour une livraison progressive en plusieurs lots sur 2 ans, tout en maintenant la qualité de service. Une des particularités de ce projet est de livrer une version refondue iso-fonctionnelle, un engagement qui offre l’avantage de pouvoir prévoir et maîtriser les différents aspects de la refonte. Cependant, il nécessite également une obligation de résultat fonctionnel à l’identique tout en maintenant et en retranscrivant des concepts de développement datés vers des solutions techniques modernes.

Puisqu’il s’agit d’une refonte iso-fonctionnelle, l’aspect externe du produit demeure inchangé. Digiposte est une application faisant intervenir divers acteurs, et dispose à ce titre d’interfaces dédiées à chacun d’entre eux : site front pour les utilisateurs, extranet et web services pour les clients et interface d’administration. Côté technique, ces interfaces fonctionnent autour d’une API regroupant une partie de la logique métier et permettant l’accès aux données. Cette architecture a été jugée conforme et a donc été conservée. Cependant, dans une telle configuration d’interdépendance, la question du découpage et de l’organisation des lots de la refonte est primordiale.

Lot 1 : Modèle de données et mise en place du socle de refonte

Le modèle de données s’est naturellement placé en première place dans les lots à traiter. Il était à lui seul la principale source d’erreurs de données et de perte de performances. Peu optimisé et disposant d’un format de données non adapté basé sur du XML rendant toute évolution périlleuse, il était trop risqué d’envisager une cohabitation entre ce bagage instable et la livraison d’un lot. Sa refonte a donc été placée en tant que pré-requis à toute autre intervention sur le fonctionnement du système. La migration du modèle de données a été effectuée avec divers composants :
Une tâche de migration chargée de la transformation
Une couche DAO spécifique insérée au niveau des accès aux données dans le code de l’API.

À l’issue de la migration des données, des comparaisons de métriques entre l’ancien et le nouveau modèle ont permis de s’assurer qu’aucune donnée n’ait été perdue au cours du processus. Ces métriques concernaient la volumétrie des tables, comme le nombre d’utilisateurs, le nombre de documents, etc.

En complément de la vérification volumétrique, des scénarios de test sur l’API ont été écrits, exécutés et leurs résultats comparés entre l’utilisation de l’ancien et du nouveau modèle. La similitude des réponses entre l’exécution sur les deux versions a permis de s’assurer que le changement de la couche DAO n’avait pas impacté le comportement de l’application. Pour réaliser ces tests, un outil particulier de test et de reporting appelé Maniac a été spécialement développé. Le reporting détaillé a permis de suivre pas à pas les étapes de chaque scénario de test et de d’identifier avec précision les potentielles régressions.

maniac

La couche DAO a eu un rôle capital dans la migration de la base de données. Son rôle n’a pas seulement été de gérer la manière dont les données étaient manipulées sur le nouveau modèle. Elle se chargeait également de retranscrire ces nouvelles données à l’API dans un format identique à celui qui était obtenu par le biais de l’ancien MDD, à savoir un format à base de XML.

Des modifications ciblées ont également été ajoutées à ce premier lot pour préparer le terrain pour les prochaines livraisons, notamment en englobant tout l’ancien applicatif PHP à l’intérieur d’une couche Symfony2 afin de former un socle commun et adapté aux futurs développements.

Lot 2 : Refonte du front : site front et API à destination du front

Le deuxième lot a vu la migration d’une partie de l’API, depuis le code existant PHP vers une API réalisée en Java. Dans cette première phase de migration concernant l’API, seuls les services utilisés par l’application front ont été refondus.

L’outil de test Maniac a de nouveau été utilisé à cette étape. Des scénarios de test d’interface ont été réalisés en se basant sur le front branché sur l’API en PHP comme références. L’exécution de ces scénarios en branchant l’API Java à la place de celle en PHP a permis de s’assurer qu’aucune régression n’ait été introduite par le passage à la nouvelle version. Ainsi, le passage de l’ancienne à la nouvelle version de l’API a été maîtrisé et réalisé sans risques.

Parallèlement, le front PHP a été totalement refondu en utilisant Symfony2, exception faite de l’interface utilisant Smarty et qui est demeurée identique (pour le moment, puisqu’à l’issue de la refonte iso-fonctionnelle un projet de refonte basé sur AngularJS a été initié).

Les lots qui ont suivi ont vu les dernières parties de l’API en PHP être progressivement refondues en Java.

Bilan de la migration par lot

Un des objectifs de cette refonte, et qui était attendu par le client, était de réduire le délais nécessaire à la mise en production d’une version, qui était approximativement de 3 mois. La mise en production du premier lot a été rendue délicate en raison de la première mise en place de la nouvelle infrastructure qui accompagnait la refonte, bien que automatisée avec Puppet. Les lots suivants ont cependant été livrés sans réelles difficultés. La refonte arrive actuellement à son terme et les processus sont maîtrisés, jusqu’à permettre d’effectuer plusieurs mises en production par semaine en conservant la qualité du service Digiposte.

Le projet de refonte globale de Digiposte sera d’ailleurs le sujet d’une conférence réalisée par Thomas Rabaix au PHP Tour de Lyon le 24 juin 2014 (plus d’infos : http://afup.org/pages/phptourlyon2014/sessions.php#1101).

Second exemple de refonte

Ce second cas a concerné un grand acteur du sport français à fort trafic avec de véritables attentes en terme de fonctionnalités conjuguées à la performance : consultation et saisie d’actualités et résultats sportifs, espace personnalisé, outil d’échange pour les fans, licenciés, arbitres, gérants de clubs… Contrairement au cas précédent, cette refonte a traité le front et l’infrastructure mais le backoffice de saisie de contenus et le modèle de données business historiques ont été conservés. Ici, les développements ont été réalisés par lot mais pour une livraison finale en production 9 mois plus tard.

CMS historique vs refonte front

La première partie de la refonte a consisté en une montée de version de PHP mais aussi et surtout en des changements technologiques profonds : Symfony2, différents niveaux de cache, jobs asynchrones, SSO…
Même si le backoffice est resté le même, les données stockées ne sont pas exploitables par le nouvel applicatif front sans appliquer les routines legacy. Aussi, la construction d’une page dans ce backoffice ne tient pas compte des nouveaux besoins business, comme par exemple remonter des contenus différents au sein d’une page front.
Pour ces raisons, une couche d’interfaçage a été introduite pour que le nouveau front puisse servir les contenus. Le CMS met à disposition les données correctement formatées que le front consomme ; seules de rares actions utilisateur (like, note…) nécessitent au front d’écrire en base. Un système de taxonomie permet d’administrer les contenus à mettre en avant suivant le contexte de la page.
Enfin, ce nouveau front est entièrement conçu pour une expérience utilisateur continue sur desktop, tablette et mobile.

Infrastructure

L’infrastructure a elle aussi subit une refonte complète : anciennement un pool de 13 serveurs web en PHP4, un reverse proxy a été placé devant un Varnish pour servir de nouveaux frontaux en PHP5. Des tests de montée en charge ont démontré que ce nombre de machines pouvait être réduit de plus de 80% tout en garantissant une qualité de service équivalente, voire supérieure. Différents niveaux de cache ont également été introduits, chacun répondant à des problématiques spécifiques : caches HTTP, opcode et applicatif.
Un moniteur de processus permet le traitement asynchrone de certaines tâches comme l’envoi de mails ou toute mise à jour ne nécessitant pas de confirmation pour l’utilisateur.
Ainsi avec une meilleure maîtrise d’un bout à l’autre de la chaîne, les performances et la tenue en charge ont été améliorées.

Après 12 ans d’évolutions diverses basées sur le même socle, ce site monolithique est devenu structuré, résistant et évolutif. Grâce au découplage CMS/front, une refonte du CMS serait maintenant envisageable.

Conclusion

Simple en théorie, l’expérience montre qu’un chantier de refonte ne l’est jamais. Différentes stratégies permettent d’atteindre l’objectif. Ces deux projets réalisés par Ekino montrent des approches différentes de celle réalisée par François Zaninotto sur le site 20minutes.fr. Bien que chaque stratégie apporte son lot d’avantages, la migration continue semble être une des approches offrant le plus de contrôle sur le processus de refonte. Elle implique néanmoins une préparation méticuleuse et une planification détaillée dès ses premières étapes. Il peut s’agir d’un préalable coûteux en ressources selon l’ampleur de la refonte envisagée. Au final, l’organisation de la refonte et la problématique de sa livraison est une variable à ajuster au contexte de chaque projet.

Crédits photo : arielst0rm7

Laisser un commentaire