Système de staging OTOBO – Migration et environnement de test sécurisé

Système de staging OTOBO – Migration et environnement de test sécurisé

Un système de staging est l’environnement idéal pour tester en toute sécurité les modifications apportées au système de tickets – que ce soit pour OTOBO ou Znuny. Il s’agit d’une copie exacte du système de production dans laquelle les fonctionnalités, les configurations et les données sont migrées, testées et validées, sans aucun impact sur le système en direct.

🗾 Compatibilité : Les étapes décrites dans cet article s’appliquent de la même manière à OTOBO 11.x et Znuny 6.x+. Les différences dans les fichiers de configuration sont minimes et signalées si nécessaire.

---

🔄 Aperçu : Processus de migration du système de staging

1. Préparer le système de développement
2. Configurer le système de staging
3. Copier les données de production
4. Tester le staging
5. Déployer le staging vers la production (optionnel)

---

✅ Avantages d’un système de staging

• Tests sécurisés de la configuration, du code personnalisé et des packages
• Tests de bout en bout automatisés avec, par exemple, Playwright
• Tests conformes au RGPD après anonymisation
• Tests de restauration et vérification des sauvegardes

---

🛠 Prérequis

• Ubuntu 20.04+ ou Debian 10+
• Docker (recommandé) ou installation Linux manuelle
• Ressources système suffisantes (8 Go de RAM, 4 CPU)
• Accès aux données de production actuelles (base de données et système de fichiers)
• Possibilité de désactiver l’envoi d’e-mails (par ex. via un SMTP factice)

---

flowchart TD
    A[Fonctionnalité prête pour le test] --> B[Nettoyer le système de dev, supprimer les tickets]
    B --> C[Copier Dev -> Staging]
    C --> D[Attendre la fenêtre de maintenance]
    D --> E[Sauvegarder les données de production DB & Files]
    E --> F[Transférer les données de production vers le Staging]
    F --> G[Adapter la configuration dans le Staging]
    G --> H[Désactiver l'envoi d'e-mails]
    H --> I[Exécuter la série de tests]
    
    I -->|Tests réussis| J[Optionnel : Copier Staging -> Production]
    I -->|Tests échoués| K[Corriger les erreurs et tester à nouveau]

    J --> L[Activer la production]
    L --> M[Terminé, déploiement finalisé]

    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

🧱 Guide étape par étape

1. Mettre en place le système de staging

Une installation Docker est recommandée :

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   # Définir OTOBO_DB_ROOT_PASSWORD

2. Nettoyer le système de développement

Si vous utilisez un système de développement comme base :

# Supprimer les tickets et les pièces jointes
bin/otobo.Console.pl Admin::Delete::Tickets --older 1d --state closed --really
rm -rf /opt/otobo/var/article/*

---

3. Copier les données de production

# Sauvegarder la base de données (système de production)
mysqldump -u root -p otobo > /tmp/otobo_prod.sql

# Sauvegarder les articles et le noyau
rsync -avz /opt/otobo/Kernel /tmp/Kernel
rsync -avz /opt/otobo/var/article /tmp/article

Importer dans le staging :

# Importer la DB
mysql -u root -p otobo_staging < /tmp/otobo_prod.sql

# Copier le système de fichiers
rsync -avz /tmp/Kernel /opt/otobo/Kernel
rsync -avz /tmp/article /opt/otobo/var/article

🔐 Protection des données : Anonymisez toutes les données clients de production, par exemple dans la table customer_user, ou supprimez les adresses e-mail à l’aide d’un script SQL.

---

4. Adapter la configuration

Kernel/Config.pm

$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'MOT_DE_PASSE_STAGING';

5. Empêcher l’envoi d’e-mails

Dans SysConfig :

• Régler SendmailModule sur Kernel::System::Email::DoNotSendEmail
• Alternative : changer le serveur SMTP pour 127.0.0.1 et le port 1

---

🔬 Tests dans le staging

• Utiliser des scripts Playwright ou Cypress pour les tests UI
• Utiliser bin/otobo.Console.pl Maint::Test::System
• Vérifier l’intégrité des données et le comportement de l’UI
• Désactiver les intégrations telles que LDAP ou les Webservices, ou les rediriger vers un serveur de test

---

🔐 Sécuriser le staging

• Restreindre l’accès via VPN ou liste blanche IP
• Configurer robots.txt pour empêcher l’indexation
• Si nécessaire, ajouter une authentification Basic via Nginx
• Sécuriser le SSL via un certificat SAN ou Wildcard (*.staging.example.com)

---

🔄 Optionnel : Déployer le staging vers la production

Une fois les tests terminés dans le staging :

1. Arrêter le serveur de production
2. Copier la base de données et les répertoires du staging vers la production
3. Adapter Config.pm
4. Redémarrer la production

---

🧪 Exemples d’outils pour l’automatisation

• Playwright (pour les tests E2E)
• rsync pour un transfert de données rapide
• docker-compose pour un environnement orchestré
• cron ou systemd pour des sauvegardes régulières
• Scripts Python pour l’anonymisation ou la migration de structure

---

Conclusion

Un système de staging OTOBO ou Znuny offre une sécurité maximale lors de l’introduction de modifications. Grâce à une migration structurée, des données de test anonymisées et des tests automatisés, vous évitez les pannes et assurez des déploiements stables.

🔁 Conseil : Intégrez les processus de staging dans votre pipeline CI/CD pour une assurance qualité automatisée à chaque modification.