Pour un DSI, un site se gère sur la longueur. Il doit minimiser le fardeau de la maintenance et des évolutions tout en assurant sa pérennité maximale.
Deux problématiques principaux se posent à lui par rapport au cycle de vie du produit qu’il à choisi : les corrections de bug et les mises à jour de sécurité d’une part et la gestion de la compatibilité ascendante d’autre part.
Pour Drupal la politique est la suivante. Les nouvelles releases sont numérotés par 2 chiffres : une version majeure, et une version mineure. Par exemple actuellement nous sommes en Drupal 7.24
- les changements de version majeure brisent la compatibilité ascendante mais permettent des évolutions fonctionnelles et d’API majeures. Si on veut monter en version il faut donc le prévoir en amont.
- les changements de version mineures apportent surtout des corrections de bugs, des patch de sécurités, et des évolutions mineurs, mais surtout, ne brisent pas la compatibilité ascendante. On peut donc (et c’est même recommandé pour des questions de sécurité) faire ces mise à jour « les yeux fermés » (idéalement, car dans la pratique il faut quand même prendre des précautions élémentaires).
- La communauté supporte la version n-1. C’est à dire que Drupal 6 ne sera supporté que jusqu’à la sortie de Drupal 8.
Mais les difficultés de développement de Drupal 8, ainsi que l’évolution rapide de web imposent de revoir cette politique. Même si ce n’est pas encore définitif, il semble que la communauté Drupal s’achemine vers une nouvelle manière de gérer le cycle de vie de Drupal, dite, « release sémantique« .
De quoi s’agit-il ?
- Les évolutions « mineures » (celles qui ne brisent pas ou très peu la compatibilité ascendante) de Drupal se feront selon un cycle de 6 mois, afin de pouvoir intégrer plus rapidement les nouveautés dans le cœur.
- Les évolutions « majeures » (celles qui brisent la compatibilité ascendante) disposeront d’un support LTS assuré en version n-1 pour les correction de bugs et en version n-2 pour les patchs de sécurité, mais uniquement à partir de la dernière évolution mineure.
Dans la pratique cela devrait permettre un cycle de vie d’un site d’environ 5 ans avec une fenêtre d’un peu plus d’un an pour faire évoluer son site en version n+2. Ce qui semble assez raisonnable comme compromis.
Les montées en version de Drupal ne sont pas sans poser de problèmes. Il y a 4 aspects à considérer :
- le coeur de Drupal en principe dispose d’un « chemin d’upgrade » qui fait évoluer la base de donnée afin que le site soit toujours fonctionnel
- les thèmes (l’habillage) est à revoir en grande partie. D’une part parce que les API changent, d’autre part pour s’adapter aux nouveaux standards du web en la matière.
- pour les modules communautaires, c’est au cas par cas. Les plus populaires disposent en général d’un chemin d’upgrade comme le coeur de Drupal, mais c’est loin d’être une règle générale. Il faut donc s’attendre devoir faire évoluer les données en base soi même, avec des requêtes SQL.
- reste ensuite le code custum. Plus il sera important en proportion, plus l’opération sera lourde et risquée.
Le cas de Drupal 8 est la encore différent. Il n’y aura pas de « chemin d’upgrade » depuis Drupal 7 car les architectures sont trop différentes. Pour l’instant, il semble que le choix se porte sur le module « Migrate » qui aura en charge d’aspirer les données des anciens sites. Mais ce module n’est pas magique et demande un certain travail de configuration / développement. C’est un choix stratégique qui, même s’il pénalise un peu les usager de Drupal, pourrait permettre de convertir plus facilement des sites non Drupal (WordPress, Typo3, phpBB) et d’attirer encore plus de monde vers Drupal.