Testumgebung für Odoo: Staging und Kopien

Was Sie vorab brauchen

• Ihr Hostingmodell: Odoo Online, Odoo.sh oder ein eigener Server. Die Editionsseite ordnet die Zeile „Hosting” der Enterprise-Edition zu; die Community-Edition betreiben Sie auf eigenem Server selbst.
• Bei Odoo Online: den Administrator-Zugang zur Datenbankverwaltung.
• Bei Odoo.sh: den Zugang zum Projekt. Über die Werkzeuge von Odoo.sh erreichen die Staging-Datenbank laut Dokumentation die Rollen Tester und Admin; die Rolle Developer hat laut Rollenbeschreibung keinen Zugriff auf die Produktions- und die Staging-Datenbank.
• Bei eigenem Server (Administrator-Rechte): Serverzugang, das Master-Passwort der Datenbankverwaltung und Platz für eine zweite Datenbank.
• Eine feste Regel, wie die Kopie E-Mails und geplante Aktionen zurückhält.
• Einen Zeitpunkt, zu dem die Kopie wieder verschwindet.

Worauf es bei einer Testumgebung ankommt

Eine Testumgebung ist eine zweite Odoo-Datenbank mit einer Kopie der Produktivdaten, in der Sie Änderungen prüfen, ohne die Produktion zu berühren. Entscheidend ist nicht nur, wie die Kopie entsteht, sondern was sie nicht mehr tut: Sie darf keine E-Mails an Kundschaft senden, keine geplanten Aktionen auslösen und keine Zahlungen anstoßen. Odoo nennt eine solche Datenbank neutralisiert (Dokumentation „Neutralized database”, Version 20.0). Sie zeigt oben ein rotes Band, damit sie nicht mit der Produktion verwechselt wird.

Welche Kopien neutralisiert sind, hält die Dokumentation fest: Datenbanken, die zum Testen angelegt werden, also Kopien aus einer Sicherung und duplizierte Datenbanken, bei Odoo.sh zusätzlich die Staging- und Development-Datenbanken. Auf einem eigenen Server gibt es keine solche Automatik; dort neutralisieren Sie selbst. Eine ältere Version einer Datenbank prüfen Sie vor einem Wechsel mit demselben Vorgehen (siehe Odoo auf eine neue Version heben).

Testumgebung je Hostingmodell

Die folgende Übersicht stellt die drei Hostingmodelle nebeneinander. Die sicherheitsrelevante Spalte ist der ausgehende E-Mail-Versand.

	Odoo Online	Odoo.sh	Eigener Server
Testumgebung anlegen	Datenbank in der Verwaltung duplizieren (Duplicate)	Branch in die Stufe Staging ziehen; die Plattform baut ein Duplikat	zweite Datenbank aus einem eigenen Dump (odoo-bin db load)
Datenquelle	Kopie der Produktivdatenbank	neutralisierte Kopie der Produktionsdatenbank	Ihr Dump; Testdaten nur, wenn Sie sie einspielen
Ausgehende E-Mails	Duplikat ist neutralisiert: E-Mails sind abgeschaltet (Option „For testing purposes”, standardmäßig an)	neutralisiert; ein Mail Catcher fängt die E-Mails ab (Reiter „Mails”); aus der Produktion gehen Mails wirklich raus	nichts automatisch; die Neutralisierung schaltet ausgehende E-Mails ab. Ein Mailserver, den Sie danach neu und aktiv eintragen, ist davon nicht betroffen
Weitere abgeschaltete Wirkungen	Zahlungen, Lieferaufträge und weitere externe Aktionen	geplante Aktionen aus; Zahlungsanbieter und Lieferdienste im Testmodus; IAP-Dienste aus	von Ihnen zu setzen; die Neutralisierung deckt geplante Aktionen, Bank-Synchronisierung, Zahlungsanbieter, Liefermethoden und IAP-Dienste ab
Lebensdauer	Duplikat läuft nach 15 Tagen ab; höchstens 5 je Datenbank	Staging-Datenbank einen Monat nach dem Anlegen automatisch gelöscht; Development für rund 3 Tage gedacht, danach Abräumen ohne Vorankündigung möglich	die Dauer legen Sie fest
Backups	die Datenbank wird laut Dokumentation täglich gesichert (Download Backup); das Duplikat ist keine Sicherung	Staging und Development werden nicht automatisch gesichert; manuell nur Staging (3 Tage)	eigene Regel

Bei Odoo Online und Odoo.sh sind die Kopien also schon neutralisiert, sobald sie entstehen; Sie müssen dabei prüfen, dass die Schutzfunktion aktiv bleibt. Bei Odoo.sh folgt das aus den Branch-Stufen: Production, Staging und Development. Ein Staging-Branch ist laut Dokumentation dafür gedacht, neue Funktionen mit Produktivdaten zu testen; die Plattform erstellt dafür ein neutralisiertes Duplikat der Produktionsdatenbank.

Schritt für Schritt: Testumgebung einrichten

Schritt 1: Prüfziel festlegen

Notieren Sie, was Sie prüfen wollen: eine Konfigurationsänderung, ein Modul oder ein Update. Legen Sie fest, welche Funktionen die Kopie dafür braucht, und richten Sie sie danach ein. Ein Abnahmetest mit festen Szenarien ist ein eigenes Vorgehen (siehe Abnahmetest für Odoo).

Schritt 2 (Odoo Online): Datenbank duplizieren

Öffnen Sie die Datenbankverwaltung unter odoo.com/my/databases und melden Sie sich als Administrator an. Wählen Sie die Produktivdatenbank, klicken Sie „Duplicate” und vergeben Sie einen neuen Namen. Lassen Sie die Option „For testing purposes” angehakt; sie ist standardmäßig aktiv und schaltet alle externen Aktionen der Kopie ab. Endzustand: Die neue Datenbank erscheint in der Verwaltung. Beachten Sie, dass laut Dokumentation höchstens fünf Duplikate je Datenbank möglich sind und ein Duplikat nach 15 Tagen abläuft.

Schritt 3 (Odoo.sh): Staging-Branch anlegen

Legen Sie einen Branch an und ziehen Sie ihn in die Stufe „Staging”; die Plattform erstellt dann ein neutralisiertes Duplikat der Produktionsdatenbank. Für jede weitere Staging-Umgebung verlangt Odoo eine Produkterhöhung, die Sie im Projekt beantragen. Standardmäßig aktualisiert ein neuer Commit den vorhandenen Build; wenn Sie bei jedem Commit eine frische Kopie der Produktion wollen, stellen Sie das im Reiter „Settings” auf „New build”. Endzustand: Der Branch steht unter Staging und die Datenbank ist über „Connect” erreichbar.

Schritt 4 (eigener Server): Kopie erstellen und neutralisieren

Sichern Sie die Produktion mit odoo-bin db dump und laden Sie den Dump unter neuem Datenbanknamen wieder ein. Mit dem Zusatz -n neutralisieren Sie die Kopie direkt beim Einspielen:

odoo-bin db load <datenbank> <dump> -n

Eine bereits laufende Kopie neutralisieren Sie nachträglich mit:

odoo-bin --addons-path <pfad> neutralize -d <datenbank>

Setzen Sie außerdem den Startparameter --database mit der Liste der erlaubten Datenbanken und --db-filter für die Namen, welche die Web-Oberfläche zeigen darf. --db-filter begrenzt die Cron-Worker laut Dokumentation nicht; ohne --database laufen sie auf jeder verfügbaren Datenbank. Setzen Sie beide, entscheidet --db-filter über die sichtbare Liste und die Aufzählung bei --database über Vorgänge wie ein Modul-Update.

Schritt 5: E-Mail-Versand absichern

Auf einem eigenen Server ist nichts vorbelegt. Die Neutralisierung schaltet ausgehende E-Mails ab; ein Mailserver, den Sie danach neu und aktiv eintragen, ist davon nicht betroffen. Prüfen Sie deshalb unter Einstellungen → E-Mails den Abschnitt der ausgehenden Mailserver (Option „Use Custom Email Servers”, dann „Outgoing Email Servers”; mehrere Server verwalten Sie im Entwicklermodus unter Einstellungen → Technisch → E-Mail: Ausgehende Mailserver) und schalten Sie die Verbindung ab. Redaktioneller Vorschlag: Richten Sie den ausgehenden Mailserver der Testdatenbank auf einen SMTP-Dienst, der Mails annimmt, aber nicht weiterleitet, und lesen Sie dort mit. Bei Odoo.sh und Odoo Online entfällt dieser Schritt, weil ein Duplikat oder Staging-Branch bereits neutralisiert ist.

Schritt 6: Prüfen und wieder verwerfen

Führen Sie die geplante Änderung in der Kopie durch, nicht in der Produktion. Danach verwerfen Sie die Kopie: Das Odoo-Online-Duplikat läuft von selbst nach 15 Tagen ab, die Odoo.sh-Staging-Datenbank löscht die Plattform einen Monat nach dem Anlegen, und eine Development-Datenbank kann Odoo.sh nach rund drei Tagen abräumen. Eigenen Serverkopien löschen Sie selbst. Übertragen Sie eine in der Kopie gefundene Konfigurationsänderung bewusst in die Produktion und protokollieren Sie sie; bei Odoo.sh wandern beim Zusammenführen nur die Codeänderungen mit.

So prüfen Sie das Ergebnis

• Das rote Band der neutralisierten Datenbank ist oben sichtbar.
• Eine Testmail landet im Mail Catcher (Odoo.sh, Reiter „Mails”) oder im Postfach des SMTP-Dienstes, auf den Sie die Kopie umgeleitet haben (eigener Vorschlag), nicht bei einer echten Adresse.
• Geplante Aktionen laufen nicht von selbst los.
• Auch in Test- und Staging-Datenbanken gibt es keine Standardpasswörter wie admin/admin.
• Auf internetseitig erreichbaren Servern liegen keine Demodaten, die Standardzugänge enthalten.
• Öffentlich erreichbare Test- und Staging-Instanzen stehen möglichst auf einer anderen Maschine als die Produktion.
• Bei Odoo.sh bleiben Produktions- und Staging-Builds privat; die Option „Allow public access” öffnet nur Development-Builds für Besucher.

Wenn etwas nicht klappt

Symptom	Ursache nach Quelle	Lösung
Testdatenbank ist verschwunden	Odoo-Online-Duplikat nach 15 Tagen abgelaufen; Odoo.sh-Staging-Datenbank einen Monat nach dem Anlegen gelöscht; Development-Datenbank nach rund drei Tagen abgeräumt	Kopie neu duplizieren oder den Branch neu aufbauen
E-Mails kommen doch bei Kunden an	Neutralisierung oder Mailserver nicht geprüft	Test abbrechen, ausgehenden Mailserver abschalten und Testmail wiederholen
Cron-Jobs arbeiten in der Testdatenbank	--db-filter begrenzt die Cron-Worker nicht; ohne --database laufen sie auf jeder verfügbaren Datenbank	--database mit der erlaubten Liste setzen oder die geplanten Aktionen in der Kopie kontrollieren
Bei Odoo.sh keine Staging-Umgebung sichtbar	Branch steht nicht in der Stufe Staging oder das Kontingent ist erschöpft	Branch unter „Staging” ziehen oder Produkterhöhung beantragen
Datenbankverwaltung auf eigenem Server nicht erreichbar	list_db = False beziehungsweise --no-database-list	über odoo-bin oder die Kopie der Konfigurationsdatei arbeiten

Wann Sie Hilfe holen sollten

Bei Odoo Online und Odoo.sh sind Odoo Support und Ihr Partner die Ansprechpartner, etwa für eine Produkterhöhung, zusätzliche Staging-Branches oder eine höhere Zahl an Duplikaten. Auf einem eigenen Server holen Sie Hilfe, wenn die Testdatenbank Cron-Jobs, den Mailversand oder die Bank-Synchronisierung nicht sicher vom Produktivsystem trennt. Redaktionelle Einschätzung: Diese Trennung ist eine Server- und Rechtefrage; prüfen Sie sie, bevor die Kopie eine echte Aktion auslöst.