Les migrations techniques

Suite au changement d’hébergeur du site familial e-mendibil, j’ai dû réaliser une migration technique qui m’a été très coûteuse et c’est très frustrant car l’utilisateur final ne voit pas le résultat, pire tout ce qu’il peut constater suite à cette migration ce sont les régressions engendrées !migrationOiseau

Mais si ça n’apporte rien à part des bugs pourquoi je me suis infligé ça ?

Une migration d’un logiciel c’est le changement d’une technologie utilisée par ce logiciel. Ça peut être pour remplacer une technologie par une autre ou simplement mettre à jour une technologie existante.

Il y a différents objectifs pour une migration :

  • avoir de nouvelles fonctionnalités
  • corriger des bugs
  • améliorer les performances
  • faire marcher un logiciel avec une nouvelle technologie ou sur une nouvelle plateforme qui imposerait l’utilisation d’une certaine techno.

migrationPoisson

Pour reprendre l’exemple de la migration de e-mendibil, je vais expliquer rapidement les briques techniques avec lesquelles il était construit avant la migration.

E-Mendibil se base sur un logicel de gestion de contenu (Content Management System) appelé Drupal en version 5.5. Drupal 5.5 a besoin pour fonctionner que la plateforme PHP soit installée en version 4.2 avec une base de données MySQL.

drupal                                      mysqlphp

Ces prérequis étaient validés par le précédent hébergeur mais par soucis d’économie, nous avons décidés de changer d’hébergeur. Ce dernier fournit des serveurs plus à jour avec PHP en version 5.4.

Super ! une nouvelle version de PHP plus stable, plus de fonctionnalités, plus rapide… (harder, better, faster, stronger…) oui mais non car cette nouvelle version de PHP n’est pas rétrocompatible vis à vis de la version 4.4. C’est à dire que ce qu’ils l’ont développé ne se sont pas préoccupés que certains applications codées avec une version de PHP inférieur à 4.4  ne fonctionnerait probablement plus… Ce qui est le cas de Drupal 5.5 donc e-mendibil ne fonctionnait pas bien sur la nouvelle plateforme.

C’est un problème récurrent en informatique lors de la gestion des dépendances, les logiciels/systèmes dont dépendent d’autres systèmes sont amenés à évoluer forçant les logiciels dépendants dit « clients » à évoluer.

carte

Voici un exemple simple qui illustre bien le problème de rétro-compatibilité.

Imaginez que vous souhaitez afficher une carte sur votre site internet pour montrer votre localisation. Vous n’avez pas envie de dessiner vous-même la carte donc vous décidez de faire appel à un fournisseur de carte externe comme GoogleMaps ou ViaMichelin et vous choisissez le fameux Carto3000. Vous ajoutez sur votre site le composant « afficherCarteDUneAdresse » qui a partir d’une adresse française vous affiche la carte et c’est gagné.

Le changement c’est maintenant…

Carto3000 décide de s’ouvrir à l’international et donc d’afficher des cartes du monde entier. Le problème c’est que le composant « afficherCarteDUneAdresse » ne gère que la France et qu’en tapant « Barcelone » il affiche « Barcelone du Gers » (vous pensiez sûrement à cette ville là) !panneau-barcelonne-du-gers

Carto3000 doit donc faire évoluer son composant pour qu’on puisse préciser le pays mais que faire de tout ceux qui utilisent déjà le composant sans préciser le pays ?

Plusieurs solutions :

  • si le client ne précise pas de pays : on affiche un message d’erreur lui demandant de le faire
  • on détermine automatiquement le pays en récupérant les données de géo-localisation du visiteur
  • on laisse le composant « afficherCarteDUneAdresse » intacte (il n’affichera que les adresses françaises) et on crée un autre composant « afficherCarteDUneAdresseInternationale » capable d’afficher des adresses de n’importe quel pays

La solution 1 casse la rétro-compatibilité : tous les utilisateurs du composant « afficherCarteDUneAdresse » vont devoir modifier leur site pour préciser le pays sinon ils auront ce message d’erreur.

La solution 2 est très dangereuse car on a l’impression que la rétro-compatibilité est maintenue mais ce n’est pas vraiment le cas et le composant ne se comporte plus vraiment comme avant : les visiteurs espagnols d’un site à Barcelone du Gers verront la carte à Barcelone en Espagne…
Cette solution n’est pas acceptable car elle change le comportement du service rendu.

La solution 3 préserve la rétro-compatibilité tout en permettant aux nouveaux utilisateurs de préciser le pays. On va dire que le composant « afficherCarteDUneAdresse » est déprécié et qu’il est maintenant préférable d’utiliser « afficherCarteDUneAdresseInternationale ».

La solution 3 semble donc la solution idéale mais ce n’est pas le choix que va faire Carto3000, pourquoi ?

argentCar c’est la plus onéreuse ! Carto3000 va maintenant devoir maintenir 2 composants au lieu d’un. S’ils doivent corriger un bug ou ajouter une nouvelle fonctionnalité ils vont devoir le faire sur les 2 composants ça double quasiment la charge de travail !

Et en plus Carto3000 propose d’autres composant du même style : « afficherCarteSatelliteDUneAdresse », « afficherCarteReliefDUneAdresse », … La solution 3 les pousserait à dupliquer chaque composant !

Carto3000 n’a pas le budget de Google et choisit donc la solution 1 et va afficher un message d’erreur si on ne précise pas le pays. Et Carto3000 envoie donc un email à tous ses utilisateurs pour les prévenir qu’ils doivent préciser le pays sur le composant « afficherCarteDUneAdresse ».

Carto3000 fait des économies mais tous les utilisateurs vont avoir eux des frais supplémentaires pour mettre à jour leur site et préciser le pays.

Le choix de Carto3000 n’est pas isolé, on peut trouver beaucoup d’exemple de non rétro-compatibilité et pas que dans le monde logiciel :

  • apple change ses chargeurs
  • la SNCF commande des rames trop larges
  • vous achetez un livre trop grand pour rentrer dans votre bibliothèque

bibliotheque

Le dernier exemple est bête (les précédents sont pas mal non plus…) mais impose de changer de bibliothèque si vous tenez absolument à ranger tous vos livres en un seul endroit !

Pour revenir à e-Mendibil, qui donc ne fonctionnait plus sur le nouvel hébergeur, voici les solutions qui s’offrait à moi :

  • revenir sur l’ancien hébergeur
  • bricoler/modifier (« hacker ») ma version actuelle de Drupal pour que au minimum les fonctionnalités qui m’intéresse fonctionne sur le nouvel hébergeur
  • migrer de la version 5.5 à la version 6 compatible avec le nouvel hébergeur

La solution 1 était peut être la moins couteuse mais l’ancien hébergeur allait probablement se comporter un jour comme le nouveau. Ça ne ferait donc que reporter le problème.

J’ai étudié la solution 2 mais elle s’avère très dangereuse car quand on commence à « hacker » un logiciel beaucoup de problèmes peuvent ensuite survenir.

Il ne restait donc que la solution 3, très couteuse mais plus pérenne.

Très couteuse car dans mon cas Drupal n’est pas en bout de la chaine des dépendances ! Une vingtaine d’extensions/modules installées par dessus Drupal vont devoir être migrer également. Et chaque migration de module est spécifique :

  • quelques modules ont été migrés sans problème
  • sur certains modules la configuration faite pour e-mendibil n’était plus permises, il a fallu l’adapter ou la refaire
  • certains modules n’existe plus sur la nouvelle version de Drupal, il a fallu trouver des modules équivalents et refaire la configuration ou abandonner la fonctionnalité
  • certains modules demandait une migration du format des données dans la base, cette migration se faisait plus ou moins automatiquement…
  • certains modules sont buggés sur la nouvelle version…

Au final le site d’e-Mendibil n’a pas vraiment gagner sur cette migration puisque certaines fonctionnalités ont été abandonnées.

LogoDependance_05Comment éviter ce genre de problème de dépendance ?

La réponse est simple mais difficile à appliquer : il faut maitriser ses dépendances.

Comment maitriser ses dépendances ?

Ce n’est pas facile mais voici quelques pistes :

  • ne pas en avoir et tout faire soi-même :)
  • utiliser des dépendances qui ont de la « bouteille », qui existe depuis suffisamment longtemps et sont suffisamment utilisés pour avoir un bon niveau d’expérience et être assez stable.
  • A l’inverse, éviter les produits « hype » ou trop jeune qui suivent un effet de mode et ne sont pas pensés pour durer et peuvent souffrir de problème de conception qui les amèneront à modifier fortement leurs produits.
  • passer par des standards, si les dépendances s’attachent à être compatible avec un standard : elle ne peuvent pas changer du jour au lendemain et au pire vous pourrez basculer sur une autre dépendance qui est compatible avec ce standard.
  • si on est sur un produit qui évolue régulièrement, il est préférable de migrer régulièrement à chaque changement majeur plutôt qu’attendre et de se retrouver face à un mur quand on sera obligé de tout migrer d’un coup.

Une réflexion au sujet de « Les migrations techniques »

Laisser un commentaire