Odoo.sh per a partners: dev, staging i producció sense trencar res al client

La regla que evita la majoria dels ensurts a Odoo.sh cap en una frase: res no arriba a producció sense un build verd sobre una còpia real de la base del client, amb el mateix commit que es fusionarà. La documentació explica la plataforma, no el flux d'un partner. Aquí hi ha el nostre.

Tres etapes, i què fa de debò cadascuna

Odoo.sh té tres etapes: producció (una sola branca), staging i desenvolupament. La diferència és amb quina base arrenca cada build:

• Desenvolupament: base nova amb demo, instal·la els mòduls de la branca i executa els tests; dura uns tres dies. És l'única etapa que testeja: els tests depenen de la demo.
• Staging: el build duplica la base de producció i la neutralitza. La còpia s'esborra al cap d'un mes.
• Producció: el push reinicia el servidor; si has pujat la versió del mòdul a __manifest__.py, executa l'update (equival a -u) i la instància queda en manteniment. Si falla, torna a la revisió anterior i restaura la base.

D'aquí la conseqüència que gairebé ningú no llegeix: fusionar porta el codi, mai el que has tocat a mà a la base de staging. El que vulguis que arribi va en XML del mòdul, amb la versió pujada.

Estructura de branques per a un partner

Amb un sol client n'hi ha prou amb dev, staging i producció. Amb diversos: una branca de desenvolupament per tasca; una de staging per client i lliurament, reconstruïda abans de cada validació; l'única de producció que imposa Odoo.sh; i, si el mòdul va a l'App Store, una per versió d'Odoo.

Al nostre repositori hi ha avui 144 branques, entre elles 17.0, 18.0, 19.0 i production: 41 porten el sufix -17, -18 o -19 (un connector, una versió) i 19 són production-pre-<cambio>-<fecha>: el commit que corria producció abans de cada desplegament delicat. Tornar enrere és un push.

El build com a porta: què comprova i què no

Un build és verd (sense errors ni avisos), groc (avisos) o vermell (errors); només el verd es lliura. Un de desenvolupament comprova que els mòduls de la branca s'instal·len en una base neta amb demo i que els seus tests passen. El que no comprova:

• Mòduls fora de la branca. Per defecte instal·la només els teus, sense submòduls. Als ajustos: instal·lació completa (submòduls i tots els estàndard, però sense tests) o una llista de noms tècnics separats per comes, que és la útil.
• L'upgrade. Instal·la des de zero; mai no executa -u sobre una base amb historial.
• Les dades reals. Això és staging, que no executa tests.

Per això la porta té dues fulles: el build de desenvolupament executa tests que instal·len, no només unitaris; i la branca de staging executa l'upgrade real sobre la còpia de producció, llegint update.log fins al final. Mira la línia 0 failed, 0 error(s) of N tests amb N més gran que zero: un verd de zero tests és buit. Més causes, a un mòdul d'Odoo 19 compila però no s'instal·la.

Staging amb dades: què resol la còpia i què no

La neutralització resol el perillós: no surten correus (es veuen a la pestanya Mails), no corren les tasques programades, els IAP queden fora, transportistes i passarel·les van en mode test, i neutralize.log diu què s'ha apagat. El que no resol:

• Anonimitzar continua sent cosa teva. Apaga processos, no esborra dades personals. Si l'equip no ha de veure dades del client: Developer no accedeix ni a staging ni a producció, Tester sí a staging i només Admin a producció.
• Les credencials d'APIs externes viatgen a la còpia. Un connector a staging amb les claus de producció parla amb Amazon o Mirakl com si ho fos: activa el seu mode sandbox o buida les claus.
• La base de staging no es refresca sola. Per defecte la branca actualitza el build anterior i la base sobreviu entre pushes, amb les dades ja tocades; amb New build, cada push parteix d'una còpia fresca. Els crons es disparen a mà, i els backups manuals duren tres dies, amb un màxim de cinc al dia.

SSH i psql a producció: què es toca i què no

Odoo.sh dona shell a producció. Hi entrem per llegir (psql, lnav ~/logs/odoo.log), diagnosticar amb odoo-bin shell i executar la suite d'un mòdul en mode transaccional. El que no es fa: un UPDATE a mà ni instal·lar mòduls saltant-se el build. Detalls que costen una tarda: scp i sftp estan bloquejats, el rol de Postgres no pot crear bases i els mòduls propis viuen sota ~/src/user. Un alleujament: odoo-bin shell fa rollback en sortir a 17, 18 i 19 (odoo/cli/shell.py).

Upgrade a producció: noupdate, base.group_system i migracions

Un upgrade es dispara pujant la versió al manifest; Odoo.sh fa un backup marcat com a Update (també si canvia requirements.txt) i executa el -u. Aquí hi viu la trampa més cara que hem tingut. L'idioma habitual perquè l'administrador hereti el teu grup és:

<record id="base.group_system" model="res.groups">
    <field name="implied_ids" eval="[(4, ref('group_mi_manager'))]"/>
</record>

Funciona en una instal·lació nova i en un upgrade s'ignora en silenci. El motiu és a la base del client: noupdate viu a la fila de ir_model_data. En actualitzar, el carregador només reescriu el registre if not (update and d_noupdate) (odoo/orm/models.py a la 19, odoo/models.py a 17 i 18), i l'upsert que manté aquesta taula refresca model i res_id però mai la columna noupdate: un cop posada, no es treu. I no es dedueix de l'addon: a les tres versions el record de base.group_system és en un <data> sense noupdate i tot i així pot arribar marcat:

select name, noupdate from ir_model_data
 where module='base' and name in ('group_system','group_user');

A la nostra producció d'Odoo.sh retorna t en les dues; a les 69 bases que el nostre banc de proves ha creat des de zero, group_user surt t i group_system, f. El mateix XML, dos resultats.

Ens va passar al nostre connector de Mirakl 16.15.0: les credencials van passar a un grup «Mirakl Manager». En instal·lacions noves l'administrador l'heretava; en les actualitzades va quedar sense membres i ningú no podia tocar les claus. Els tests eren verds perquè una instal·lació neta sí que aplica el record. L'arranjament, a 16.15.1: deixar l'XML i afegir migrations/19.0.16.15.1/post-migrate.py, que escriu la implicació en SQL sobre res_groups_implied_rel i res_groups_users_rel amb ON CONFLICT DO NOTHING, més un test que falla si el grup es queda buit.

Les migracions: carpeta migrations/<versión>/ amb fitxers pre-*.py, post-*.py i end-*.py, cadascun amb migrate(cr, version), on version és la que hi havia instal·lada. Odoo només les executa quan el mòdul està marcat per actualitzar: en una instal·lació nova no en corre cap, per això l'XML fa falta. Si canvia la versió major, el procés és un altre: errors de migració a Odoo 19 i la checklist de go-live.

Trampes que no surten a la documentació

• Builds que s'adormen. Un build de desenvolupament sense ús hiberna i els seus crons no corren. Si l'uses com a banc de proves, mantén-lo despert: tenim un agent de launchd que cada 240 segons fa curl /web/health i ssh -n … true contra cada build.
• El build que valides pot ser el vell. L'identificador canvia amb cada push i l'anterior triga a reciclar-se: per SSH en conviuen dos. Abans de donar res per bo, grep del que acabes de canviar a ~/src/user.
• La sèrie del manifest falla diferent en cada sentit. A la 19, un manifest 18.0.x o 17.0.x no rebenta: el servidor avisa has an incompatible version, setting installable=False. Al revés, a la 17 o la 18, un 19.0.x.y.z talla la lectura amb invalid manifest.

Checklist de lliurament al client

1. Build verd (no groc) en desenvolupament, amb tests que instal·len i N més gran que zero.
2. Staging reconstruït avui des de producció; credencials externes en sandbox o buides.
3. Versió pujada al manifest i update.log llegit fins al final, migracions incloses.
4. Validació del client a staging, amb els crons a mà i els correus revisats a Mails.
5. Branca production-pre-<cambio>-<fecha> des del commit que corre producció, i backup manual si toca dades.
6. Fusió fora d'hores punta i, després, odoo.log, el grup de permisos amb membres i els crons actius.

Aquest flux l'oferim com a enginyeria Odoo per a consultories i l'usem a cada implantació i migració a Odoo 19. Si ets partner o casa de programari, el programa de partners tecnològics explica com treballem.

Si el que tens és un ecommerce

Tocar un connector de marketplace o una regla d'estoc a producció és jugar amb comandes reals: etiquetes duplicades, comandes importades dues vegades, sincronitzacions a mitges. Per staging passen els mòduls nous, els canvis d'estoc i les actualitzacions de connectors (Amazon, Mirakl, ManoMano, SEUR, MRW, Correos Express), i allà transportistes i passarel·les van en mode test: és on provar una etiqueta sense que surti la furgoneta.

Preguntes freqüents

Enllaços útils dins de FlexigoTech

El que fem sobre això