Première partie : Pourquoi Combodo s’est lancé dans une version Long Term Support d’iTop
Avec la version 2.7 d’iTop nous avons introduit notre première Long Term Support (LTS) qui est une version que Combodo prévoit de supporter pendant plusieurs années. Suite à la fin de support de la 2.7, une version ultérieure d’iTop viendra la remplacer comme version LTS afin de garantir un support stable et à long terme à nos clients.
Nous souhaitons aujourd’hui, après 2 ans d’utilisation de notre première version Long Term Support chez certains de nos clients, partager avec vous notre expérience de la transition vers un mix entre LTS et STS. Dans ce premier article nous allons vous expliquer quelles sont les raisons qui nous ont poussés à créer cette version Long Term Support.
Nous verrons dans les deux prochains articles la façon dont les équipes Combodo se sont organisées pour livrer cette version ainsi que notre retour d’expérience en prévision de la préparation de la prochaine version LTS.
Long Term Support : qu’est-ce que ça veut dire ?
Selon Wikipedia, la définition d’une version Long-term support (LTS) est :
En informatique, une version Long-term support ou LTS (en français Support à long terme) désigne une version spécifique d’un logiciel dont le support est assuré pour une période de temps plus longue que la normale.
Il s’agit de la mise en œuvre de la politique de gestion du cycle de vie d’un produit dans le domaine du génie logiciel, avec notamment l’application des principes de l’ingénierie de la fiabilité au processus de développement et de maintenance du logiciel. Le support à long terme étend la durée de la maintenance applicative ; il modifie également le type et la fréquence de publication des mises à jour (correctifs) pour réduire le risque, les dépenses et les perturbations liés au déploiement de logiciels, tout en favorisant la fiabilité.
Pourquoi une version LTS pour iTop ?
Version iTop utilisées chez nos clients
En 2019 :
- 40% des versions d’iTop installées chez nos clients avaient plus de deux ans
- nous devions supporter 7 versions d’iTop différentes, dont 6 versions majeures !
Le nombre de clients augmentant, il devenait difficile d’assurer un service de qualité dans de bonnes conditions…
Deux typologies de clients se dessinent alors :
- Les clients recherchant la stabilité en restant longtemps sur une version d’iTop qui leur convient
- Les clients recherchant les nouvelles fonctionnalités en utilisant les dernières versions d’iTop
Coûts des services
Nous fournissons à la fois des services de support (impliquant la maintenance de l’application) et de l’intégration et des développements spécifiques pour nos clients. Avant de mettre en œuvre la politique de gestions des versions, nous supportions la maintenance de tous les iTop installés chez nos clients, quelle qu’en soit la version. Cela veut dire que les équipes devaient maitriser les spécificités d’un panel de versions différentes, qui ne faisait que grandir !
- Les fonctionnalités d’iTop 1.0 sont complètement différentes de celles d’iTop 2.6. Cela rend la mise à niveau et le temps d’apprentissage des nouvelles recrues toujours plus longs.
- De plus, maintenir des environnements adaptés à des versions d’iTop si différentes en termes de prérequis systèmes (PHP, MySQL…) devenait trop complexe.
Pour conserver un prix de souscription raisonnable pour nos clients et garder une qualité de service au meilleur niveau, nous devions nous concentrer sur ce que nous connaissions le mieux. Nous devions nous concentrer sur les versions récentes d’iTop et les versions récentes des plateformes systèmes.
La décision
Nous avons décidé de passer à une gestion des versions d’iTop suivant le modèle LTS / STS : Cela veut dire que des versions LTS supportées plusieurs années sont suivies par plusieurs versions STS (Short Term Support) supportées moins longtemps. En d’autres termes à un instant donné nous auront un nombre limité de versions à supporter.
Vous pouvez retrouver le calendrier de support des versions de iTop sur la documentation officielle. Au mois de juillet 2022, ce calendrier est le suivant :
Le modèle LTS / STS répond à nos typologies de clients évoquées plus haut :
- Les LTS correspondent aux clients recherchant la stabilité
- Alors que les STS sont destinées aux clients recherchant les nouvelles fonctionnalités au prix quelques fois de changements importants
Cela nous encourage à envisager des fonctionnalités plus disruptives (comme le changement de l’interface de la console dans la version d’iTop 3.0.0, cette version étant une STS) tout en conservant de la stabilité pour les clients qui restent sur la version LTS.
Les différents challenges
Contenu d’une version LTS : des choix Cornéliens
Depuis longtemps, la politique en terme de contenu des versions d’iTop est la suivante :
- Les nouvelles fonctionnalités arrivent dans les versions majeures (celles qui se terminent en « .0 », par exemple : 2.5.0 ou 2.6.0)
- Quelques nouvelles fonctionnalités (à la marge) sont encore possibles dans la première version mineure (la version .1)
- Toutes les autres version mineures contiennent des corrections fonctionnelles ou de sécurité seulement
- Les versions mineures doivent conserver une compatibilité au niveau des API et interfaces pour garantir le fonctionnement des extensions
Sur cette première version LTS, nous avons envisagé qu’il fallait répondre à plusieurs objectifs :
- La stabilité : une version qui doit rester longtemps installée chez un client doit être stable (pas de crash, pas de défauts bloquants…). Par conséquent les évolutions intégrées ne doivent pas être trop impactantes pour la base de code.
- La performance : le volume de données gérées par iTop augmentant avec les années d’utilisation, il est important d’avoir une version LTS performante !
- Ajuster les fonctionnalités existantes (attachements, portail utilisateur, log, …) pour ne pas avoir à faire d’évolutions fonctionnelles durant la vie de la LTS
- Fournir les fonctionnalités qui ne pourront pas attendre la prochaine version majeure : des fonctionnalités demandées qui n’avaient pas encore été réalisées, mais qui seront utiles aux clients adoptant la version LTS sur toute sa durée de vie
- Ajouter des outils de support internes à l’application pour faciliter la maintenance
- Faciliter la migration vers des versions de maintenance : les clients adoptant la version LTS doivent pouvoir installer les corrections de sécurité facilement avec un minimum d’interruption de service
Comme on peut le constater, le travail à effectuer étant très conséquent, il a fallu faire des choix cornéliens pour respecter la date de sortie que l’on s’était fixée !
Nous sommes dans un monde qui bouge vite
iTop est programmé en PHP et utilise MySQL (ou MariaDB) comme base de données.
Le calendrier support de PHP s’est très nettement accéléré ces dernières années avec un passage à 2 ans de support par version majeure, puis 1 an de mises à jour de sécurité. Voici par exemple ce calendrier en mai 2022 :
Pour comparaison :
- PHP 5.5.0 est sorti en juin 2013, et la dernière version 5.5.38 en juillet 2016 : plus de 3 ans de support
- PHP 5.6.0 est sorti en août 2014, et la dernière version 5.6.40 en janvier 2019 : plus de 4 ans 1/2 de support
- PHP 7.0.0 est sorti en décembre 2015, et la dernière version 7.0.33 en janvier 2019 : plus de 3 ans de support
Nous souhaitons que nos clients migrent rapidement vers cette première version LTS. Par conséquent nous ne pouvons pas imposer des versions minimales PHP / MySQL trop élevées.
Comme les utilisateurs choisissant une version LTS préfèrent la stabilité, nous devons autant que possible ne plus modifier cette version minimale PHP… considérant que cette version LTS va devoir être supportée plusieurs années par Combodo !
Mais iTop utilise aussi une soixantaine de bibliothèques PHP externes qui évoluent également. La gestion de ces dépendances est très importante à prendre en compte quand on veut supporter une version d’iTop plusieurs années :
- certaines bibliothèques vont suivre l’évolution du langage mais en arrêtant de supporter les versions PHP trop anciennes
- d’autres seront en retard
- et encore d’autres vont être abandonnées par leur éditeur
Lors du lancement des développements de cette LTS, nous avions par exemple pour mission de remplacer une de ces bibliothèques au développement arrêté : Silex. Cette librairie qui est utilisée pour le portail dans iTop n’a plus été maintenue après 2018
Conclusion
Ainsi, les versions supportées doivent répondre à un ensemble complexe de contraintes et prérequis, et la combinaison des LTS et STS ne facilite en rien la gestion de leurs développements.. C’est avec tout cela en tête que nous avons lancé le projet de développement à partir de mars 2019.
Mais comment s’organiser pour développer et livrer une version Long Term Support ? C’est ce que nous allons vous dévoiler dans le prochain article.