Staging (Odoo.sh)
Kurz gesagt
Bei Odoo.sh ist Staging die mittlere der drei Zweigstufen: Dort legt die Plattform zum Zweig eine Datenbank an, ein neutralisiertes Duplikat der Produktionsdatenbank (Dokumentation 20.0, Stand 14. Oktober 2026). Darin prüfen Sie Änderungen an echten Daten, ohne den Echtbetrieb zu verändern. Die Datenbank löscht Odoo.sh einen Monat nach dem Anlegen automatisch; der Zweig selbst liegt in Ihrem GitHub-Repository.
Das Wichtigste
- Zweigstufe zwischen Entwicklung und Produktion; je Odoo.sh-Projekt gibt es genau einen Produktionszweig.
- Die Staging-Datenbank ist ein neutralisiertes Duplikat der Produktionsdatenbank, gedacht für Tests mit Produktivdaten.
- Odoo.sh löscht die Datenbank eines Staging-Zweigs einen Monat nach dem Anlegen; danach bauen Sie den Zweig neu auf (Rebuild).
- Der Zweig selbst liegt im GitHub-Repository; eine Ablauffrist dafür nennt die Dokumentation 20.0 nicht.
- Neutralisiert heißt: geplante Aktionen aus, E-Mails im Mail-Catcher, IAP-Dienste aus, Zahlung und Versand im Testmodus.
Staging ist bei Odoo.sh die mittlere der drei Stufen, in die ein Zweig des Projekts eingeordnet wird (deutsch Zweig, englisch Branch). Die Stufe bestimmt, welche Datenbank Odoo.sh zu diesem Zweig anlegt: auf Staging eine zweite Datenbank mit den Daten des Echtbetriebs, in der Sie Änderungen prüfen, ohne die Produktionsdatenbank zu verändern. Die Zuordnung wechseln Sie, indem Sie den Zweig in der Ansicht Zweige per Drag and Drop in den gewünschten Abschnitt ziehen.
Wozu eine Staging-Umgebung dient
Die Kopie trägt die Produktivdaten und ist neutralisiert. Neutralisiert bezieht sich auf die Funktionen, die die Dokumentation im Abschnitt Staging selbst nennt: Geplante Aktionen sind deaktiviert, ausgehende E-Mails fängt ein Mail-Catcher ab, IAP-Dienste sind aus, Zahlungsanbieter und Versandkonnektoren laufen im Testmodus. Automatische Sicherungen gibt es für Staging-Datenbanken nicht; manuelle sind möglich, und eine Sicherung der Produktionsdatenbank können Sie in einen Staging-Zweig einspielen. Beim Zusammenführen in den Produktionszweig wandert nur der Quellcode.
Wie lange die Staging-Umgebung besteht
Datenbanken, die für Staging-Zweige erstellt wurden, löscht Odoo.sh nach einem Monat automatisch; danach müssen Sie den Zweig neu aufbauen (Rebuild). Die Frist beginnt laut Dokumentation mit dem Anlegen der Datenbank. Eine Ablauffrist für den Zweig selbst nennt die Seite nicht, denn der Zweig liegt in Ihrem GitHub-Repository. In einem Testprojekt kommt eine zweite Frist hinzu: Nach 30 Tagen setzt Odoo.sh den Produktionszweig und alle Staging-Zweige automatisch in die Entwicklungsphase zurück.
Beispiel
Beispiel mit erfundenen Daten: Sie ändern eine Formularansicht, pushen den Commit in einen Zweig und ziehen ihn auf Staging. Odoo.sh legt die Datenbank aus der Produktion an, E-Mails landen im Mail-Catcher; nach dem Test ziehen Sie den Zweig in den Produktionszweig, und nur der Code wandert mit. Einen Monat nach dem Anlegen ist die Staging-Datenbank abgeräumt; für einen zweiten Testlauf bauen Sie den Zweig neu auf.
Grundlage
Der Begriff steht in der Anbieterdokumentation von Odoo S.A. und ist keine gesetzliche Kategorie. Maßgeblich ist die Dokumentation 20.0, Seite Zweige (Branches), Abschnitt Staging, gelesen am 14. Oktober 2026; die Dokumentationswurzel leitet auf die Version 20.0 weiter.
Nicht zu verwechseln mit
- Entwicklung (Development): je Push eine neue Datenbank mit Demodaten und standardmäßig Unit-Tests; die Datenbank ist für rund drei Tage gedacht.
- Produktion (Production): die Datenbank des Echtbetriebs; je Projekt gibt es genau einen Produktionszweig, und Odoo.sh sichert ihn automatisch.
- Testumgebung: der allgemeine Begriff für alle Hostingmodelle; wie sie bei Odoo Online und auf einem eigenen Server entsteht, steht unter Testumgebung für Odoo, die Fristen im Detail unter Staging-Branches.
- Runbot: Odoos Testinfrastruktur für Änderungen am Produktcode, nicht für Ihre Projektdaten (Runbot).