Je suis en train d’évaluer AOS (v7.2.2) et j’ai vu sur certains sujets que les migrations entre versions peuvent être assez complexes. Vu que ces sujets datent un peu je rouvre celui ci pour avoir les dernières infos + bonnes pratiques.
J’ai vu que Axelor fournit une liste assez précise des modifications dans le changelog, et si j’ai bien compris pour les utilisateurs Open Source c’est à chacun de se débrouiller avec ces infos et mise à jour. Certains font des « diff » sur la base de données pour voir les 2 versions pour comprendre les modifications entre les versions.
Mais du coup :
est-ce que Axelor fournit un script d’upgrade pour la version « core » + les apps « natives », à lancer manuellement (ce qui permet d’en faire aussi le review pour comprendre les changements)
ou alors suffit-il de mettre à jour AOS pour qu’un script se déclenche au premier run ?
ou alors faut-il écrire ce script soit même (y compris les modifs des champs de base de données et cas de modification profonde sur les fields / modèles)
NB : je parle bien uniquement de la mise à jour d’une version qui serait « stock » (non personnalisée), bien évidemment que toute personnalisation / dev dédié ne peut pas être concernée par ce genre de script
Parmi les utilisateurs de la version Open Source, certains peuvent-il décrire leur workflow de migration étape par étape ?
Bonjour,
Quand je peux je me penche sur le sujet, mais je suis bloqué en v6 depuis 2 ans.
Peut-être que les boites magiques des IA pourront débloquer ma situation faute de budget.
Axelor a un énorme potentiel mais sans pouvoir MAJ quand on le veut, c’est ce qui est de pire pour une société. Tel un épais brouillard sur sa route, on ne sait pas où on va.
OK ! Par contre ces scripts existent forcément chez Axelor ? (certes j’imagine limité aux clients existants sous licence)
Les modifications apportées au Core / Apps par défaut étant gérées par Axelor, j’ai du mal à conceptualiser qui peut être en meilleure position pour faire cette mise à jour « principale » en impactant le moins de données possibles.
Bien évidemment sans concerner la mise à jour des apps custom et des modèles personnalisés, car pour ces dev spécifiques il va de soi que sans paiement il ne faut pas rêver et espérer un support.
Y a-t-il quelques groupes Open Source qui publient des scripts ? (et sur lesquels il serait possible de contribuer)
Quelle est la fréquence de besoin d’un script ? Entre chaque version majeure (v6 => v7) ou alors aussi entre les versions intermédiaire (par ex v7.1 => v7.2, etc…)
Quelqu’un aurait-il un exemple de script de migration (même ancien) avec la procédure utilisée pour que je puisse me rendre compte du boulot sur ces scripts + process global (ordre des remises à jour des différents composants et méthode) ?
Cependant l’analyse des changements de la base de données seule ne donne pas forcément la méthodologie pour migrer ces données (mais cela reste évidemment utile)
Si Axelor veut se développer de manière massive, il va falloir proposer un chemin de migration clair, également valable pour les Open Source. Au delà de la mise à jour du core, on pourrait aussi imaginer un pré-script de contrôle qui viendrait aussi analyser les plugins / custom apps.
J’ai vu dans certains changelog des modifications de nommage (pour uniformisation notamment) dans le core, ce pré-script pourrait rechercher dans les apps installées les termes et usages qui pourraient poser souci ou doivent être mis à jour…
La version Pro démarre à 10 utilisateurs (donc 350 euro / mois) cela exclut forcément beaucoup de TPE. Perso j’ai besoin d’un seul utilisateur, je peux dev certaines choses pour ajuste à mon business, mais payer 9 licences en plus pour avoir les mises à jour rend Axelor tout de suite moins compétitif
L analyse de changement de structure de la base donne le script à effectuer pour changer la structure . Faut aussi analyser les données à rajouter et avoir une politique de mise a jour ( toutes les versions , que les sous versions … )
Bon… du coup j’en retiens surtout que l’on peut rester bloqué sur une version pendant longtemps, et que plus on attend, plus il est probable d’y rester bloqué (l’effort pour en sortir vers la version à jour se cumulant avec toutes les mises à jour intermédiaires)
Autant je peux comprendre cette position d’un point de vue fonctionnel, mais il n’y a pas que cela dans une app. Il y aussi des mises à jour de sécurité, des corrections de bugs, etc… Laisser des systèmes pas à jour, c’est le risque de voir un jour des fuites de données, qui viendront indirectement ternir l’image de la solution.
Pour le moment je préfère donc stopper l’évaluation poussée de Axelor, car selon moi ce point est vital.
Dans les alternatives, il y a Odoo qui permet d’avoir accès aux mises à jour dès 1 seule licence utilisateur contre 10 chez Axelor (ou alors via OCA qui propose ces scripts en Open Source mais c’est très long) et je vais aussi évaluer ERPNext qui semble avoir une politique de mise à jour automatique du core.
Je garde évidemment un oeil sur Axelor, qui me semble ultra prometteur sur beaucoup de points, j’espère que ce problème de mises à jour pour les utilisateurs Open Source sera adressé.
Odoo a changé de modèle il y a quelques mois, maintenant ils ont une offre globale qui ne dépend plus des apps installées mais que du nombre d’utilisateurs :
à 30 euro / utilisateur / mois en « Standard » (hébergement mutualisé chez eux obligatoire, toutes les apps sauf Odoo Studio, pas de multi-entreprise)
a 37.40 euro / utilisateur / mois pour la version complète (possible en hébergement « On-Premise » et incluant toutes les apps. Il faut payer en plus si tu veux un cloud semi-dédié (odoo.sh)
Dans le cas des TPE (moins de 10 utilisateurs), ça fait une sacré différence de part cet effet de seuil de 10 utilisateurs minimum pour avoir accès à Axelor Pro (je pense qu’il y aurait tout intérêt à faire évoluer ce point)
Ah ok , je ne suis pas a la page . Cela semble pas mal , même si je suis pas fan d’Odoo ( avis personnel ) . En ce qui concerne mon entreprise , on est multi entreprises , multi devises , multi langues .
Oui idem je ne suis pas fan d’Odoo, surtout l’interface à la base mais je reconnais aussi qu’elle a favorablement évolué dans les 2 dernières versions (mais je n’ai jamais ré-évalué en profondeur)
Et la politique de (non) mise à jour des utilisateurs de la version Open Source est aussi une catastrophe. C’est un point que je n’arrive pas à comprendre, dans ce cas autant fermer le code… Bon l’ai l’impression que les 2 viennent de OpenERP, et ont donc peut être des contraintes de licence pour le faire.
Oui ,je n ai pas tester Odoo , et juste regarder une demo de ERPNEXT . Axelor j ai utilisé une instance de base dans mon emploi précédent , juste pour gérer les achats de matériel du service informatique , et c était opérationnel. Faut que je m installe une version 7.2.2 pour tester un peu plus et voir quelle stratégie de mon informatique d entreprise je peux remplacer , ajuster , integrer …