Odoo.sh: Staging-Branches und ihre Lebensdauer

Ein Staging-Zweig dient dem Test mit echten Daten: Odoo.sh legt dafür ein neutralisiertes Duplikat der Produktionsdatenbank an, in dem Sie gefahrlos arbeiten können. Die Frage nach der Lebensdauer betrifft deshalb weniger den Zweig als die Datenbank dahinter und die Sicherungen, die von ihr übrig bleiben. Die folgenden Fristen stehen in der Dokumentation 20.0, gelesen am 14. Oktober 2026.

Dieser Artikel behandelt Odoo.sh. Odoo Online und ein selbst betriebener Server haben eigene Regeln für Testumgebungen, die Testumgebung für Odoo: Staging und Kopien zusammenstellt.

Worauf es ankommt

Odoo.sh ist laut eigener Dokumentation die offizielle Cloud-Plattform von Odoo für das Hosten und Verwalten von Odoo-Anwendungen. Ihr Projekt hängt an einem GitHub-Repository; daraus baut die Plattform Datenbanken in drei Stufen: Produktion, Staging und Entwicklung. In der Ansicht Zweige (Branches) ordnen Sie einen Zweig per Drag and Drop einer Stufe zu. Einen Produktionszweig gibt es je Projekt nur einen.

Weil eine Staging-Datenbank die Produktivdaten enthält, ist sie neutralisiert: geplante Aktionen sind abgeschaltet, ausgehende E-Mails fängt ein Mail-Catcher ab, IAP-Dienste sind aus, Zahlungsanbieter und Versandkonnektoren laufen im Testmodus. Der Zugriff ist entsprechend geregelt: Die Rolle Admin erreicht alle Stufen. Die Rolle Tester erreicht die Staging- und Entwicklungsdatenbanken samt deren Werkzeugen, über die Werkzeuge von Odoo.sh aber nicht die Produktionsdatenbank. Die Rolle Developer erreicht weder Produktions- noch Staging-Datenbanken.

Drei Dinge tragen eine eigene Frist: die Datenbank des Staging-Zweigs, die Sicherungen und bei einem Testprojekt die Stufe des Zweigs. Den Zweig selbst entfernen Sie per Git aus dem Repository; die Plattform löscht die Datenbank, die zu ihm gehört.

Die Fristen im Überblick

Beide Tabellen geben die Dokumentation 20.0 wieder, gelesen am 14. Oktober 2026.

Gegenstand	Frist	Was danach gilt	Quelle (Dokumentation 20.0)
Datenbank eines Staging-Zweigs	einen Monat ab dem Anlegen	Odoo.sh löscht sie automatisch; für eine weitere Nutzung bauen Sie den Zweig neu auf (Rebuild)	Zweige, Abschnitt Staging
Manuelle Sicherung von Produktion und Staging	drei Tage ab dem Anlegen der Sicherung, höchstens fünf je Tag	Danach steht die Sicherung nicht mehr zur Verfügung; laden Sie sie vorher herunter	Zweige, Reiter Back-ups
Automatische Sicherung der Produktionsdatenbank	sieben tägliche, vier wöchentliche und drei monatliche Stände, bis zu drei Monate	Der Produktionsserver hält nur einen Monat; die drei Monatsstände liegen auf eigenen Sicherungsservern und kommen über den Odoo-Support	Zweige, Abschnitte Produktion und Back-ups
Datenbank eines Entwicklungszweigs	rund drei Tage	Odoo.sh kann sie danach ohne vorherige Ankündigung abräumen, um Platz für neue Datenbanken zu schaffen; Sicherungen gibt es dort nicht	Zweige, Abschnitt Entwicklung

Gegenstand	Frist oder Grenze	Was danach gilt	Quelle (Dokumentation 20.0)
Testprojekt	30 Tage	Produktions- und alle Staging-Zweige setzt Odoo.sh automatisch in die Entwicklungsphase zurück	Zweige, Abschnitt Produktion
Testprojekt eines Partners	1 GB Speicher und zwei Staging-Umgebungen	Grenze des Testbuilds, den ein Partner mit seinem Partnerschaftscode startet; für ein reguläres Projekt schließt der Kunde ein Odoo-Enterprise-Abonnement mit Odoo.sh-Hosting ab	Projekt erstellen
Gewählte Revision im Entwicklungszweig	drei Monate	Das Feld Revision springt automatisch auf Neueste (Latest) zurück; die Plattform erinnert vorher per E-Mail	Zweige, Reiter Einstellungen
Zweig löschen	sofort	Ohne vorhandene Sicherung ist keine Wiederherstellung möglich	Zweige, Abschnitt Löschen

Für den Produktionszweig nennt die Dokumentation keine Ablauffrist; dort sind nur die Fristen der Sicherungen beschrieben. Staging- und Entwicklungsdatenbanken dagegen sind ausdrücklich Zwischenstände.

So sieht das im Alltag aus

Beispiel mit erfundenen Daten: Sie ziehen am 5. Mai einen Zweig auf die Stufe Staging, und Odoo.sh legt die Datenbank als Kopie der Produktion an. Am 5. Juni löscht die Plattform diese Datenbank. Reicht der Test bis zum 20. Mai, ist die Sache erledigt; für eine Fortsetzung am 10. Juni bauen Sie den Zweig neu auf (Rebuild), und die Datenbank entsteht wieder aus den Produktivdaten. Was Sie in der alten Staging-Datenbank angeklickt haben, ist dann nicht mehr vorhanden. Wollen Sie diese Konfigurationsarbeit behalten, legen Sie vor dem 5. Juni eine manuelle Sicherung an und laden Sie sie herunter: Sie bleibt drei Tage ab dem Anlegen abrufbar, eine am 3. Juni angelegte Sicherung also bis zum 6. Juni. Alternativ schreiben Sie die Einstellungen als XML-Datendatei in den Zweig.

Was bei einem neuen Commit mit dem Zweig geschieht, steuern Sie im Reiter Einstellungen des Zweigs: Standardmäßig aktualisiert ein Staging-Zweig den vorhandenen Build. Mit der Option Neuer Build (New build) entsteht bei jedem Push eine neue Kopie des Produktions-Builds.

Typische Fehler

• Einstellungen nur geklickt: Änderungen in der Staging-Datenbank überträgt Odoo.sh beim Zusammenführen nicht in die Produktion, übernommen wird nur der Quellcode. Legen Sie sie als XML-Datendatei im Zweig ab oder tragen Sie sie von Hand nach.
• Sicherung zu spät gezogen: Manuelle Sicherungen bleiben drei Tage ab dem Anlegen der Sicherung verfügbar. Wer eine Woche später auf denselben Teststand zugreifen will, findet nichts mehr; laden Sie die Sicherung vor dem Ablauf herunter.
• Mit einer dauerhaften Testdatenbank gerechnet: Die Staging-Datenbank wird nach einem Monat gelöscht; die Entwicklungsdatenbank ist für rund drei Tage gedacht und kann danach abgeräumt werden. Notieren Sie das Anlegedatum, damit der Ablauf nicht mitten in einer Abnahme liegt.
• Testprojekt als Dauerlösung: Nach 30 Tagen fallen Produktions- und Staging-Zweig in die Entwicklungsphase zurück. Ein Testprojekt, das Sie mit einem Partnerschaftscode gestartet haben, ist kein Dauerbetrieb; für ein reguläres Projekt brauchen Sie ein Odoo-Enterprise-Abonnement mit Odoo.sh-Hosting.
• Zweig gelöscht, Sicherung vergessen: Beim Löschen gibt es keine Wiederherstellung, wenn keine Sicherung existiert; Staging-Zweige werden nicht automatisch gesichert, Entwicklungszweige gar nicht.

So gehen Sie vor

1. Notieren Sie beim Anlegen der Staging-Datenbank das Datum; die Frist von einem Monat rechnet die Dokumentation ab dem Anlegen.
2. Halten Sie Konfigurationen im Zweig fest und nicht in der Datenbank: Einstellungen als XML-Datendatei im Modul, bei Bedarf mit erhöhter Modulversion im Manifest, damit die Aktualisierung beim Zusammenführen läuft.
3. Prüfen Sie vor jedem längeren Teststopp, ob Sie den Stand noch brauchen: manuelle Sicherung anlegen und herunterladen (sie bleibt drei Tage ab dem Anlegen abrufbar) oder von einem Staging-Build den Datenbank-Dump über die Aktionen neben Connect laden. Für Entwicklungs-Builds sind manuelle Sicherungen nicht möglich; den Dump-Download nennt die Dokumentation nur für die Produktions- und die Stagingstufe.
4. Bauen Sie den Zweig nach dem Ablauf neu auf und spielen Sie die Testdaten neu ein; eine Sicherung der Produktionsdatenbank können Sie im Reiter Back-ups in einen Staging-Zweig importieren.
5. Geben Sie Testpersonen die Rolle Tester, wenn sie die Staging-Datenbank öffnen sollen; die Produktionsdatenbank erreichen sie über die Werkzeuge von Odoo.sh nicht. Wer nur am Code arbeitet, bleibt Developer und sieht Produktiv- und Staging-Daten nicht.
6. Übertragen Sie am Ende die Änderungen per Zusammenführung in die Produktion; dabei wandert nur der Code. Wie Sie die Produktion danach sichern, steht unter Backup-Strategie für Odoo.