Livrer un module, de votre code à l'app

L'onglet Modules d'un environnement ressemble à un endroit où l'on installe des modules. Ce n'est presque jamais le cas, et la première minute passée ici est mieux employée à comprendre pourquoi.

Une fois ce point acquis, l'onglet se lit d'un coup d'œil : il vous dit ce que contient votre code, ce que contient réellement votre Odoo, et si les deux sont d'accord.

Vos modules viennent de votre code

Les boutons Installer et Désinstaller de chaque carte sont inactifs. Votre ensemble de modules appartient à votre dépôt, pas à un bouton de cette page : ce qui est dans la branche est ce qui est construit dans l'image, et ce qui est dans l'image est ce que votre Odoo peut exécuter.

C'est cette contrainte qui rend un environnement reproductible. Si l'on pouvait ajouter des modules à la main ici, deux environnements construits depuis le même commit ne contiendraient pas forcément la même chose — et ni la copie que vous créez pour tester, ni la restauration que vous lancez après un incident ne vous rendraient ce que vous aviez.

La boucle est donc : modifier le code, construire et déployer la branche, puis aligner la base. Cet onglet est la dernière étape de cette boucle, pas un raccourci qui la contourne.

Dans l'app, ou dans la branche

Chaque module détecté dans votre branche porte l'un de deux badges, et la différence décide de ce que vous pouvez faire ensuite.

Synchroniser depuis le dépôt réanalyse la branche : c'est ce qui fait apparaître ici un module que vous avez poussé il y a cinq minutes. Cette action lit votre code ; elle ne change rien dans l'environnement.

Faire passer un module de Dans la branche à Dans l'app demande un build et un déploiement, pas une action sur cet onglet. C'est le sens de la ligne sous la carte : déployez la branche pour le rendre installable.

Actualiser la liste d'Odoo

Odoo ne relit pas son chemin d'addons à chaque démarrage. Il tient sa propre liste de modules connus, et un module arrivé avec votre dernier déploiement peut très bien être dans l'image alors qu'Odoo n'en sait encore rien.

Actualiser la liste Odoo lui demande de regarder à nouveau. L'analyse s'exécute à l'intérieur de l'environnement en marche et peut dépasser la minute : le bouton ne l'attend donc pas, il lance le balayage et les badges Dans l'app se mettent à jour tout seuls peu après.

Utilisez-le quand un module que vous savez déployé n'apparaît pas comme présent dans l'app. Si l'environnement est arrêté, l'analyse ne peut pas s'exécuter du tout, et le message le dit.

Mettre à jour les modules

Mettre à jour les modules lance la migration de base pour tous les modules installés de cet environnement — le -u all d'Odoo. C'est ce dont un déploiement de code a besoin ensuite : le déploiement livre le nouveau code, ceci met le schéma et les données de la base en accord avec lui.

À côté du bouton se trouve un sélecteur de version, et les deux fonctionnent ensemble. Choisir une version la met en service puis migre dessus, dans cet ordre, en une seule opération. Séparer les deux en deux actions distinctes est exactement la façon dont un environnement finit par servir une version alors que sa base porte encore le schéma d'une autre — un état qui produit des erreurs que personne ne sait expliquer, ni d'un côté ni de l'autre. Laisser le sélecteur sur la version en service aujourd'hui migre vers ce qui tourne déjà, sans rien déployer.

Deux choses méritent d'être sues avant de cliquer :

• Si la version choisie ne peut pas être mise en service, aucune migration n'est lancée. Vous obtenez une exécution en échec qui le dit précisément, plutôt qu'une migration appliquée en silence contre la version que vous étiez en train de remplacer.
• L'environnement est brièvement perturbé pendant la migration. En cas de doute sur le changement, prenez d'abord une sauvegarde depuis l'onglet Sauvegardes — voir le guide sur la duplication d'un environnement pour tester.

Une seule mise à jour s'exécute à la fois par environnement. En demander une deuxième pendant qu'une autre est en cours vous rend celle qui tourne déjà, au lieu d'empiler deux migrations sur la même base.

Ce que la mise à jour laisse derrière elle

Une migration prend plusieurs minutes, et vous avez le droit de partir. L'exécution est enregistrée, pas seulement annoncée : son résultat est écrit et survit à un rechargement, à une déconnexion et à un changement de machine.

Cela compte surtout en cas d'échec. L'exécution ratée conserve l'erreur d'Odoo elle-même — le modèle, le champ, la vue qui n'a pas pu être validée — et la fin de son journal de migration en dessous. Un résumé rédigé par la plateforme vous dirait que la mise à jour a échoué, ce que vous savez déjà ; seule la ligne d'Odoo vous dit laquelle de vos vues référence un champ que vous avez supprimé.

L'historique est replié par défaut et s'ouvre sur l'exécution la plus récente. Une exécution qui a migré ce qui était déjà déployé porte la mention version en service, plutôt qu'une case vide — un blanc se lirait comme une donnée manquante et non comme un choix que quelqu'un a fait.

Quand Odoo refuse tout

Un jour, l'onglet aura l'air normal et plus rien ne fonctionnera. Les installations sont refusées, les mises à jour ne font rien, et dans Odoo même ses propres modules de base ont leurs boutons grisés.

C'est Odoo qui se protège. Quand un module reste dans un état transitoire — to install, to upgrade, to remove — Odoo refuse toute opération de module sur cette base tant que l'état n'est pas résolu. Cela arrive quand une installation est interrompue : un redémarrage au mauvais moment, ou un module absent du chemin des addons au moment où Odoo est allé le chercher.

Débloquer annule ces opérations. Il ne les termine pas — les terminer reviendrait à relancer l'installation qui a déjà échoué. Chaque module retourne là où il était : celui qui était en cours d'installation redevient non installé, celui qui était en cours de mise à jour ou de suppression reste installé. Rien n'est installé, rien n'est supprimé, aucune donnée n'est touchée, et vous pourrez relancer l'installation ensuite.

C'est un bouton et non une réparation automatique. Annuler une opération que quelqu'un est peut-être en train de diagnostiquer est votre décision, et cela écrit dans votre base Odoo.

Ce que cet onglet ne fait pas

Il n'installe pas un module dans Odoo pour la première fois. Une fois qu'un module est Dans l'app et que la liste d'Odoo a été actualisée, vous l'installez depuis Odoo lui-même, dans son écran Applications — cet onglet le suit ensuite et le maintient migré.

Sur un environnement multi-tenant, le sélecteur de version et Mettre à jour les modules ne sont pas proposés du tout. Vos bases clientes sont migrées par la vague de mise à niveau, qui les fait avancer dans un ordre maîtrisé et tient son propre historique ; les migrer toutes d'un coup depuis ici est précisément ce qu'il ne faut pas faire.

Et il ne touche jamais un autre environnement. Chaque environnement porte sa propre base, sa propre image et ses propres états de modules — c'est pour cela que la copie de test que vous migrez d'abord vous apprend quelque chose sur la production que vous migrerez ensuite.