OTOBO & Znuny 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.
INFO
🗾 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)
🧱 Schritt-für-Schritt-Anleitung
1. Staging-System aufbauen
Empfohlen wird eine Docker-Installation:
bash
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:
bash
# 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
bash
# 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:
bash
# 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
perl
# Kernel/Config.pm
$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'STAGING_PASSWORT';
5. E-Mail-Versand unterbinden
In SysConfig
:
SendmailModule
aufKernel::System::Email::DoNotSendEmail
setzen- Alternativ: SMTP-Server auf
127.0.0.1
und Port1
ä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übertragungdocker-compose
für orchestrierte Umgebungcron
odersystemd
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.