2 coops ont rencontrés 2 problèmes qui soulignent des difficultés à disposer d’un code stable et à jour.
Je suis peu aux faits des aspects techniques détaillées (et je m’en remets à ceux qui ont travaillé dessus pour me reprendre et apporter des infos techniques complémentaires) mais je me permets de faire un petit récap d’une part pour partager l’info et d’autre part pour tenter d’en tirer quelques enseignements. N’hésitez pas non plus à nourrir la réflexion par vos questions.
Les deux problèmes rencontrés donc :
-
Le conteneur Docker Odoo contient une version de code qui est assez ancienne. Elle n’est pas compatible avec la version de code Odoo utilsée par La Louve. L’installation de modules de La Louve sur un code Odoo qui n’est pas celui utilisé par La Louve peut poser des problèmes.
-
Lors d’une mise à jour récente de nos modules à partir du github de la Louve nous avons rencontré un problème d’installation du module coefficients qui nous a causé quelques sueurs froides pendant plusieurs jours et nous a amené à demander aux utilisateurs d’arrêter d’utiliser Odoo. Nous redoutions une corruption de la base (nous avions des doublonse, en apparence). Heureusement que nous n’étions pas en production et que nous avions les compétences pour résoudre le problème. Evidemment… c’est compliqué à gérer un jour en semaine.
Une bonne nouvelle dans les deux cas : même si nous ça a provoqué pas mal de galères, cela nous a fait monter en compétences. Les problèmes ne s’étant pas produit sur des périodes de forte change (ex : vente)… on s’en sort avec du temps perdu et du stress mais sans gros dommages.
Ces problèmes nous sensibilisent aussi sur la prudence qui doit être la notre pour maintenir une cohérence et une intégrité de la base de données Odoo. Cela nous amène à travailler sur la question suivante que faire quand la base est corrompue : appel à de l’expertise en urgence, retour arrière, continuer au risque de se trainer « à vie » une base incohérente ?
Cela nous amène à réfléchir sur plusieurs aspects :
- au niveau de notre production informatique (de notre groupe info) : travailler sur le processus de mise à jour du code et sur la communication en cas de crise
- au niveau de l’intégration des mises à jour de code. Je crois qu’il nous faut comprendre que La Louve a externalisé les montés de version de code à son prestataire car… c’était beaucoup trop lourd à gérer pour l’équipe ERP de La Louve. On ne peut pas considérer qu’on pourrait facilement faire des mises à jour de code sur la base du répertoire Github mis à disposition par La Louve sans risque (pour plusieurs raisons car en plus nous n’avons pas les mêmes usages et pas les mêmes données). En conséquence, la question d’en passer par un intégrateur Odoo - comme le propose La Louve - me semble assez incontournable. C’est à discuter.
- dès qu’on arrive à un certain niveau d’activité, il me semble important de travailler sur les scénari de panne et de crise. Ce que je comprends c’est que la difficulté que nous avons rencontré - si elle s’était produite à La Louve - ne relèverai plus de l’intervention de l’équipe ERP de La Louve (les mise à jour de code sont confiées à un intégrateur). Pour autant il reste probablement d’autres scénari à étudier.
