Odoo.sh für Partner: Dev, Staging und Produktion, ohne beim Kunden etwas zu beschädigen

Die Regel, die in Odoo.sh die meisten Schrecksekunden verhindert, passt in einen Satz: Nichts gelangt in die Produktion ohne einen grünen Build auf einer echten Kopie der Kundendatenbank, mit demselben Commit, der gemergt werden soll. Die Dokumentation erklärt die Plattform, nicht den Workflow eines Partners. Hier ist unserer.

Drei Stufen und was jede wirklich tut

Odoo.sh hat drei Stufen: Produktion (nur ein Branch), Staging und Entwicklung. Der Unterschied liegt darin, mit welcher Datenbank jeder Build startet:

• Entwicklung: neue Datenbank mit Demodaten, installiert die Module des Branches und führt die Tests aus; sie besteht etwa drei Tage. Es ist die einzige Stufe, die testet: Die Tests hängen von den Demodaten ab.
• Staging: Der Build dupliziert die Produktionsdatenbank und neutralisiert sie. Die Kopie wird nach einem Monat gelöscht.
• Produktion: Der Push startet den Server neu; wenn Sie die Modulversion in __manifest__.py erhöht haben, führt er das Update aus (entspricht -u) und die Instanz geht in den Wartungsmodus. Schlägt es fehl, kehrt er zur vorherigen Revision zurück und stellt die Datenbank wieder her.

Daraus folgt, was fast niemand liest: Das Mergen überträgt den Code, nie das, was Sie von Hand in der Staging-Datenbank verändert haben. Was ankommen soll, gehört ins XML des Moduls, mit erhöhter Version.

Branch-Struktur für einen Partner

Mit nur einem Kunden genügen Dev, Staging und Produktion. Mit mehreren: ein Entwicklungs-Branch pro Aufgabe; ein Staging-Branch pro Kunde und Lieferung, vor jeder Abnahme neu aufgebaut; der einzige Produktions-Branch, den Odoo.sh vorschreibt; und, wenn das Modul in den App Store geht, einer pro Odoo-Version.

In unserem Repository gibt es heute 144 Branches, darunter 17.0, 18.0, 19.0 und production: 41 tragen das Suffix -17, -18 oder -19 (ein Konnektor, eine Version) und 19 sind production-pre-<cambio>-<fecha>: der Commit, der vor jedem heiklen Deployment in der Produktion lief. Zurückgehen ist ein Push.

Der Build als Tor: was er prüft und was nicht

Ein Build ist grün (ohne Fehler und Warnungen), gelb (Warnungen) oder rot (Fehler); nur Grün wird ausgeliefert. Ein Entwicklungs-Build prüft, dass die Module des Branches in einer sauberen Datenbank mit Demodaten installiert werden und ihre Tests bestehen. Was er nicht prüft:

• Module außerhalb des Branches. Standardmäßig installiert er nur Ihre eigenen, ohne Submodule. In den Einstellungen: vollständige Installation (Submodule und alle Standardmodule, aber ohne Tests) oder eine kommagetrennte Liste technischer Namen, was die nützliche Variante ist.
• Das Upgrade. Er installiert von Grund auf; er führt -u nie auf einer Datenbank mit Historie aus.
• Die echten Daten. Das ist Staging, das keine Tests ausführt.

Deshalb hat das Tor zwei Flügel: Der Entwicklungs-Build führt Tests aus, die installieren, nicht nur Unit-Tests; und der Staging-Branch führt das echte Upgrade auf der Produktionskopie aus und liest update.log bis zum Ende. Achten Sie auf die Zeile 0 failed, 0 error(s) of N tests mit N größer als null: Ein Grün mit null Tests ist leer. Weitere Ursachen in Ein Odoo-19-Modul kompiliert, lässt sich aber nicht installieren.

Staging mit Daten: was die Kopie löst und was nicht

Die Neutralisierung löst das Gefährliche: Es werden keine E-Mails versendet (sie erscheinen im Tab Mails), die geplanten Aktionen laufen nicht, die IAP bleiben außen vor, Zusteller und Zahlungsanbieter laufen im Testmodus, und neutralize.log sagt, was abgeschaltet wurde. Was sie nicht löst:

• Anonymisieren bleibt Ihre Aufgabe. Sie schaltet Prozesse ab, löscht aber keine personenbezogenen Daten. Wenn das Team keine Kundendaten sehen soll: Developer hat weder auf Staging noch auf Produktion Zugriff, Tester nur auf Staging und nur Admin auf Produktion.
• Die Zugangsdaten externer APIs wandern mit der Kopie. Ein Konnektor in Staging mit den Produktionsschlüsseln spricht mit Amazon oder Mirakl, als wäre er die Produktion: Aktivieren Sie seinen Sandbox-Modus oder leeren Sie die Schlüssel.
• Die Staging-Datenbank aktualisiert sich nicht von selbst. Standardmäßig aktualisiert der Branch den vorherigen Build und die Datenbank überlebt zwischen den Pushes, mit den bereits veränderten Daten; mit New build startet jeder Push von einer frischen Kopie. Die Crons werden von Hand ausgelöst, und manuelle Backups halten drei Tage, mit höchstens fünf pro Tag.

SSH und psql in der Produktion: was man anfasst und was nicht

Odoo.sh gibt Shell-Zugriff auf die Produktion. Wir gehen hinein, um zu lesen (psql, lnav ~/logs/odoo.log), mit odoo-bin shell zu diagnostizieren und die Suite eines Moduls im Transaktionsmodus auszuführen. Was man nicht tut: ein UPDATE von Hand oder Module am Build vorbei installieren. Details, die einen Nachmittag kosten: scp und sftp sind gesperrt, die Postgres-Rolle kann keine Datenbanken anlegen, und eigene Module liegen unter ~/src/user. Eine Erleichterung: odoo-bin shell macht beim Beenden in 17, 18 und 19 ein Rollback (odoo/cli/shell.py).

Upgrade in der Produktion: noupdate, base.group_system und Migrationen

Ein Upgrade wird ausgelöst, indem man die Version im Manifest erhöht; Odoo.sh erstellt ein als Update markiertes Backup (auch wenn sich requirements.txt ändert) und führt das -u aus. Hier steckt die teuerste Falle, die wir hatten. Die übliche Formulierung, damit der Administrator Ihre Gruppe erbt, lautet:

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

Sie funktioniert bei einer Neuinstallation und wird bei einem Upgrade stillschweigend ignoriert. Der Grund liegt in der Kundendatenbank: noupdate steht in der Zeile von ir_model_data. Beim Aktualisieren überschreibt der Loader nur den Datensatz if not (update and d_noupdate) (odoo/orm/models.py in 19, odoo/models.py in 17 und 18), und das Upsert, das diese Tabelle pflegt, aktualisiert Modell und res_id, aber nie die Spalte noupdate: Einmal gesetzt, wird sie nicht mehr entfernt. Und es lässt sich nicht aus dem Addon ableiten: In allen drei Versionen steht der Record von base.group_system in einem <data> ohne noupdate und kann trotzdem markiert ankommen:

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

In unserer Odoo.sh-Produktion liefert es in beiden t; in den 69 Datenbanken, die unser Testsystem von Grund auf erstellt hat, ergibt group_user t und group_system, f. Dasselbe XML, zwei Ergebnisse.

Es passierte uns in unserem Mirakl-Konnektor 16.15.0: Die Zugangsdaten wurden in eine Gruppe «Mirakl Manager» verlegt. Bei Neuinstallationen erbte der Administrator sie; bei den aktualisierten blieb sie ohne Mitglieder und niemand konnte die Schlüssel anfassen. Die Tests waren grün, weil eine saubere Installation den Record sehr wohl anwendet. Die Lösung, in 16.15.1: das XML belassen und migrations/19.0.16.15.1/post-migrate.py hinzufügen, das die Implikation per SQL auf res_groups_implied_rel und res_groups_users_rel mit ON CONFLICT DO NOTHING schreibt, dazu ein Test, der fehlschlägt, wenn die Gruppe leer bleibt.

Die Migrationen: Ordner migrations/<versión>/ mit den Dateien pre-*.py, post-*.py und end-*.py, jeweils mit migrate(cr, version), wobei version die installierte Version ist. Odoo führt sie nur aus, wenn das Modul zum Aktualisieren markiert ist: Bei einer Neuinstallation läuft keine, deshalb braucht es das XML. Wenn sich die Hauptversion ändert, ist der Prozess ein anderer: Migrationsfehler bei Odoo 19 und die Go-live-Checkliste.

Fallen, die nicht in der Dokumentation stehen

• Builds, die einschlafen. Ein ungenutzter Entwicklungs-Build geht in den Ruhezustand und seine Crons laufen nicht. Wenn Sie ihn als Testsystem nutzen, halten Sie ihn wach: Wir haben einen launchd-Agenten, der alle 240 Sekunden curl /web/health und ssh -n … true gegen jeden Build ausführt.
• Der Build, den Sie abnehmen, kann der alte sein. Die Kennung ändert sich mit jedem Push und der vorherige wird erst verzögert recycelt: Per SSH existieren zwei nebeneinander. Bevor Sie etwas für gut befinden, prüfen Sie mit grep das, was Sie gerade geändert haben, in ~/src/user.
• Die Serie des Manifests scheitert je nach Richtung anders. In 19 bricht ein Manifest 18.0.x oder 17.0.x nicht ab: Der Server warnt has an incompatible version, setting installable=False. Umgekehrt unterbricht in 17 oder 18 ein 19.0.x.y.z das Lesen mit invalid manifest.

Checkliste für die Übergabe an den Kunden

1. Grüner Build (nicht gelb) in der Entwicklung, mit Tests, die installieren, und N größer als null.
2. Staging heute aus der Produktion neu aufgebaut; externe Zugangsdaten in der Sandbox oder leer.
3. Version im Manifest erhöht und update.log bis zum Ende gelesen, Migrationen eingeschlossen.
4. Abnahme durch den Kunden in Staging, mit den Crons von Hand und den E-Mails in Mails geprüft.
5. Branch production-pre-<cambio>-<fecha> vom Commit, der in der Produktion läuft, und manuelles Backup, wenn Daten betroffen sind.
6. Merge außerhalb der Spitzenzeiten und danach odoo.log, die Berechtigungsgruppe mit Mitgliedern und die aktiven Crons.

Diesen Workflow bieten wir als Odoo-Engineering für Beratungshäuser an und nutzen ihn bei jeder Implementierung und Migration auf Odoo 19. Wenn Sie Partner oder Softwarehaus sind, erklärt das Technologiepartner-Programm, wie wir arbeiten.

Wenn Sie einen E-Commerce betreiben

Einen Marktplatz-Konnektor oder eine Bestandsregel in der Produktion anzufassen, heißt mit echten Bestellungen zu spielen: doppelte Etiketten, zweimal importierte Bestellungen, halbe Synchronisationen. Über Staging laufen die neuen Module, die Bestandsänderungen und die Konnektor-Updates (Amazon, Mirakl, ManoMano, SEUR, MRW, Correos Express), und dort laufen Zusteller und Zahlungsanbieter im Testmodus: Hier testen Sie ein Etikett, ohne dass der Lieferwagen losfährt.

Häufige Fragen

Nützliche Links bei FlexigoTech

Was wir dazu anbieten