Sistema de Staging de OTOBO – Migración y entorno de pruebas seguro

Sistema de Staging de OTOBO – Migración y entorno de pruebas seguro

Un sistema de Staging es el entorno perfecto para probar cambios en el sistema de tickets de forma segura, ya sea en OTOBO o Znuny. Se trata de una copia exacta del sistema de producción en la que se migran, prueban y validan funciones, configuraciones y datos, sin afectar al sistema en vivo.

🗾 Compatibilidad: Los pasos descritos en este artículo se aplican por igual a OTOBO 11.x y Znuny 6.x+. Las diferencias en los archivos de configuración son mínimas y se señalarán cuando sea necesario.

---

🔄 Resumen: Flujo de migración del sistema de Staging

1. Preparar el sistema de desarrollo
2. Configurar el sistema de Staging
3. Copiar los datos de producción
4. Probar el Staging
5. Desplegar el Staging a producción (opcional)

---

✅ Ventajas de un sistema de Staging

• Pruebas seguras de configuración, código personalizado y paquetes
• Pruebas automatizadas de extremo a extremo (End-to-End) con, por ejemplo, Playwright
• Pruebas conformes al RGPD tras la anonimización
• Pruebas de restauración y verificación de backups

---

🛠 Requisitos previos

• Ubuntu 20.04+ o Debian 10+
• Docker (recomendado) o instalación manual en Linux
• Recursos de sistema suficientes (8 GB RAM, 4 CPUs)
• Acceso a datos de producción actuales (BD y sistema de archivos)
• Posibilidad de desactivar el envío de correos electrónicos (p. ej., mediante un SMTP ficticio)

---

flowchart TD
    A[Funcionalidad lista para prueba] --> B[Limpiar sistema Dev y borrar tickets]
    B --> C[Copiar Dev -> Staging]
    C --> D[Esperar ventana de mantenimiento]
    D --> E[Realizar backup de datos de producción BD y archivos]
    E --> F[Transferir datos de producción al Staging]
    F --> G[Ajustar configuración en Staging]
    G --> H[Desactivar envío de correos]
    H --> I[Ejecutar pruebas]
    
    I -->|Pruebas exitosas| J[Opcional: Copiar Staging -> Producción]
    I -->|Pruebas fallidas| K[Corregir errores y volver a probar]

    J --> L[Activar producción]
    L --> M[Listo: Despliegue completado]

    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

🧱 Guía paso a paso

1. Configurar el sistema de Staging

Se recomienda una instalación con Docker:

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

2. Limpiar el sistema de desarrollo

Si utiliza un sistema de desarrollo como base:

# Borrar tickets y adjuntos
bin/otobo.Console.pl Admin::Delete::Tickets --older 1d --state closed --really
rm -rf /opt/otobo/var/article/*

---

3. Copiar los datos de producción

# Realizar backup de la base de datos (sistema de producción)
mysqldump -u root -p otobo > /tmp/otobo_prod.sql

# Realizar backup de artículos y Kernel
rsync -avz /opt/otobo/Kernel /tmp/Kernel
rsync -avz /opt/otobo/var/article /tmp/article

Importar en el Staging:

# Importar BD
mysql -u root -p otobo_staging < /tmp/otobo_prod.sql

# Copiar sistema de archivos
rsync -avz /tmp/Kernel /opt/otobo/Kernel
rsync -avz /tmp/article /opt/otobo/var/article

🔐 Protección de datos: Anonimice todos los datos de clientes de producción, por ejemplo, en la tabla customer_user, o elimine las direcciones de correo electrónico con un script SQL.

---

4. Ajustar la configuración

Kernel/Config.pm

$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'CONTRASEÑA_STAGING';

5. Impedir el envío de correos electrónicos

En SysConfig:

• Establecer SendmailModule en Kernel::System::Email::DoNotSendEmail
• Alternativamente: cambiar el servidor SMTP a 127.0.0.1 y puerto 1

---

🔬 Pruebas en el Staging

• Utilizar scripts de Playwright o Cypress para pruebas de UI
• Usar bin/otobo.Console.pl Maint::Test::System
• Verificar la integridad de los datos y el comportamiento de la UI
• Desactivar integraciones como LDAP o servicios web, o redirigirlos a un servidor de pruebas

---

🔐 Asegurar el Staging

• Restringir el acceso mediante VPN o lista blanca de IP
• Configurar robots.txt para evitar la indexación
• Si es necesario, implementar Basic-Auth mediante Nginx
• Asegurar SSL mediante certificado SAN o Wildcard (*.staging.example.com)

---

🔄 Opcional: Desplegar el Staging a producción

Una vez realizadas todas las pruebas en el Staging:

1. Detener el servidor de producción
2. Copiar la base de datos y los directorios del Staging a producción
3. Ajustar Config.pm
4. Reiniciar la producción

---

🧪 Herramientas de ejemplo para la automatización

• Playwright (para pruebas E2E)
• rsync para una transferencia de datos rápida
• docker-compose para un entorno orquestado
• cron o systemd para backups regulares
• Scripts de Python para anonimización o migración de estructuras

---

Conclusión

Un sistema de Staging de OTOBO o Znuny ofrece la máxima seguridad al introducir cambios. Mediante una migración estructurada, datos de prueba anonimizados y pruebas automatizadas, evitará interrupciones y garantizará despliegues estables.

🔁 Consejo: Integre los procesos de Staging en su pipeline de CI/CD para una garantía de calidad automatizada en cada cambio.