Znuny Staging-System – Migration und sichere Testumgebung

Ein Staging-System ist die perfekte Umgebung, um Änderungen am Ticketsystem sicher zu testen – bei 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.

Hinweis

Kompatibilität: Die in diesem Artikel beschriebenen Schritte gelten für Znuny 6.x+. Konfigurationsdateien sind konsistent und werden bei Bedarf gekennzeichnet.

Ü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

• 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 Compose (empfohlen) oder offizielle 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

Eine Docker-Compose-Installation ist der schnellste Weg zu einer isolierten Staging-Instanz:

1. Znuny mit Docker Compose installieren auf einer separaten VM oder einem eigenen Host.
2. Anderen Compose-Projektnamen oder ein separates Verzeichnis als in Produktion verwenden, damit Volumes nicht kollidieren.
3. Web-Installer mit separater Datenbank (leeres Schema) abschließen.
4. Für den laufenden Betrieb: Znuny Docker (Backups, Konsolenbefehle, Updates).

Für Bare-Metal-Staging die offizielle Installationsanleitung auf einem dedizierten Server befolgen.

2. Dev-System aufräumen

Falls Sie ein Dev-System als Basis nutzen:

• Test-Tickets und Agenten entfernen, die nicht benötigt werden.
• SysConfig-Werte zurücksetzen, die auf Produktiv-URLs, LDAP oder Mailserver zeigen.
• Prüfen, dass keine Produktiv-API-Keys oder Web-Service-Zugangsdaten verbleiben.

3. Produktionsdaten kopieren

Datenbank:

# Auf Produktion (Beispiel MariaDB)
mysqldump -u root -p znuny > znuny-prod-$(date +%F).sql

# Auf Staging — in den DB-Container importieren
docker compose exec -T db mysql -u root -p znuny < znuny-prod-$(date +%F).sql

Dateisystem / Volumes:

Das var-Verzeichnis (Anhänge, Sessions) von Produktion kopieren. Bei Docker-Stacks typischerweise das Volume znuny-var — siehe Volume-Backup.

Datenschutz: Anonymisieren Sie alle produktiven Kundendaten z. B. in der customer_user-Tabelle oder entfernen Sie E-Mail-Adressen mit einem SQL-Skript, bevor Tester Zugang zum Staging erhalten.

4. Konfiguration anpassen

In SysConfig auf Staging:

• System-FQDN und HTTP-URLs auf den Staging-Hostnamen setzen.
• LDAP und externe Integrationen auf Test-Endpunkte zeigen oder deaktivieren.
• Cache-TTL bei Bedarf senken für schnelleres Feedback beim Testen.

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

Nach umfangreichen SysConfig-Änderungen im App-Container Maint::Config::Rebuild und Maint::Cache::Delete ausführen.

Tests im Staging

• Playwright oder Cypress-Skripte einsetzen für UI-Tests
• bin/znuny.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:

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

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

Häufig gestellte Fragen

Warum ein Znuny Staging-System einrichten?

Staging ist eine isolierte Kopie der Produktion, in der Sie Konfiguration, Packages und Migrationen testen können, ohne das Live-Ticketsystem zu gefährden.

Wie verhindere ich echten E-Mail-Versand auf Staging?

In der SysConfig SendmailModule auf Kernel::System::Email::DoNotSendEmail setzen oder SMTP auf einen Dummy-Host wie 127.0.0.1 Port 1 zeigen.

Dürfen Produktiv-Kundendaten unverändert auf Staging bleiben?

Nein. Kundendaten (z. B. in customer_user) vor Tester-Zugang anonymisieren, damit Staging DSGVO-tauglich bleibt.