OTOBO Staging-System – Migration und sichere Testumgebung

Ein Staging-System ist die perfekte Umgebung, um Änderungen am Ticketsystem sicher zu testen – ob bei OTOBO oder Znuny. Es handelt sich um eine exakte Kopie des Produktivsystems, in dem Funktionen, Konfigurationen und Daten migriert, getestet und validiert werden – ohne Einfluss auf das Live-System.

🗾 Kompatibilität: Die in diesem Artikel beschriebenen Schritte gelten gleichermaßen für OTOBO 11.x und Znuny 6.x+. Unterschiede in Konfigurationsdateien sind minimal und werden bei Bedarf gekennzeichnet.

🔄 Ü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:

# Tickets und Attachments löschen
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 oder Znuny Staging-System bietet maximale Sicherheit bei der Einführung von Änderungen. Durch strukturierte Migration, anonymisierte Testdaten und automatisierte Tests vermeiden Sie Ausfälle und sorgen für stabile Deployments.

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