OTOBO Staging-System erstellen — Schritt für Schritt

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

Entwicklungssystem vorbereiten
Staging-System aufsetzen
Produktivdaten kopieren
Staging testen
Staging nach Production deployen (optional)

✅ 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

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

1. Staging-System aufbauen

Empfohlen wird eine Docker-Installation:

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

Falls Sie ein Dev-System als Basis nutzen:

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

3. Produktionsdaten kopieren

# 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:

# 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

$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'STAGING_PASSWORT';

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

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

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

Wenn im Staging vollständig getestet wurde:

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

🧪 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

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.

OTOBO zuverlässig betreiben

Unterstützung bei Updates, Staging, Wartung, Backup-Konzept und einem dokumentierten, sicheren Betrieb.

Betrieb besprechen

Häufig gestellte Fragen

Was ist ein OTOBO Staging-System?

Eine möglichst exakte Kopie des Produktivsystems, um Features, Konfigurationen und Migrationen ohne Live-Risiko zu testen.

Sollte Staging Produktionsdaten nutzen?

Oft ja für realistische Tests — sensible Daten anonymisieren oder einschränken und Staging-Mail nie an echte Kunden senden.

Was sollte vor der Migration gesichert werden?

Sichern Sie Datenbank und relevante Dateidaten (Artikel und Kernel), bevor Sie sie ins Staging übernehmen.

Was sollte ich über 🛠 Voraussetzungen wissen?

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) ---

Was sollte ich über 🔄 Optional: Staging auf Production deployen wissen?

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 ---