Zum Inhalt springen
OTOBO Community Guide

OTOBO Staging-System erstellen — Schritt für Schritt

https://softoft.sirv.com/Images/otobo-staging-2.png Richten Sie ein OTOBO Staging-System als sichere Produktivkopie ein — so erstellen Sie das Staging-System Schritt für Schritt. Alternativ nutzen Sie ein OTOBO Testsystem mit derselben Methode: Datenbank und Dateien migrieren, echten E-Mail-Versand abschalten, Kundendaten anonymisieren und Packages prüfen — bevor etwas live geht.

🔄 Überblick: Staging-System Migrationsablauf

Abschnitt betitelt „🔄 Überblick: Staging-System Migrationsablauf“
  1. Entwicklungssystem vorbereiten
  2. Staging-System aufsetzen
  3. Produktivdaten kopieren
  4. Staging testen
  5. Staging nach Production deployen (optional)

✅ Vorteile eines Staging-Systems

Abschnitt betitelt „✅ Vorteile eines Staging-Systems“
  • Sicheres Testen von Konfiguration, Custom Code & Packages
  • Automatisierte End-to-End-Tests mit z. B. Playwright
  • DSGVO-konformes Testen nach Anonymisierung
  • Wiederherstellungstests & Backup-Prüfung

🛠 Voraussetzungen

Abschnitt betitelt „🛠 Voraussetzungen“
  • Ubuntu 20.04+ oder Debian 10+
  • Docker (empfohlen) oder manuelle Linux-Installation
  • Genug Systemressourcen (8 GB RAM, 4 CPUs)
  • Zugriff auf aktuelle Produktionsdaten (DB & Dateisystem)
  • E-Mail-Versand deaktivierbar (z. B. durch Dummy-SMTP)
flowchart TD
    A[Feature bereit für Test] --> B[Dev-System bereinigen Tickets löschen]
    B --> C[Dev -> Staging kopieren]
    C --> D[Warten auf Wartungsfenster]
    D --> E[Produktivdaten sichern DB & Files]
    E --> F[Produktivdaten auf Staging übertragen]
    F --> G[Konfiguration im Staging anpassen]
    G --> H[E-Mail-Versand deaktivieren]
    H --> I[Testlauf durchführen]

    I -->|Tests erfolgreich| J[Optional: Staging -> Production kopieren]
    I -->|Tests fehlgeschlagen| K[Fehler beheben und erneut testen]

    J --> L[Production aktivieren]
    L --> M[Fertig Deployment abgeschlossen]

    style D fill:#a9a,stroke:#333,stroke-width:1px
    style I fill:#aae,stroke:#333,stroke-width:1px
    style J fill:#9a9,stroke:#333,stroke-width:1px
    style K fill:#a99,stroke:#333,stroke-width:1px

🧱 Schritt-für-Schritt-Anleitung

Abschnitt betitelt „🧱 Schritt-für-Schritt-Anleitung“

1. Staging-System aufbauen

Abschnitt betitelt „1. Staging-System aufbauen“

Empfohlen wird eine Docker-Installation:

Terminal-Fenster
sudo apt install docker.io docker-compose
cd /opt
git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-11_0
cd otobo-docker
cp .docker_compose_env_https .env
nano .env   # OTOBO_DB_ROOT_PASSWORD setzen

2. Dev-System aufräumen

Abschnitt betitelt „2. Dev-System aufräumen“

Falls Sie ein Dev-System als Basis nutzen:

Terminal-Fenster
bin/otobo.Console.pl Admin::Delete::Tickets --older 1d --state closed --really
rm -rf /opt/otobo/var/article/*

3. Produktionsdaten kopieren

Abschnitt betitelt „3. Produktionsdaten kopieren“
Terminal-Fenster
# Datenbank sichern (Produktivsystem)
mysqldump -u root -p otobo > /tmp/otobo_prod.sql


# Artikel & Kernel sichern
rsync -avz /opt/otobo/Kernel /tmp/Kernel
rsync -avz /opt/otobo/var/article /tmp/article

Im Staging importieren:

Terminal-Fenster
# DB importieren
mysql -u root -p otobo_staging < /tmp/otobo_prod.sql


# Dateisystem kopieren
rsync -avz /tmp/Kernel /opt/otobo/Kernel
rsync -avz /tmp/article /opt/otobo/var/article

🔐 Datenschutz: Anonymisieren Sie alle produktiven Kundendaten z. B. in der customer_user-Tabelle oder entfernen Sie E-Mail-Adressen mit einem SQL-Skript.

4. Konfiguration anpassen

Abschnitt betitelt „4. Konfiguration anpassen“
Kernel/Config.pm
$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'STAGING_PASSWORT';

5. E-Mail-Versand unterbinden

Abschnitt betitelt „5. E-Mail-Versand unterbinden“

In SysConfig:

  • SendmailModule auf Kernel::System::Email::DoNotSendEmail setzen
  • Alternativ: SMTP-Server auf 127.0.0.1 und Port 1 ändern

🔬 Tests im Staging

Abschnitt betitelt „🔬 Tests im Staging“
  • Playwright oder Cypress-Skripte einsetzen für UI-Tests
  • bin/otobo.Console.pl Maint::Test::System verwenden
  • Datenintegrität & UI-Verhalten prüfen
  • Integrationen wie LDAP oder Webservices deaktivieren oder auf Testserver umleiten

🔐 Staging absichern

Abschnitt betitelt „🔐 Staging absichern“
  • Zugriff via VPN oder IP-Whitelist beschränken
  • robots.txt setzen, um Indexierung zu verhindern
  • ggf. Basic-Auth via Nginx einbauen
  • SSL per SAN- oder Wildcard-Zertifikat absichern (*.staging.example.com)

🔄 Optional: Staging auf Production deployen

Abschnitt betitelt „🔄 Optional: Staging auf Production deployen“

Wenn im Staging vollständig getestet wurde:

  1. Production-Server stoppen
  2. Staging-Datenbank und Verzeichnisse auf Production kopieren
  3. Config.pm anpassen
  4. Production wieder starten

🧪 Beispielhafte Tools für Automatisierung

Abschnitt betitelt „🧪 Beispielhafte Tools für Automatisierung“
  • Playwright (für E2E-Tests)
  • rsync für schnelle Datenübertragung
  • docker-compose für orchestrierte Umgebung
  • cron oder systemd für regelmäßige Backups
  • Python-Skripte für Anonymisierung oder Strukturmigration

Fazit

Abschnitt betitelt „Fazit“

Ein OTOBO Staging-System lässt Sie Upgrades, Packages und SysConfig-Änderungen an produktionsnahen Daten testen — ohne Produktivausfall und ohne versehentliche Kunden-Mails.

🔁 Tipp: Integrieren Sie die Staging-Prozesse in Ihre CI/CD-Pipeline für automatisierte Qualitätssicherung bei jeder Änderung.

Zuverlässiger OTOBO Betrieb & Support

Verlässliche Unterstützung bei Updates, Staging-Instanzen, Desaster-Recovery-Konzepten und technischem 2nd-Level-Support.

Support-Plan ansehen

Häufig gestellte Fragen

Was ist ein OTOBO Staging-System und welche Vorteile bietet es?

Ein OTOBO Staging-System ist eine möglichst exakte Kopie Ihres Produktivsystems, die dazu dient, neue Features, Konfigurationen, Updates oder Migrationen in einer sicheren und isolierten Umgebung zu testen. Es simuliert die Produktionsumgebung so genau wie möglich, um unerwartete Probleme im Live-System zu vermeiden. Die Vorteile eines solchen Systems sind vielfältig: Es ermöglicht das sichere Testen von Konfigurationen, benutzerdefiniertem Code und Packages, ohne das Risiko eines Produktivausfalls. Zudem können automatisierte End-to-End-Tests (z. B. mit Playwright) durchgeführt werden, um die Funktionalität umfassend zu prüfen. Ein Staging-System unterstützt auch DSGVO-konformes Testen nach der Anonymisierung sensibler Daten und kann für Wiederherstellungstests sowie die Überprüfung von Backups genutzt werden. Es ist ein unverzichtbares Werkzeug für eine robuste Qualitätssicherung.

Quellen:

Wie gehe ich mit Produktionsdaten im Staging-System um, insbesondere bezüglich Datenschutz (DSGVO)?

Für realistische Tests ist es oft notwendig, Produktionsdaten im Staging-System zu verwenden. Dies ermöglicht es, das System unter Bedingungen zu testen, die denen der Live-Umgebung sehr nahekommen. Es ist jedoch von entscheidender Bedeutung, sensible Kundendaten zu anonymisieren oder einzuschränken, um die Datenschutz-Grundverordnung (DSGVO) einzuhalten. Dies kann durch SQL-Skripte geschehen, die beispielsweise E-Mail-Adressen, Namen oder andere identifizierbare Informationen in der customer_user-Tabelle ändern oder entfernen. Stellen Sie sicher, dass keine echten Kundendaten, die eine Identifizierung ermöglichen, im Staging-System verbleiben. Darüber hinaus muss der E-Mail-Versand im Staging-System unbedingt deaktiviert werden, um zu verhindern, dass Test-E-Mails versehentlich an echte Kunden gesendet werden.

Quellen:

Welche Schritte sind für die Einrichtung eines OTOBO Staging-Systems erforderlich und welche Voraussetzungen gibt es?

Die Einrichtung eines OTOBO Staging-Systems umfasst mehrere zentrale Schritte und erfordert bestimmte Voraussetzungen. Zunächst sollten Sie ein Entwicklungssystem vorbereiten, falls Sie eines als Basis nutzen, und es gegebenenfalls aufräumen. Anschließend wird das Staging-System selbst aufgesetzt, wobei eine Docker-Installation oft empfohlen wird. Der kritische Schritt ist das Kopieren der Produktivdaten, einschließlich der Datenbank und relevanter Dateidaten wie Artikel und Kernel-Verzeichnisse. Nach dem Import müssen die Konfigurationen im Staging-System angepasst werden, insbesondere die Datenbankverbindung in der Config.pm. Schließlich ist es unerlässlich, den E-Mail-Versand zu unterbinden.
Die technischen Voraussetzungen umfassen:

  • Betriebssystem: Ubuntu 20.04+ oder Debian 10+.
  • Installation: Docker (empfohlen) oder eine manuelle Linux-Installation.
  • Ressourcen: Ausreichend Systemressourcen (mindestens 8 GB RAM, 4 CPUs).
  • Datenzugriff: Zugriff auf aktuelle Produktionsdaten (Datenbank und Dateisystem).
  • E-Mail-Kontrolle: Die Möglichkeit, den E-Mail-Versand zu deaktivieren (z. B. durch einen Dummy-SMTP-Server).

Quellen:

Wie verhindere ich den versehentlichen E-Mail-Versand vom Staging-System und wie sichere ich es ab?

Um den versehentlichen E-Mail-Versand vom OTOBO Staging-System zu unterbinden, gibt es mehrere effektive Methoden. Die einfachste ist, in der SysConfig den Parameter SendmailModule auf Kernel::System::Email::DoNotSendEmail zu setzen. Alternativ können Sie die SMTP-Servereinstellungen auf eine ungültige Adresse wie 127.0.0.1 und einen nicht verwendeten Port wie 1 ändern, um sicherzustellen, dass keine E-Mails versendet werden können.
Die Absicherung des Staging-Systems ist ebenso wichtig. Beschränken Sie den Zugriff auf das System über VPN oder eine IP-Whitelist, um unbefugten Zugriff zu verhindern. Setzen Sie eine robots.txt-Datei, um die Indexierung durch Suchmaschinen zu unterbinden und das System nicht öffentlich sichtbar zu machen. Eine zusätzliche Sicherheitsebene kann durch Basic-Auth via Nginx implementiert werden. Für die Verschlüsselung des Datenverkehrs sollte SSL mittels eines SAN- oder Wildcard-Zertifikats (z. B. für *.staging.example.com) eingerichtet werden.

Quellen:

Wie kann ich ein Staging-System effektiv testen und welche Tools unterstützen dabei?

Ein effektives Testen im OTOBO Staging-System ist entscheidend, um die Stabilität und Funktionalität vor dem Go-Live zu gewährleisten. Sie können hierfür verschiedene Methoden und Tools einsetzen. Für UI-Tests eignen sich Skripte mit Tools wie Playwright oder Cypress, die End-to-End-Szenarien simulieren. Die OTOBO-Konsole bietet zudem das Kommando bin/otobo.Console.pl Maint::Test::System, um grundlegende Systemprüfungen durchzuführen. Wichtig ist auch die manuelle Überprüfung der Datenintegrität und des UI-Verhaltens. Integrationen wie LDAP oder Webservices sollten im Staging entweder deaktiviert oder auf separate Testserver umgeleitet werden, um keine Auswirkungen auf Produktivsysteme zu haben.
Für die Automatisierung und Verwaltung des Staging-Prozesses können weitere Tools hilfreich sein:

  • rsync für schnelle und effiziente Datenübertragung.
  • docker-compose zur Orchestrierung der OTOBO-Umgebung, falls Docker verwendet wird.
  • cron oder systemd für die Planung regelmäßiger Backups oder Wartungsaufgaben.
  • Python-Skripte können für die Anonymisierung von Daten oder die Migration von Strukturen eingesetzt werden.

Quellen:

Was muss ich beachten, wenn ich das Staging-System auf das Produktivsystem übertragen möchte?

Die Übertragung des erfolgreich getesteten Staging-Systems auf das Produktivsystem ist ein optionaler, aber wichtiger Schritt, der sorgfältig geplant werden sollte. Dieser Prozess, oft als "Deployment" bezeichnet, erfordert ein Wartungsfenster, da das Produktivsystem währenddessen gestoppt werden muss.
Die Schritte sind wie folgt:

  1. Production-Server stoppen: Beenden Sie alle OTOBO-Dienste auf dem Produktivsystem, um Dateninkonsistenzen zu vermeiden.
  2. Staging-Datenbank und Verzeichnisse auf Production kopieren: Übertragen Sie die Datenbank des Staging-Systems sowie die relevanten Dateiverzeichnisse (z. B. /opt/otobo/Kernel und /opt/otobo/var/article) auf den Produktivserver. Stellen Sie sicher, dass Sie zuvor ein vollständiges Backup des Produktivsystems erstellt haben.
  3. Config.pm anpassen: Bearbeiten Sie die Kernel/Config.pm auf dem Produktivserver, um die Datenbankverbindungsdaten und andere spezifische Einstellungen wieder auf die Produktionswerte anzupassen.
  4. Production wieder starten: Starten Sie alle OTOBO-Dienste auf dem Produktivsystem neu und überprüfen Sie die Funktionalität.
    Es ist ratsam, diesen Prozess in Ihre CI/CD-Pipeline zu integrieren, um eine automatisierte und fehlerfreie Qualitätssicherung bei jeder Änderung zu gewährleisten.

Quellen: