Troisième partie : la mise en place d’évolutions pérennes et maintenables

Lancer un projet de développement d’une long-term support c’est bien. Mettre les moyens, méthodes et organisation pour le mener à bien c’est encore mieux. Mais encore faut-il que la release soit un succès, et qu’elle s’intègre au mieux dans les cycles de release et de maintenance pour l’avenir.

C’est tout l’objet de ce dernier article de notre série sur iTop 2.7 Long-Term Support.

Un déploiement régulier et progressif

Une version LTS se doit de sortir avec la plus grande qualité possible ! Nous avons voulu confronter cette version au plus tôt au « monde réel » afin d’obtenir le plus de retours possibles : stabilisation, corner case, validation des choix effectués…

Alpha, Beta, RC

Par le passé nous avions déjà publié des versions beta de notre produit (exemples : 2.5.0-beta, 2.4.0-beta, 2.3.0-beta), mais jamais plus d’une par version. Ces beta avaient été générées à la fin des développements d’évolution. Elles ont été suivies d’une phase de correction de bugs et enfin la publication de la version finale.

Pour cette version 2.7.0 qui apporte comme on l’a vu dans notre article précédent plusieurs modifications majeures nous avons souhaité pouvoir disposer de plus de versions intermédiaires autant pour le test interne à l’entreprise que pour la communauté. Pour définir différents types de jalons, nous avons repris des nommages assez standards dans l’industrie du logiciel :

• alpha : versions non finalisées, mais dont un certain nombre de fonctionnalités peuvent déjà être testées

• beta : version fonctionnellement complète, mais pas encore exhaustivement testée (ce qui correspond à la définition de nos beta pour les versions précédentes)
• release candidate (RC) : version prête à publier, mais sur laquelle on souhaite étendre les tests

Et c’est ainsi que pour la 2.7.0 nous avons généré toutes ces versions intermédiaires :

• 2.7.0-alpha1 le 22/10/2019
• 2.7.0-beta le 18/12/2019
• 2.7.0-beta2 le 29/01/2020
• 2.7.0-rc le 24/03/2020
• sur le même commit 2.7.0-rc2 et 2.7.0 le 25/03/2020

Nous avons publié 2 versions beta sur SourceForge afin de récolter des retours de la communauté iTop :

• beta le 18/12/2019
• beta2 le 29/01/2020

Les quelques corrections intégrées dans la beta ont été utiles pour le déploiement d’iTop Combodo par la suite.

Déploiement sur l’iTop Combodo

Installation long-term support 2.7 sur iTop Combodo

Pour ses besoins propres, et aussi pour réaliser le support de ses clients, Combodo dispose d’une version personnalisée d’iTop. Cette instance est surnommée « iTop Combodo« . Nous avons décidé de déployer sur cette instance des versions iTop 2.7.0 beta afin de nous assurer de détecter :

• les problèmes de migration : l’iTop Combodo contient de très nombreuses personnalisation utilisant un très large panel des API iTop
• les bugs à l’usage : cette instance étant utilisée au quotidien dans l’entreprise et sur l’ensemble de ses fonctionnalités (Helpdesk, exports, datasynchro, …) cela augmente la probabilité de déceler les problèmes rapidement !

Les premiers déploiements de la version 2.7.0 sur l’iTop de Combodo ont eu lieu deux mois avant la sortie de la version finale : la 2.7.0 beta a été déployée en janvier 2020. Plusieurs mises à jour suivantes ont permis de valider la beta2 et la RC. Cela a permis d’améliorer le produit et surtout de se rassurer sur la qualité !

Les versions beta de iTop 3.0.0

Cette première expérience réussie nous a poussé à utiliser encore plus ce mécanisme de pré-release à l’occasion de iTop 3.0.0. En effet pour iTop 3.0.0 nous avons créé :

• une alpha (publique)
• 8 versions beta, dont 4 publiques
• l’installation de certaines beta sur iTop Combodo entre juillet 2021 et la sortie de la version finale en janvier 2022 : beta1 (01/07), beta2 (13/07), beta3 (31/08), beta5 (04/10), beta7 (24/11), finale (26/01)

Et pour aller plus loin dans l’intégration de la Communauté dans ce processus, un forum dédié aux versions beta a été créé en mars 2020 juste avant la publication de la 1ere 3.0.0 beta.

Ce forum aura été très suivi et a permis de récolter de très nombreux retours de notre communauté, des partenaires et clients Combodo. Merci à tous pour votre implication ! 🤗

Toujours avec cette volonté de plus communiquer et partager l’information avec nos utilisateurs, nous avons ajouté au plan de release :

• des annonces dédiées sur Sourceforge
• une liste des problèmes connus sur notre Wiki, mise à jour en cours de développement.

Cependant, le travail sur la version 2.7.0 ne s’arrête pas à la sortie de la version finale, à partir de là une nouvelle phase commence en parallèle de la release 3.0. Il faut accompagner les utilisateurs dans la mise à jour de leur application.

Migrations

Une version qui a un cycle de développement de plus d’un an contient beaucoup de modifications (voir Organisation interne “Long-term” pour une version LTS au top) et par conséquent les nouvelles fonctionnalités et les changements doivent être documentés et transmis le mieux possible, autant vers les clients qu’à destination des équipes internes chez Combodo.

Ce que nous avons fait

Les notes de migration sont un document très important pour les utilisateurs et le service Support : c’est avec ces informations que les migrations des clients vont être préparées et exécutées.La rédaction de cette page wiki est donc un point très important du processus de réalisation d’une version, et suit les étapes suivantes :

1. Le document est rempli au fur et à mesure de l’avancement du développement, autant par l’équipe R&D que l’équipe Produit
2. Avant publication de la première version beta une structuration du document est effectuée par les 2 équipes pour assurer un maximum de lisibilité
3. La migration est testée lors des mises à jour de l’iTop Combodo avec les versions beta et RC
4. En cours de validation de la version (au moment de la RC donc), des tests de migration sont effectués sur des instances de test contenant des personnalisations représentatives

Comme pour les versions précédentes, nous avons suivi ce même processus pour créer les notes de migration de la version 2.7.0. Mais force est de constater que ce processus habituel n’aura cette fois pas été suffisant.

Retour d’expérience

En effet dans les mois qui ont suivi la publication de la version 2.7.0 finale, les migrations s’enchainant, nous avons pu constater :

• Quelques oublis dans les notes de migration, détectés sur des cas particuliers qui n’avaient pas été vus dans nos tests de migration lors de la RC : et donc de mauvaises surprises à gérer dans l’urgence.
• Les notes de migration qui deviennent compliquées à appréhender :
  • un grand volume de points à vérifier, avec certains très techniques et mal expliqués (en particulier : quand et pourquoi faire certaines modifications)
  • un mélange des genres entre les tâches concernant l’administrateur de la machine, l’administrateur iTop, et les développeurs de personnalisations iTop (extensions, code PHP inclus dans l’ITSM Designer)
• Changement de paradigme : si pour de nombreuses versions précédentes d’iTop on pouvait simplement mettre à jour et se référer aux notes de migration en cas de problèmes, avec la version 2.7.0 il devient impératif de préparer la migration avant de la réaliser !

A cela s’ajoute une formation et un accompagnement insuffisants de nos équipes support et conseil lors des premières migrations clients, par manque d’anticipation de l’ampleur de ces migrations.

Résultat : les difficultés rencontrées lors des premières migrations vers iTop 2.7 ont dégradé la qualité du produit perçue par nos clients.

Ce qui a été mis en place depuis

Le constat est clair, il fallait changer cela ! Ainsi, sur le développement de la version suivante 3.0.0, nous avons fait les choix suivants

Formation interne et transfert de compétences

• Tout au long du développement de la version 3.0.0, des présentations de l’avancement ont été faites, et aussi des présentations des fonctionnalités clés
• Des sessions de formation plus approfondies des équipes internes ont été organisées
  
• Migration assistée :
  • L’équipe Produits a donné pour chaque personne dans les équipes Support et Conseil une formation individuelle sur une migration réelle d’un client donné
  • Des migrations ont également été réalisées avec nos partenaires

Outils

Une grande innovation chez Combodo a été l’ajout d’un outil « audit de migration« . Cet outil est basé sur des règles qui vont contrôler une expression régulière ou un XPath sur :

• le XML généré par l’ITSM Designer (modification datamodel en XML, méthodes surchargées, snippets, …)
• le code PHP des modules installés sur cette instance

Chaque règle est associée à une version d’iTop.

Exemple de règle pour iTop 2.7.0 :

/itop_design/menus/menu[parent = "AdminTools"]

Si l’on souhaite vérifier les erreurs pour une migration vers iTop >= 2.7.0, et que dans la licence client cette règle est déclenchée alors une erreur sera levée.

Cet ensemble de règles sont saisies de manière simple et rapide en cours de développement, et validées en fin de version : exactement à la manière des migration notes dont nous parlions plus haut.
La différence ici est qu’il devient aisé de planifier une migration client, en listant tous les points posant problèmes sous forme de rapport.
Cet outil va aussi grandement aider lors de migrations portant sur plusieurs versions majeures (par exemple de 2.6.* à 3.0.*).

Documentation

• Pour la version 3.0.0 nous avons créé une nouvelle page de notes de migration « developer » : Migrate an Extension to 3.0
  • Ces notes de migration dédiées aux développeurs d’extension sont découpées en plusieurs catégories claires : iTop XML, PHP APIs, Twig, JS APIs, CSS APIs.
  • Dans chacune de ces catégories, des chapitres dédiés listent les suppression d’API (« breaking changes »), et un autre les dépréciations.
• Également une page de compatibilité des extensions a été développée : Extensions compatibility with iTop 3.0 afin d’aider les testeurs de versions alpha et beta, et après livraison de la version finale pour que les utilisateurs communautaire puissent migrer plus simplement

Les perspectives

Processus de livraison

Le processus de livraison d’une version de iTop (Professional, Essential, Community) est une opération complexe : plusieurs départements de l’entreprise sont concernés (équipes R&D, Produits, Marketing), et de très nombreuses tâches doivent être exécutées dans un ordre définis !

Pour aider au suivi de ce processus, notre instance iTop interne a été adaptée pour associer à chaque version une liste de nouveaux objets Work Order. Ils contiennent principalement :

• une équipe d’affectation,
• une durée,
• la dépendance éventuelle à d’autre objets Work Order
• et bien sûr un état.

Ainsi, chacun peut voir le calendrier prévu et pendant la réalisation suivre l’avancement.

L’équipe R&D doit réaliser plusieurs dizaines de tâches, certaines à automatiser. Nous avons donc réduit cette liste en développant :

• des scripts (répertoire .make de notre dépôt)
• des tests PHPunit nous informant des tâches oubliées (répertoire test/integration/ de notre dépôt)

Ces efforts d’automatisation et validation automatique sont toujours à poursuivre.

Versions mineures et évolutions

Jusqu’à la 2.7.0, notre règle était d’intégrer des évolutions uniquement dans les versions majeures (x.y.0). Mais quelques mois après la sortie de la 2.7.0, nous avons convenu qu’il nous fallait aussi intégrer des changements de comportement dans les versions correctives suivantes… Cela a été le cas sur la 2.7.1 et la 2.7.2. La version 2.7.0 ayant introduit de très nombreux changements, cela était peut être assez inévitable ?

Alors, quelle version faut-il décider de basculer en LTS ? Aurions nous du attendre une 2.7.2, plutôt que de déclarer le statut LTS dès la 2.7.0 ?
Aussi, par rapport à la politique de dépréciation / suppression de nos API (souvenez-vous, nous en parlions dans le 2eme article) : est-ce que la prochaine version iTop LTS ne devra contenir aucune API dépréciée ?

Ces questions restent ouvertes et en discussion avec nos clients et partenaires.

Adoption des versions iTop

Aujourd’hui, soit deux ans et demi après la sortie de la version 2.7.0, environ 80% de nos clients sont dans une version maintenue (au sens corrections de bugs) et plus de 90% de nos clients sont sur les trois dernières versions.

En comparaison, en 2019 les 2 dernières versions majeures (2.6 et 2.5) ne représentaient que 60% des installations chez nos clients et les versions 2.4 et 2.3 représentaient encore 34%.

Conclusion

Si nous devons conclure en une phrase cette expérience « long-term support », le recul nous montre que le pari de la LTS a fonctionné.

L’adoption est indéniable, malgré les difficultés rencontrées suite aux premières migrations et les risques de perte de confiance de nos utilisateurs. D’autre part, combiner des versions short-term et long-term support a indéniablement fait progresser Combodo dans la gestion des développements et des releases, tout comme son organisation interne.

Capitalisons sur ces apprentissages pour le passage à la prochaine LTS 3.X. Affaire à suivre…

Eric Espié

Plus de publications

Développeur dans de nombreux domaines comme les télécoms, le kernel Linux et AIX (IBM), la sécurité, la détection embarquée de pannes matérielles, les ERP, et l'ITSM.

• Organisation interne "Long-term" pour une version LTS au top
• Besoin de stabilité ? La Long Term Support est faite pour vous