Retour d’expérience de mises à jour « 3.2 BibLibre » vers 3.8

J’ai expliqué ici-même en juillet dernier notre stratégie concernant la mise à disposition des nouveaux développements financés pour nos clients. Deux clients majeurs de BibLibre, l’université de Lyon 3 et le réseau de lecture publique du SAN-Ouest Provence sont retournés dans une version communautaire de l’application. L’université de Lyon 3 est passée en version 3.6 il y a quelques mois (et devrait très prochainement passer en 3.8), le SAN Ouest Provence en version 3.8 il y a quelques semaines. Ces deux clients sont représentatifs de la plupart des mises à jour que nous aurons à faire dans les mois qui viennent, l’objet de ce billet est de faire le point sur le déroulement de cette mise à jour. Celle-ci s’est déroulée en 4 étapes : La première a consisté à identifier les différences au niveau de la base de données entre la version 3.2 BibLibre et la version 3.8 communautaire. A partir de ces différences, nous avons développé des scripts et procédures spécifiques pour remettre la base de données en version « standard ». La deuxième étape a consisté à lister les fonctionnalités dont nos clients disposaient en version « 3.2 BibLibre » et qui ne sont pas disponibles, ou pas disponible à l’identique, dans la version communautaire. Ces différences sont nombreuses, mais, en dehors des changements dans les règles de circulation, elles sont mineures. En particulier, la moulinette SUDOC et le vendangeur fonctionnent correctement, après prise en compte de quelques « patches » qui sont maintenant intégrés dans la version 3.8 La troisième étape a consisté à effectuer une mise à jour du client sur un serveur de test. Dans cette étape, l’implication du client a été essentielle, les deux « pionniers » listés ci-dessus se sont très bien impliqués, cela a permis de résoudre un certain nombre de points. La quatrième étape fut la mise à jour de la plate-forme de production. Pour cette dernière, nous avons immobilisé la production durant une journée entière, afin de pouvoir faire la mise à jour paisiblement. Comme pour tout mise à jour majeure, nous avons ensuite été confrontés à des tickets d’incident sur notre plateforme de support. Soyons honnêtes, ceux-ci ont été plus nombreux qu’attendu, merci à ces deux « pionniers » qui nous ont permis d’avancer rapidement et de capitaliser pour faciliter la mise à jour des suivants. Nous pouvons classer ceux-ci en 4 catégories :

  • les tickets consécutifs à un changement fonctionnel dans l’application. Ces tickets se divisent en deux sous catégories :
    • les différences non identifiées lors de la deuxième étape
    • les nouveautés fonctionnelles de la version communautaire.
  • les tickets consécutifs à un bug dans l’application. Ils ont fait l’objet d’une remontée au niveau communautaire, voire, dans quelques cas, étaient déjà corrigés dans la version communautaire, le correctif a simplement été appliqué.
  • les « autres tickets ». Ceux-ci sont sans rapport avec la mise à jour (un problème de droits d’un bibliothécaire dans Koha par exemple), mais, intervenant au moment sensible d’une mise à jour majeure, viennent se confondre avec les problèmes liés à la mise à jour

Pour ce qui touche aux changements fonctionnels, nous avons rédigé deux documents que nous espérons maintenant complets, et que nous continuerons à compléter au fur et à mesure des mises à jour s’il le faut. Parfois, un changement est très mineur dans le code, mais nécessite un changement de pratique pour la bibliothèque. Par exemple, un champ enlevé ou rajouté dans une liste, un filtre automatiquement appliqué à l’ouverture de la page là ou il fallait une validation précédemment,… En conclusion, la mise à jour en version 3.8 apporte de nombreuses nouveautés, ce qui s’annonce pour la prochaine version majeure (3.10 ou peut-être 4.0, ce n’est pas encore « gravé dans le marbre ») est très excitant et sera nettement plus simple à mettre en place chez ces clients. Les péripéties consécutives à la mise à jour passées, nous estimons que notre choix de remettre tous nos clients dans une version communautaire se trouve conforté : les pertes (fonctionnelles) sont minimes, les gains d’ores et déjà évidents, et les promesses incomparables.

Share

A propos Paul Poulain

Ingénieur en Informatique, Paul a travaillé pour l’assurance maladie et, à la fin des années 1990, dans une start-up du secteur de la vente en ligne. Il s’implique dans des projets de logiciels libres depuis 1998. Depuis 2001, Paul œuvre à faire connaître les logiciels libres dans le monde des bibliothèques. Contributeur aux développements de Koha depuis fin 2001, Paul s’est impliqué à temps plein dans ce projet dès 2002. Il en est l’un des plus importants développeurs, ayant en particulier mis en œuvre la gestion des formats MARC. Il a été « Release Manager » pour les version 2.0, 2.2 (de 2003 à 2005), 3.8 et 3.10 (entre novembre 2011 et novembre 2012) Tel : +33-(0)491813508

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *