Pour cette version 2.7.0 qui apporte comme on l\u2019a vu dans notre article pr\u00e9c\u00e9dent plusieurs modifications majeures nous avons souhait\u00e9 pouvoir disposer de plus de versions interm\u00e9diaires autant pour le test interne \u00e0 l\u2019entreprise que pour la communaut\u00e9. Pour d\u00e9finir diff\u00e9rents types de jalons, nous avons repris des nommages assez standards dans l\u2019industrie du logiciel :<\/p>\n
- \n
- alpha : versions non finalis\u00e9es, mais dont un certain nombre de fonctionnalit\u00e9s peuvent d\u00e9j\u00e0 \u00eatre test\u00e9es<\/li>\n<\/ul>\n
- \n
- beta : version fonctionnellement compl\u00e8te, mais pas encore exhaustivement test\u00e9e (ce qui correspond \u00e0 la d\u00e9finition de nos beta pour les versions pr\u00e9c\u00e9dentes)<\/li>\n
- release candidate (RC) : version pr\u00eate \u00e0 publier, mais sur laquelle on souhaite \u00e9tendre les tests<\/li>\n<\/ul>\n
Et c\u2019est ainsi que pour la 2.7.0 nous avons g\u00e9n\u00e9r\u00e9 toutes ces versions interm\u00e9diaires :<\/p>\n
- \n
- 2.7.0-alpha1<\/a>\u00a0le 22\/10\/2019<\/li>\n
- 2.7.0-beta<\/a>\u00a0le 18\/12\/2019<\/li>\n
- 2.7.0-beta2<\/a>\u00a0le 29\/01\/2020<\/li>\n
- 2.7.0-rc<\/a>\u00a0le 24\/03\/2020<\/li>\n
- sur le m\u00eame commit\u00a02.7.0-rc2<\/a>\u00a0et\u00a02.7.0<\/a>\u00a0le 25\/03\/2020<\/li>\n<\/ul>\n
Nous avons publi\u00e9 2 versions beta sur SourceForge afin de r\u00e9colter des retours de la communaut\u00e9 iTop :<\/p>\n
- \n
- beta<\/a>\u00a0le 18\/12\/2019<\/li>\n
- beta2<\/a>\u00a0le 29\/01\/2020<\/li>\n<\/ul>\n
Les quelques corrections int\u00e9gr\u00e9es dans la beta ont \u00e9t\u00e9 utiles pour le d\u00e9ploiement d\u2019iTop Combodo par la suite.<\/p>\n
D\u00e9ploiement sur l\u2019iTop Combodo<\/h3>\n
Pour ses besoins propres, et aussi pour r\u00e9aliser le support de ses clients, Combodo dispose d\u2019une version personnalis\u00e9e d\u2019iTop. Cette instance est surnomm\u00e9e\u00a0\u00ab\u00a0iTop Combodo<\/strong>\u00ab\u00a0. Nous avons d\u00e9cid\u00e9 de d\u00e9ployer sur cette instance des versions iTop 2.7.0 beta afin de nous assurer de d\u00e9tecter :<\/p>\n
- \n
- les\u00a0probl\u00e8mes de migration<\/strong>\u00a0: l\u2019iTop Combodo contient de tr\u00e8s nombreuses personnalisation utilisant un tr\u00e8s large panel des API iTop<\/li>\n
- les\u00a0bugs \u00e0 l\u2019usage<\/strong>\u00a0: cette instance \u00e9tant utilis\u00e9e au quotidien dans l\u2019entreprise et sur l\u2019ensemble de ses fonctionnalit\u00e9s (Helpdesk, exports, datasynchro, \u2026) cela augmente la probabilit\u00e9 de d\u00e9celer les probl\u00e8mes rapidement !<\/li>\n<\/ul>\n
Les premiers d\u00e9ploiements de la version 2.7.0 sur l\u2019iTop de Combodo ont eu lieu deux mois avant la sortie de la version finale : la 2.7.0 beta a \u00e9t\u00e9 d\u00e9ploy\u00e9e en janvier 2020. Plusieurs mises \u00e0 jour suivantes ont permis de valider la beta2 et la RC. Cela a permis d\u2019am\u00e9liorer le produit et surtout de se rassurer sur la qualit\u00e9 !<\/p>\n
Les versions beta de iTop 3.0.0<\/h3>\n
Cette premi\u00e8re exp\u00e9rience r\u00e9ussie nous a pouss\u00e9 \u00e0 utiliser encore plus ce\u00a0m\u00e9canisme de pr\u00e9-release \u00e0 l\u2019occasion de iTop 3.0.0<\/strong>. En effet pour iTop 3.0.0 nous avons cr\u00e9\u00e9 :<\/p>\n
- \n
- une alpha (publique)<\/li>\n
- 8 versions beta, dont 4 publiques<\/li>\n
- l\u2019installation 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)<\/li>\n<\/ul>\n
Et pour aller plus loin dans l\u2019int\u00e9gration de la Communaut\u00e9 dans ce processus, un\u00a0forum d\u00e9di\u00e9 aux versions beta<\/a>\u00a0a \u00e9t\u00e9 cr\u00e9\u00e9 en mars 2020 juste avant la publication de la 1ere 3.0.0 beta.<\/p>\n
Ce forum aura \u00e9t\u00e9 tr\u00e8s suivi et a permis de r\u00e9colter de tr\u00e8s nombreux retours de notre communaut\u00e9, des partenaires et clients Combodo. Merci \u00e0 tous pour votre implication ! \ud83e\udd17<\/p>\n
Toujours avec cette volont\u00e9 de plus communiquer et partager l\u2019information avec nos utilisateurs, nous avons ajout\u00e9 au plan de release :<\/p>\n
- \n
- des annonces d\u00e9di\u00e9es sur Sourceforge<\/a><\/li>\n
- une liste des probl\u00e8mes connus sur notre Wiki,\u00a0<\/a>mise \u00e0 jour en cours de d\u00e9veloppement.<\/li>\n<\/ul>\n
Cependant, le travail sur la version 2.7.0 ne s\u2019arr\u00eate pas \u00e0 la sortie de la version finale, \u00e0 partir de l\u00e0 une nouvelle phase commence en parall\u00e8le de la release 3.0. Il faut accompagner les utilisateurs dans la mise \u00e0 jour de leur application.<\/p>\n
Migrations<\/h2>\n
Une version qui a un cycle de d\u00e9veloppement de plus d\u2019un an contient beaucoup de modifications (voir\u00a0Organisation interne \u201cLong-term\u201d pour une version LTS au top<\/a>) et par cons\u00e9quent les nouvelles fonctionnalit\u00e9s et les changements doivent \u00eatre document\u00e9s et transmis le mieux possible, autant vers les clients qu\u2019\u00e0 destination des \u00e9quipes internes chez Combodo.<\/p>\n
Ce que nous avons fait<\/h3>\n
Les\u00a0notes de migration<\/a>\u00a0sont un document tr\u00e8s important pour les utilisateurs et le service Support<\/strong>\u00a0: c\u2019est avec ces informations que les migrations des clients vont \u00eatre pr\u00e9par\u00e9es et ex\u00e9cut\u00e9es.La r\u00e9daction de cette page wiki est donc un point tr\u00e8s important du processus de r\u00e9alisation d\u2019une version, et suit les \u00e9tapes suivantes :<\/p>\n
- \n
- Le document est rempli au fur et \u00e0 mesure de l\u2019avancement du d\u00e9veloppement, autant par l\u2019\u00e9quipe R&D que l\u2019\u00e9quipe Produit<\/li>\n
- Avant publication de la premi\u00e8re version beta une structuration du document est effectu\u00e9e par les 2 \u00e9quipes pour assurer un maximum de lisibilit\u00e9<\/li>\n
- La migration est test\u00e9e lors des mises \u00e0 jour de l\u2019iTop Combodo avec les versions beta et RC<\/li>\n
- En cours de validation de la version (au moment de la RC donc), des tests de migration sont effectu\u00e9s sur des instances de test contenant des personnalisations repr\u00e9sentatives<\/li>\n<\/ol>\n
Comme pour les versions pr\u00e9c\u00e9dentes, nous avons suivi ce m\u00eame processus pour cr\u00e9er les notes de migration de la version 2.7.0. Mais force est de constater que ce processus habituel n\u2019aura cette fois pas \u00e9t\u00e9 suffisant.<\/p>\n
Retour d\u2019exp\u00e9rience<\/h3>\n
En effet dans les mois qui ont suivi la publication de la version 2.7.0 finale, les migrations s\u2019enchainant, nous avons pu constater :<\/p>\n
- \n
- Quelques oublis dans les notes de migration, d\u00e9tect\u00e9s sur des cas particuliers qui n\u2019avaient pas \u00e9t\u00e9 vus dans nos tests de migration lors de la RC : et donc de mauvaises surprises \u00e0 g\u00e9rer dans l\u2019urgence.<\/li>\n
- Les notes de migration qui deviennent compliqu\u00e9es \u00e0 appr\u00e9hender :\n
- \n
- un grand volume de points \u00e0 v\u00e9rifier, avec certains tr\u00e8s techniques et mal expliqu\u00e9s (en particulier : quand et pourquoi faire certaines modifications)<\/li>\n
- un m\u00e9lange des genres entre les t\u00e2ches concernant l\u2019administrateur de la machine, l\u2019administrateur iTop, et les d\u00e9veloppeurs de personnalisations iTop (extensions, code PHP inclus dans l\u2019ITSM Designer)<\/li>\n<\/ul>\n<\/li>\n
- Changement de paradigme : si pour de nombreuses versions pr\u00e9c\u00e9dentes d\u2019iTop on pouvait simplement mettre \u00e0 jour et se r\u00e9f\u00e9rer aux notes de migration en cas de probl\u00e8mes, avec la version 2.7.0\u00a0il devient imp\u00e9ratif de pr\u00e9parer la migration avant de la r\u00e9aliser<\/strong>\u00a0!<\/li>\n<\/ul>\n
A cela s\u2019ajoute une formation et un accompagnement insuffisants de nos \u00e9quipes support et conseil lors des premi\u00e8res migrations clients, par manque d\u2019anticipation de l\u2019ampleur de ces migrations.<\/p>\n
R\u00e9sultat\u00a0: les difficult\u00e9s rencontr\u00e9es lors des premi\u00e8res migrations vers iTop 2.7 ont d\u00e9grad\u00e9 la qualit\u00e9 du produit per\u00e7ue par nos clients.<\/p>\n
Ce qui a \u00e9t\u00e9 mis en place depuis<\/h3>\n
Le constat est clair, il fallait changer cela ! Ainsi, sur le d\u00e9veloppement de la version suivante 3.0.0, nous avons fait les choix suivants<\/p>\n
Formation interne et transfert de comp\u00e9tences<\/h4>\n
- \n
- Tout au long du d\u00e9veloppement de la version 3.0.0, des pr\u00e9sentations de l\u2019avancement ont \u00e9t\u00e9 faites, et aussi des\u00a0pr\u00e9sentations des fonctionnalit\u00e9s cl\u00e9s<\/strong><\/li>\n
- Des sessions de\u00a0formation<\/strong>\u00a0plus approfondies des \u00e9quipes internes ont \u00e9t\u00e9 organis\u00e9es
\n<\/strong><\/li>\n- Migration assist\u00e9e<\/strong>\u00a0:\n
- \n
- L\u2019\u00e9quipe Produits a donn\u00e9 pour chaque personne dans les \u00e9quipes Support et Conseil une formation individuelle sur une migration r\u00e9elle d\u2019un client donn\u00e9<\/li>\n
- Des migrations ont \u00e9galement \u00e9t\u00e9 r\u00e9alis\u00e9es avec nos partenaires<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/h4>\n
Outils<\/h4>\n
Une grande innovation chez Combodo a \u00e9t\u00e9 l\u2019ajout d\u2019un outil \u00ab\u00a0audit de migration<\/strong>\u00ab\u00a0. Cet outil est bas\u00e9 sur des r\u00e8gles qui vont contr\u00f4ler une expression r\u00e9guli\u00e8re ou un XPath sur :<\/p>\n
- \n
- le XML g\u00e9n\u00e9r\u00e9 par l\u2019ITSM Designer (modification datamodel en XML, m\u00e9thodes surcharg\u00e9es, snippets, \u2026)<\/li>\n
- le code PHP des modules install\u00e9s sur cette instance<\/li>\n<\/ul>\n
Chaque r\u00e8gle est associ\u00e9e \u00e0 une version d\u2019iTop.<\/strong><\/p>\n
Exemple de r\u00e8gle pour iTop 2.7.0 :<\/span><\/p>\n
\n\nThe\u00a0Admin tools<\/strong>\u00a0(AdminTools<\/em>) sub-menus have been moved under the newly created group-menus:\u00a0Configuration<\/strong>\u00a0(ConfigurationTools<\/em>) and\u00a0System\u00a0<\/strong>(SystemTools<\/em>).<\/span><\/p>\n
If you have redefined those menus, it may not work as expected, as some submenus will have disappeared.<\/span><\/p><\/blockquote>\n<\/div>\n
Cette r\u00e8gle va aller v\u00e9rifier le XPath:<\/p>\n
\n\n<\/div>\n\n\n\n\n\n<\/div>\n<\/div>\n<\/div>\n\n<\/div>\n<\/div>\n\n\/itop_design\/menus\/menu[parent = \"AdminTools\"]<\/span><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\nSi l\u2019on souhaite v\u00e9rifier les erreurs pour une migration vers iTop >= 2.7.0, et que dans la licence client cette r\u00e8gle est d\u00e9clench\u00e9e alors une erreur sera lev\u00e9e.<\/p>\n
Cet ensemble de r\u00e8gles sont saisies de mani\u00e8re simple et rapide en cours de d\u00e9veloppement, et valid\u00e9es en fin de version : exactement \u00e0 la mani\u00e8re des migration notes dont nous parlions plus haut.
\nLa diff\u00e9rence ici est qu\u2019il devient ais\u00e9 de planifier une migration client, en listant tous les points posant probl\u00e8mes sous forme de rapport.
\nCet outil va aussi grandement aider lors de migrations portant sur plusieurs versions majeures (par exemple de 2.6.* \u00e0 3.0.*).<\/p>\n<\/h4>\n
Documentation<\/h4>\n
- \n
- Pour la version 3.0.0 nous avons cr\u00e9\u00e9 une nouvelle page de notes de migration \u00ab\u00a0developer\u00a0\u00bb :\u00a0Migrate an Extension to 3.0<\/a>\n
- \n
- Ces notes de migration d\u00e9di\u00e9es aux d\u00e9veloppeurs d\u2019extension sont d\u00e9coup\u00e9es en plusieurs cat\u00e9gories claires : iTop XML, PHP APIs, Twig, JS APIs, CSS APIs.<\/li>\n
- Dans chacune de ces cat\u00e9gories, des chapitres d\u00e9di\u00e9s listent les suppression d\u2019API (\u00ab\u00a0breaking changes\u00a0\u00bb), et un autre les d\u00e9pr\u00e9ciations.<\/li>\n<\/ul>\n<\/li>\n
- \u00c9galement une page de compatibilit\u00e9 des extensions a \u00e9t\u00e9 d\u00e9velopp\u00e9e :\u00a0Extensions compatibility with iTop 3.0<\/a>\u00a0afin d\u2019aider les testeurs de versions alpha et beta, et apr\u00e8s livraison de la version finale pour que les utilisateurs communautaire puissent migrer plus simplement<\/li>\n<\/ul>\n
<\/h2>\n
Les perspectives<\/h2>\n
Processus de livraison<\/h3>\n
Le processus de livraison d\u2019une version de iTop (Professional, Essential, Community) est une op\u00e9ration complexe : plusieurs d\u00e9partements de l\u2019entreprise sont concern\u00e9s (\u00e9quipes R&D, Produits, Marketing), et de tr\u00e8s nombreuses t\u00e2ches doivent \u00eatre ex\u00e9cut\u00e9es dans un ordre d\u00e9finis !<\/p>\n
Pour aider au suivi de ce processus, notre instance iTop interne a \u00e9t\u00e9 adapt\u00e9e pour associer \u00e0 chaque version une liste de nouveaux objets\u00a0Work Order<\/strong>. Ils contiennent principalement :<\/p>\n
- \n
- une \u00e9quipe d\u2019affectation,<\/li>\n
- une dur\u00e9e,<\/li>\n
- la d\u00e9pendance \u00e9ventuelle \u00e0 d\u2019autre objets Work Order<\/li>\n
- et bien s\u00fbr un \u00e9tat.<\/li>\n<\/ul>\n
Ainsi, chacun peut voir le calendrier pr\u00e9vu et pendant la r\u00e9alisation suivre l\u2019avancement.<\/p>\n
L\u2019\u00e9quipe R&D doit r\u00e9aliser plusieurs dizaines de t\u00e2ches, certaines \u00e0 automatiser. Nous avons donc r\u00e9duit cette liste en d\u00e9veloppant :<\/p>\n
- \n
- des scripts (r\u00e9pertoire\u00a0.make<\/a>\u00a0de notre d\u00e9p\u00f4t)<\/li>\n
- des tests PHPunit nous informant des t\u00e2ches oubli\u00e9es (r\u00e9pertoire\u00a0test\/integration\/<\/a>\u00a0de notre d\u00e9p\u00f4t)<\/li>\n<\/ul>\n
Ces efforts d\u2019automatisation et validation automatique sont toujours \u00e0 poursuivre.<\/p>\n
<\/a>Versions mineures et \u00e9volutions<\/h3>\n
Jusqu\u2019\u00e0 la 2.7.0, notre r\u00e8gle \u00e9tait d\u2019int\u00e9grer des \u00e9volutions uniquement dans les versions majeures (x.y.0). Mais quelques mois apr\u00e8s la sortie de la 2.7.0, nous avons convenu qu\u2019il nous fallait aussi int\u00e9grer des changements de comportement dans les versions correctives suivantes\u2026 Cela a \u00e9t\u00e9 le cas sur la\u00a02.7.1<\/a>\u00a0et la\u00a02.7.2<\/a>. La version 2.7.0 ayant introduit de tr\u00e8s nombreux changements, cela \u00e9tait peut \u00eatre assez in\u00e9vitable ?<\/p>\n
Alors, quelle version faut-il d\u00e9cider de basculer en LTS ? Aurions nous du attendre une 2.7.2, plut\u00f4t que de d\u00e9clarer le statut LTS d\u00e8s la 2.7.0 ?
\nAussi, par rapport \u00e0 la politique de d\u00e9pr\u00e9ciation \/ suppression de nos API\u00a0: est-ce que la prochaine version iTop LTS ne devra contenir aucune API d\u00e9pr\u00e9ci\u00e9e ?<\/p>\nCes questions restent ouvertes et en discussion avec nos clients et partenaires.<\/p>\n
Adoption des versions iTop<\/h2>\n
Aujourd\u2019hui, soit deux ans et demi apr\u00e8s la sortie de la version 2.7.0, environ\u00a080% de nos clients sont dans une version maintenue<\/strong>\u00a0(au sens corrections de bugs) et plus de 90% de nos clients sont sur les trois derni\u00e8res versions.<\/p>\n
![\"Long-term](\"https:\/\/blog.combodo.com\/wp-content\/uploads\/2022\/08\/itop-versions-300x280.png\")
<\/p>\nEn comparaison, en 2019 les\u00a02 derni\u00e8res versions majeures (2.6 et 2.5) ne repr\u00e9sentaient que 60%<\/strong>\u00a0des installations chez nos clients et les versions 2.4 et 2.3 repr\u00e9sentaient encore 34%.<\/p>\n
![\"repartition](\"https:\/\/blog.combodo.com\/wp-content\/uploads\/2022\/08\/Clipboard-16-septembre-2022-16_28-1-300x270.png\")
<\/p>\n<\/a>Conclusion<\/h2>\n
Si nous devons conclure en une phrase cette exp\u00e9rience \u00ab\u00a0long-term support\u00a0\u00bb, le recul nous montre que\u00a0le pari de la LTS a fonctionn\u00e9.<\/strong><\/p>\n
L\u2019adoption est ind\u00e9niable, malgr\u00e9 les difficult\u00e9s rencontr\u00e9es suite aux premi\u00e8res migrations et les risques de perte de confiance de nos utilisateurs. D\u2019autre part, combiner des versions short-term et long-term support a ind\u00e9niablement fait progresser Combodo dans la gestion des d\u00e9veloppements et des releases, tout comme son organisation interne.<\/p>\n
Capitalisons sur ces apprentissages pour le passage \u00e0 la prochaine LTS 3.X. Affaire \u00e0 suivre\u2026<\/p>\n
- des tests PHPunit nous informant des t\u00e2ches oubli\u00e9es (r\u00e9pertoire\u00a0test\/integration\/<\/a>\u00a0de notre d\u00e9p\u00f4t)<\/li>\n<\/ul>\n
- des scripts (r\u00e9pertoire\u00a0.make<\/a>\u00a0de notre d\u00e9p\u00f4t)<\/li>\n
- Pour la version 3.0.0 nous avons cr\u00e9\u00e9 une nouvelle page de notes de migration \u00ab\u00a0developer\u00a0\u00bb :\u00a0Migrate an Extension to 3.0<\/a>\n
- Des sessions de\u00a0formation<\/strong>\u00a0plus approfondies des \u00e9quipes internes ont \u00e9t\u00e9 organis\u00e9es
- Tout au long du d\u00e9veloppement de la version 3.0.0, des pr\u00e9sentations de l\u2019avancement ont \u00e9t\u00e9 faites, et aussi des\u00a0pr\u00e9sentations des fonctionnalit\u00e9s cl\u00e9s<\/strong><\/li>\n
- une liste des probl\u00e8mes connus sur notre Wiki,\u00a0<\/a>mise \u00e0 jour en cours de d\u00e9veloppement.<\/li>\n<\/ul>\n
- des annonces d\u00e9di\u00e9es sur Sourceforge<\/a><\/li>\n
- les\u00a0bugs \u00e0 l\u2019usage<\/strong>\u00a0: cette instance \u00e9tant utilis\u00e9e au quotidien dans l\u2019entreprise et sur l\u2019ensemble de ses fonctionnalit\u00e9s (Helpdesk, exports, datasynchro, \u2026) cela augmente la probabilit\u00e9 de d\u00e9celer les probl\u00e8mes rapidement !<\/li>\n<\/ul>\n
- beta2<\/a>\u00a0le 29\/01\/2020<\/li>\n<\/ul>\n
- 2.7.0-beta<\/a>\u00a0le 18\/12\/2019<\/li>\n
- 2.7.0-alpha1<\/a>\u00a0le 22\/10\/2019<\/li>\n