Déployer : staging puis production

Pourquoi la production est fermée

claude2odoo refuse le passage en production tant qu'il n'existe pas un passage en staging à la fois réussi et validé. Ce n'est pas un avertissement qu'on écarte d'un clic : un avertissement qu'on peut ignorer ne protège de rien le jour où l'on est pressé — et c'est le seul jour où ça compte.

Deux autres refus, pour la même raison :

• La branche de production ne peut pas être la même que celle de staging. Il n'y aurait pas d'étape intermédiaire, donc rien à valider.
• Le passage en production demande de recopier le nom du projet. Un clic ne doit pas suffire.

Ce que « validé » veut dire ici : quelqu'un a regardé le résultat tourner ailleurs qu'en production, et l'a dit. Le staging d'Odoo.sh tourne sur un duplicata neutralisé de vos données réelles — c'est ce qui rend l'essai crédible.

Le cycle, à l'écran

1. Préparer le passage en staging. Le plan est enregistré tel quel : c'est ce que vous devez dérouler, dans cet ordre.
2. Dérouler les commandes — en SSH, ou depuis l'onglet Shell de la branche.
3. Marquer le résultat : réussi, ou échoué.
4. Valider le passage réussi. C'est ce geste, et lui seul, qui ouvre la production.
5. Préparer le passage en production, en recopiant le nom du projet.

Le plan, commande par commande

0. Sauvegarder la base — production seulement

En premier, avant toute écriture. Une sauvegarde prise après coup ne sauve rien. C'est la seule étape du plan qui ne sert que si tout le reste échoue, et c'est la raison pour laquelle elle est en tête.

1. git push … HEAD:<branche>

Odoo.sh reconstruit à partir de la branche. La commande affichée nomme la branche telle qu'elle s'appelle chez vous : elle est faite pour être recopiée. Le nom du remote, lui, est celui de votre copie locale — adaptez si le vôtre s'appelle origin.

2. odoo-bin -u <module> --stop-after-init — règle C1

Charger les nouvelles vues et données. C'est le piège le plus fréquent du chantier d'origine, et l'auteur de la règle y est retombé après l'avoir écrite. Symptôme caractéristique : le curseur change mais le lien ne s'étend pas — le CSS est arrivé, la vue non.

Un redémarrage ne suffit pas. Un push d'assets non plus.

3. theme.reapply() sur chaque site concerné — règle C2

Recopier depuis theme_ir_ui_view vers les vues du site. Sur un site multi-instances, chaque site concerné doit y passer.

4. Vider le cache QWeb du worker — règle C4

Une vue écrite depuis un odoo-bin shell séparé reste ignorée par le worker en cours : il sert ses templates compilés. Tant qu'il n'a pas vidé son cache, votre écriture existe en base et pas à l'écran.

5. Supprimer les ir.attachment en /web/assets/% — règle C3

Purger le bundle pour que le nouveau CSS et le nouveau JS soient servis. Puis confirmer que la nouvelle règle est dans le bundle servi : deux règles parfaitement valides ont passé un tour entier à ressembler à de mauvais sélecteurs.

Un détail qui coûte des heures : le JS de page vit dans web.assets_frontend_lazy, pas dans web.assets_frontend_minimal. Chercher dans le mauvais bundle produit une attente sans fin.

Pourquoi cet ordre : C1 → C2 → C4 → C3

Les numéros de règles ne sont pas un ordre d'exécution. L'ordre vient de ce que chaque opération lit et de ce qu'elle écrit.

• C1 avant C2 — le reapply recopie depuis theme_ir_ui_view. Sans upgrade préalable, cette table contient encore l'ancienne version : le reapply la recopie fidèlement, et vous obtenez un déploiement propre de l'état d'avant. C'est une dépendance de données, pas une préférence de style.
• C4 après C1 et C2 — le cache QWeb doit être vidé après la dernière écriture de vue. Le reapply en est une. Vider avant, c'est laisser le cache se remplir à nouveau avec l'état intermédiaire, et croire qu'on a purgé.
• C3 en dernier — la règle ne dit pas seulement « purger », elle dit « purger, puis confirmer que la règle est dans le bundle servi ». Le bundle se reconstruit à la première requête qui en a besoin : le reconstruire avant que les vues soient en place, c'est reconstruire du périmé, et le vérifier alors ne prouve rien. La confirmation ne vaut que sur l'état final.

C1, C2 et C4 sont BLOQUANTES : les sauter, c'est déployer à moitié. C3 est un VÉRIFIER — elle ne casse rien, elle fait perdre du temps, et souvent beaucoup.

Le cas dispensé

Un déploiement qui ne touche que du SCSS, du CSS ou du JS est dispensé de l'upgrade et du reapply : purger le bundle suffit. Dès qu'un fichier de vue, de donnée ou de code Python entre dans le lot, la séquence complète redevient obligatoire.

C'est la seule dispense. Elle se juge sur les fichiers réellement modifiés, pas sur l'intention.

Avant de fusionner : ce qui disparaît

Une suppression massive de fichiers sous un même répertoire, sans que le manifeste parte, mérite aussi un regard : elle peut retirer des vues ou des données encore référencées en base.

Après le passage : mesurer, pas compter

La présence d'un nœud ne prouve rien. Sur le chantier d'origine, trois contrôles étaient au vert pendant que le texte était invisible.

Deux réflexes qui font gagner des heures :

• Sonder un sélecteur, jamais un libellé. Chercher « Invités » quand Odoo rend « Ajouter des invités » fait courir après une régression qui n'existe pas.
• Quand un contrôle tombe en panne, suspecter le contrôle. Trois fois sur le chantier d'origine, l'instrument avait tort et le code raison.

Le champ « URL publique du site » de l'audit lance cette mesure sur une page publique. C'est le moyen le plus rapide de vérifier un staging en ligne.

Et si le staging échoue

1. Marquez-le échoué. Un passage échoué reste dans l'historique : c'est ce qui permet de dire, plus tard, combien de tours il a fallu et pourquoi.
2. La production reste fermée. C'est le comportement attendu.
3. Corrigez, repoussez, préparez un nouveau passage. Rien ne se « rattrape » en sautant l'étape.

Supprimer le projet dans claude2odoo n'annule rien de ce qui a été déployé : ces vues vivent dans votre dépôt git, pas ici.

Suite