Skip to content
Znuny Community Docs

Znuny Staging System – Migration and Secure Test Environment

Znuny Staging System – Migration and Secure Test Environment

Section titled “Znuny Staging System – Migration and Secure Test Environment”

A staging system is the perfect environment for safely testing changes to the ticket system – for Znuny. It is an exact copy of the production system where functions, configurations, and data are migrated, tested, and validated – without affecting the live system.

🗾 Compatibility: The steps described in this article apply to Znuny 6.x+. Configuration files are consistent and are marked where necessary.

🔄 Overview: Staging System Migration Workflow

Section titled “🔄 Overview: Staging System Migration Workflow”
  1. Prepare development system
  2. Set up staging system
  3. Copy production data
  4. Test staging
  5. Deploy staging to production (optional)

✅ Benefits of a Staging System

Section titled “✅ Benefits of a Staging System”
  • Safe testing of configuration, custom code & packages
  • Automated end-to-end tests with, e.g., Playwright
  • GDPR-compliant testing after anonymization
  • Recovery tests & backup verification

🛠 Prerequisites

Section titled “🛠 Prerequisites”
  • Ubuntu 20.04+ or Debian 10+
  • Docker (recommended) or manual Linux installation
  • Sufficient system resources (8 GB RAM, 4 CPUs)
  • Access to current production data (DB & file system)
  • Ability to disable email dispatch (e.g., via dummy SMTP)

`customer_user“

🧱 Step-by-Step Guide

Section titled “🧱 Step-by-Step Guide”

1. Build the staging system

Section titled “1. Build the staging system”

A Docker installation is recommended: SysConfig

2. Clean up the dev system

Section titled “2. Clean up the dev system”

If you are using a dev system as a base: SendmailModule

Section titled “If you are using a dev system as a base: SendmailModule”

3. Copy production data

Section titled “3. Copy production data”

Kernel::System::Email::DoNotSendEmail Import into staging: 127.0.0.1

🔐 Data Privacy: Anonymize all production customer data, e.g., in the customer_user table, or remove email addresses using an SQL script.

4. Adjust configuration

Section titled “4. Adjust configuration”

1

5. Prevent email dispatch

Section titled “5. Prevent email dispatch”

In SysConfig:

  • Set SendmailModule to Kernel::System::Email::DoNotSendEmail
  • Alternatively: Change SMTP server to 127.0.0.1 and port to 1

🔬 Tests in Staging

Section titled “🔬 Tests in Staging”
  • Use Playwright or Cypress scripts for UI tests
  • Use bin/znuny.Console.pl Maint::Test::System
  • Check data integrity & UI behavior
  • Disable integrations like LDAP or web services, or redirect them to test servers

🔐 Secure the Staging System

Section titled “🔐 Secure the Staging System”
  • Restrict access via VPN or IP whitelist
  • Set robots.txt to prevent indexing
  • If necessary, implement Basic Auth via Nginx
  • Secure SSL via SAN or wildcard certificate (*.staging.example.com)

🔄 Optional: Deploy Staging to Production

Section titled “🔄 Optional: Deploy Staging to Production”

Once testing is complete in staging:

  1. Stop the production server
  2. Copy staging database and directories to production
  3. Adjust Config.pm
  4. Restart production

🧪 Example Tools for Automation

Section titled “🧪 Example Tools for Automation”
  • Playwright (for E2E tests)
  • rsync for fast data transfer
  • docker-compose for orchestrated environment
  • cron or systemd for regular backups
  • Python scripts for anonymization or structure migration

Conclusion

Section titled “Conclusion”

A Znuny staging system offers maximum security when introducing changes. Through structured migration, anonymized test data, and automated tests, you avoid downtime and ensure stable deployments.

🔁 Tip: Integrate staging processes into your CI/CD pipeline for automated quality assurance with every change.