Skip to content

OTOBO & Znuny Staging-System – Migrazione e ambiente di test sicuro

https://softoft.sirv.com/Images/otobo-staging-2.png Un sistema di staging è l'ambiente perfetto per testare in sicurezza le modifiche al sistema di ticketing – sia per OTOBO che per Znuny. Si tratta di una copia esatta del sistema di produzione, in cui funzionalità, configurazioni e dati vengono migrati, testati e convalidati – senza influenzare il sistema live.

INFO

🗾 Compatibilità: I passaggi descritti in questo articolo sono validi sia per OTOBO 11.x che per Znuny 6.x+. Le differenze nei file di configurazione sono minime e vengono segnalate quando necessario.


🔄 Panoramica: flusso di migrazione del sistema di staging

  1. Preparare il sistema di sviluppo
  2. Configurare il sistema di staging
  3. Copiare i dati di produzione
  4. Testare il sistema di staging
  5. Distribuire il sistema di staging in produzione (opzionale)

✅ Vantaggi di un sistema di staging

  • Test sicuro della configurazione, del codice personalizzato e dei pacchetti
  • Test end-to-end automatizzati con ad esempio Playwright
  • Test DSGVO-conformi dopo l'anonimizzazione
  • Test di ripristino e verifica del backup

🛠 Prerequisiti

  • Ubuntu 20.04+ o Debian 10+
  • Docker (consigliato) o installazione manuale su Linux
  • Risorse di sistema sufficienti (8 GB di RAM, 4 CPU)
  • Accesso ai dati di produzione attuali (database e file system)
  • Invio di e-mail disabilitabile (ad esempio tramite Dummy-SMTP)

🧱 Istruzioni passo dopo passo

1. Configurare il sistema di staging

Consigliato l'uso di Docker:

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   # Impostare OTOBO_DB_ROOT_PASSWORD

2. Pulire il sistema di sviluppo

Se si utilizza un sistema di sviluppo come base:

bash
# Eliminare ticket e allegati
bin/otobo.Console.pl Admin::Delete::Tickets --older 1d --state closed --really
rm -rf /opt/otobo/var/article/*

3. Copiare i dati di produzione

bash
# Eseguire il backup del database (sistema di produzione)
mysqldump -u root -p otobo > /tmp/otobo_prod.sql

# Eseguire il backup degli articoli e del kernel
rsync -avz /opt/otobo/Kernel /tmp/Kernel
rsync -avz /opt/otobo/var/article /tmp/article

Importare nel sistema di staging:

bash
# Importare il database
mysql -u root -p otobo_staging < /tmp/otobo_prod.sql

# Copiare il file system
rsync -avz /tmp/Kernel /opt/otobo/Kernel
rsync -avz /tmp/article /opt/otobo/var/article

🔐 Protezione dei dati: Anonimizzare tutti i dati dei clienti produttivi, ad esempio nella tabella customer_user, o rimuovere gli indirizzi e-mail con uno script SQL.


4. Configurare la configurazione

perl
# Kernel/Config.pm
$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'STAGING_PASSWORT';

5. Disabilitare l'invio di e-mail

In SysConfig:

  • Impostare SendmailModule su Kernel::System::Email::DoNotSendEmail
  • Alternativa: modificare il server SMTP su 127.0.0.1 e porta 1

🔬 Test nel sistema di staging

  • Utilizzare script Playwright o Cypress per test UI
  • Utilizzare bin/otobo.Console.pl Maint::Test::System
  • Verificare l'integrità dei dati e il comportamento dell'interfaccia utente
  • Disabilitare le integrazioni come LDAP o servizi web o reindirizzarle al server di test

🔐 Proteggere il sistema di staging

  • Limitare l'accesso tramite VPN o elenco di controllo degli accessi IP
  • Impostare robots.txt per prevenire l'indicizzazione
  • Aggiungere l'autenticazione di base tramite Nginx se necessario
  • Proteggere con SSL tramite certificato SAN o wildcard (*.staging.example.com)

🔄 Opzionale: distribuire il sistema di staging in produzione

Se il sistema di staging è stato testato completamente:

  1. Fermare il server di produzione
  2. Copiare il database e i directory del sistema di staging in produzione
  3. Configurare Config.pm
  4. Riavviare la produzione

🧪 Strumenti di esempio per l'automatizzazione

  • Playwright (per test end-to-end)
  • rsync per il trasferimento rapido dei dati
  • docker-compose per l'orchestrazione dell'ambiente
  • cron o systemd per backup regolari
  • Script Python per l'anonimizzazione o la migrazione della struttura

Conclusione

Un sistema di staging per OTOBO o Znuny offre la massima sicurezza quando si introducono modifiche. Attraverso la migrazione strutturata, i dati di test anonimizzati e i test automatizzati, si evitano interruzioni e si garantiscono deploy stabili.

🔁 Suggerimento: Integrare i processi di staging nella pipeline CI/CD per garantire la qualità automatica con ogni modifica.