Cómo crear un sitio de staging PrestaShop

Por qué mantenemos tiendas de staging en cada proyecto que tocamos

En mypresta.rocks mantenemos varios entornos de staging en paralelo, incluidos ps9-dev, ps8-dev, ps178-dev y ps176-dev, además de tiendas específicas de cliente cuando un proyecto necesita su propio clon. No son un lujo. Son la forma en que probamos cada actualización de módulo, cada actualización de PrestaShop y cada cambio de tema antes de que ningún cliente lo vea. Tras una década publicando módulos, nunca hemos conocido a un comerciante que se arrepintiera de montar uno, y a muchos que se arrepintieron de saltárselo.

El patrón es siempre el mismo: una actualización de módulo llega a producción sin probar, la página de inicio se rompe a las 9 de la mañana, el ticket de soporte aterriza a las 9:05 y la hora siguiente se pasa depurando delante de clientes reales. Una tienda de staging cuesta una hora de montaje y convierte ese escenario en una corrección de 20 minutos sobre una URL que nadie puede ver.

El coste de una hora de inactividad durante una campaña de rebajas supera el coste de mantener un entorno de pruebas en dos órdenes de magnitud. Si vende en internet para ganarse la vida, necesita una tienda de staging.

Qué es realmente una tienda de staging

Es un clon completo de su tienda de producción (los mismos archivos, la misma base de datos, el mismo conjunto de módulos) servido desde una URL a la que solo usted y su equipo pueden llegar. Las mismas rutas de código que tocan sus clientes, la misma lógica de negocio, los mismos casos límite. Las únicas diferencias son el nombre de host, las credenciales y (si lo ha configurado correctamente) el hecho de que no se envía ningún correo real y no se cobra ninguna tarjeta real.

No es un entorno de desarrollo para trabajo desde cero, y no es una copia de seguridad. Hemos visto cómo ambos malentendidos cuestan dinero real a los comerciantes: el staging se sobrescribe en el momento en que lo refresca, así que todo lo que haya construido allí y no haya subido a producción se pierde.

Qué es el staging

• Una copia en vivo de sus archivos y base de datos de producción
• En un dominio o subdominio separado (nosotros usamos staging.yourshop.com o dev.yourshop.com)
• Protegido tras una lista blanca de IP o autenticación básica para que solo entre su equipo
• Donde se ensayan las actualizaciones de módulos, los cambios de tema y las actualizaciones de PHP

Qué no es

• Un entorno de pruebas de desarrollo para construir código nuevo desde cero. Eso es una tienda de desarrollo aparte
• Una copia de seguridad. Las copias de seguridad son inmutables. El staging se machaca en cada refresco.
• Algo para configurar y olvidar. Una tienda de staging que lleva seis meses desincronizada con producción no detecta nada.

Opción 1: staging basado en Docker (lo que usamos)

Todas nuestras tiendas de staging se ejecutan sobre Docker en una única máquina TrueNAS. Cada tienda es una pila de docker-compose en una red Docker compartida, contenedor de PrestaShop, contenedor de MySQL, Redis compartido, un bind mount para el directorio html, uno para los datos de MySQL. Podemos levantar una nueva versión de PS en menos de cinco minutos, y desmontarla para liberar RAM cuando hayamos terminado con ella. Una vez que lo haya hecho una vez, nunca volverá al «lo instalo y ya está en una subcarpeta de cPanel».

Requisitos previos

• Un host Linux con al menos 2 GB de RAM por tienda de staging (4 GB si quiere que el panel de administración se sienta ágil)
• Docker y Docker Compose instalados y funcionando
• SSH tanto a producción como a staging
• Que se sienta cómodo copiando y pegando comandos de shell

Paso 1: el archivo compose

Cree un directorio y un docker-compose.yml:

mkdir ~/your-shop-staging && cd ~/your-shop-staging

cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: <your-shop>
    ports:
      - "8080:80"
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=root
      - DB_PASSWD=your_secure_password
    volumes:
      - ./html:/var/www/html
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mysql:5.7
    container_name: <your-shop>-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_secure_password
      - MYSQL_DATABASE=prestashop
    volumes:
      - ./mysql:/var/lib/mysql
    restart: unless-stopped
EOF

Haga coincidir la etiqueta de la imagen de PrestaShop con su versión de producción exactamente. Si producción es 1.7.8.11, use prestashop/prestashop:1.7.8.11, no 1.7. Hemos visto a comerciantes perseguir errores fantasma durante horas porque staging estaba en 1.7.8.10 y producción en 1.7.8.11, lo bastante parecidos como para parecer idénticos, lo bastante distintos como para comportarse de forma diferente.

Paso 2: volcar producción

Conéctese por SSH a producción y ejecute mysqldump. Use --single-transaction en una tienda en vivo para no bloquear la tabla de pedidos mientras los clientes pasan por caja:

# En su servidor de producción
mysqldump -u root -p prestashop > ~/prestashop_backup.sql

# Descargar a su máquina local / servidor de staging
scp user@production-server:~/prestashop_backup.sql ./

Paso 3: importar en staging

# Iniciar los contenedores
docker compose up -d

# Esperar ~30 segundos a que MySQL se inicialice, luego importar
docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop < prestashop_backup.sql

Si MySQL se queja del juego de caracteres durante la importación, ponga SET NAMES utf8mb4; al principio del archivo SQL. Hemos dedicado más tiempo del que nos gustaría admitir a depurar UTF-8 con doble codificación en staging que no existía en producción.

Paso 4: copiar los archivos de producción

# Sincronizar sus archivos de producción con el directorio html de staging
rsync -avz --delete \\
  user@production-server:/var/www/html/ \\
  ./html/ \\
  --exclude='var/cache/*' \\
  --exclude='var/logs/*' \\
  --exclude='app/config/parameters.php'

Excluya siempre parameters.php de rsync. Las credenciales de la base de datos que contiene pertenecen a producción, si deja que rsync las copie por encima, su tienda de staging intenta conectarse a su base de datos de producción, que es el peor resultado posible de «configurar staging». Lo aprendimos por las malas en un proyecto de cliente en 2017 y desde entonces hemos escrito el flag de exclusión de forma automática.

Excluya también cualquier directorio de tiempo de ejecución en el que la tienda escriba en producción, sitemaps, imágenes generadas que no necesite, carpetas de copias de seguridad, claves de licencia. rsync --delete borra el lado de destino, y los rsyncs demasiado agresivos han eliminado sitemaps generados y roto Google Search Console más de una vez en nuestro turno.

Paso 5: reescribir las URL y limpiar la caché

La mayor causa de «por qué no funciona mi tienda de staging»: ps_shop_url sigue apuntando a producción. Corríjalo:

docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

Actualice html/app/config/parameters.php con las credenciales de la base de datos de staging de su archivo compose. Luego elimine la caché:

docker exec <your-shop> rm -rf /var/www/html/var/cache/*

Si se salta la limpieza de la caché, las plantillas compiladas de Smarty siguen incrustando la URL de producción y obtendrá bucles de redirección de vuelta a la tienda en vivo. En cualquier tienda que use OPcache (que es cualquiera en producción), reinicie también PHP-FPM o llame al endpoint de reinicio de OPcache.

Opción 2: subdominio en hosting compartido

Docker no está disponible en cPanel, Plesk ni DirectAdmin. Obtendrá el mismo resultado con un subdominio, una segunda base de datos y una copia de archivos.

Cree el subdominio

1. En el panel de hosting, vaya a Subdominios o Dominios
2. Añada staging.yourshop.com
3. Apúntelo a un directorio nuevo como /home/user/staging.yourshop.com

Cree una base de datos separada

1. Abra Bases de datos MySQL
2. Cree algo como user_staging
3. Cree o asocie un usuario con todos los privilegios sobre ella

Copie los archivos e importe el volcado

Por SSH:

cp -r /home/user/public_html/* /home/user/staging.yourshop.com/

# Exportar producción
mysqldump -u user -p production_db > ~/staging_import.sql

# Importar a staging
mysql -u user -p staging_db < ~/staging_import.sql

Edite app/config/parameters.php (o config/settings.inc.php en la 1.6) para que apunte a la nueva base de datos, luego ejecute el mismo SQL de reescritura de URL de la opción 1, paso 5. No olvide eliminar var/cache/ después.

Opción 3: desarrollo local con XAMPP/MAMP

Está bien para el trabajo de «permítame revisar la pantalla de administración de este módulo durante diez minutos», inútil para cualquier otra cosa. La versión de PHP, la versión de MySQL, el modelo de permisos de archivos y las extensiones a nivel de sistema operativo serán todos distintos de su servidor de producción. Nosotros mismos usamos pilas locales, pero nunca como prueba final antes de desplegar, cualquier cosa que esté a punto de tocar producción se vuelve a probar en un staging basado en servidor que refleje el entorno de producción.

Tras la configuración: lo que le muerde si lo olvida

Corte el correo saliente de inmediato

Su base de datos de staging contiene todas las direcciones de correo de clientes reales. Active un restablecimiento de contraseña, una confirmación de pedido o un cron de notificación de stock, y esos correos van a clientes reales. Hemos visto a comerciantes disculparse públicamente porque su cron de staging envió «su pedido ha sido enviado» a mil clientes reales cuyos pedidos, de hecho, no se habían enviado.

Vaya a Parámetros avanzados → Correo electrónico y, o bien:

• Ponga el método en «No enviar nunca correos electrónicos»: la única opción totalmente segura
• Encamine todo a través de Mailtrap para que pueda seguir inspeccionando los correos renderizados sin entregarlos

Desactive los módulos de pago

Stripe, PayPal, Klarna, Adyen, cualquier cosa conectada a una cuenta de comerciante en vivo. O bien desactive los módulos por completo en staging, o cambie cada uno a modo sandbox/prueba. Lo mismo se aplica a las API de envío (etiquetas de UPS, DHL, GLS) y a cualquier módulo que llame a un servicio externo con efectos secundarios facturables.

Bloquee los motores de búsqueda

Una tienda de staging indexada por Google es un desastre de contenido duplicado. Tres cosas que hacer, por si acaso:

• Desactive el sitemap XML en Parámetros de la tienda → Tráfico y SEO
• Coloque un robots.txt con User-agent: * y Disallow: / en la raíz
• Mejor aún, bloquee el acceso público por completo (siguiente sección) para que Google nunca llegue a ella en primer lugar

Protéjala tras una lista blanca de IP

El enfoque más fiable es una restricción de IP a nivel de Apache o Nginx. El modo de mantenimiento se puede saltar si el ajuste de la lista blanca de IP tiene un fallo, y la autenticación básica HTTP a veces rompe los módulos con mucho AJAX (la hemos visto matar nuestros propios paneles de administración cuando el navegador no podía transportar la cabecera de autenticación a través de XHR). Una lista blanca de IP a nivel de servidor web atrapa todo antes de que PrestaShop se ejecute.

Mantener staging sincronizado con producción

Una tienda de staging que lleva tres meses obsoleta es peor que no tener staging, le da una falsa confianza. Nosotros refrescamos las nuestras según un calendario y antes de cualquier despliegue significativo.

Cuándo refrescar

• Antes de cualquier cambio relevante: actualización de módulo, actualización del core, subida de versión de PHP, reforma de tema
• Mensualmente como mínimo si está desarrollando activamente
• Tras cualquier cambio grande de catálogo en producción, nuevos árboles de categorías, cambios estructurales de productos, reorganizaciones de características/atributos

Script de refresco (Docker)

#!/bin/bash
# refresh-staging.sh: Traer los datos más recientes de producción a staging

# 1. Volcar la BD de producción
ssh production "mysqldump -u root -p'PASS' prestashop" > /tmp/staging_refresh.sql

# 2. Importar a staging
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop < /tmp/staging_refresh.sql

# 3. Corregir las URL
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

# 4. Sincronizar archivos
rsync -avz --delete production:/var/www/html/ ./html/ --exclude='var/cache/*' --exclude='app/config/parameters.php'

# 5. Limpiar la caché
docker exec <your-shop> rm -rf /var/www/html/var/cache/*

echo "Staging refreshed."

Los errores que seguimos viendo cometer a los comerciantes

Claves de API de producción dejadas en su sitio

La cantidad de tiendas de staging que hemos auditado que estaban silenciosamente realizando cobros reales de Stripe, llamando a API de envío reales para etiquetas de seguimiento en vivo o consumiendo límites de tasa de API reales porque las claves vinieron con la base de datos, demasiadas para contarlas. Rote toda credencial externa a una clave de sandbox en staging en el momento en que aterrice la base de datos, antes incluso de abrir el panel de administración.

Crons que siguen disparándose

Si ha configurado tareas cron en producción (recordatorios de carritos abandonados, sincronización de stock, generación de feeds, renovaciones de licencias) compruebe que su panel de hosting o sus temporizadores de systemd no estén ejecutando las mismas tareas en el nombre de host de staging. Tuvimos un cliente cuya tienda de staging estuvo enviando alegremente actualizaciones de stock reales a Allegro durante dos semanas antes de que nadie se diera cuenta.

Ambos paneles de administración abiertos en el mismo navegador

Las cookies de administración de PrestaShop tienen como ámbito el dominio, pero los conflictos de sesión siguen ocurriendo cuando tiene ambas tiendas autenticadas en el mismo navegador. Use un navegador aparte, un perfil aparte o una ventana de incógnito para staging. Cada miembro de nuestro equipo tiene un perfil de Firefox dedicado para las tiendas de staging de clientes.

Cuándo probar en staging y cuándo producción está bien

Vale la hora

La primera configuración de staging lleva alrededor de una hora. Un refresco, una vez que el script está en su sitio, son cinco minutos. La primera vez que staging detecte una actualización de módulo que habría roto su proceso de compra, habrá recuperado la inversión diez veces, y lo hemos visto suceder en tiendas reales que gestionamos. Docker es lo que nosotros elegiríamos si tiene un VPS o una máquina dedicada; la clonación por subdominio es la decisión correcta en hosting compartido. En cualquier caso, el objetivo es el mismo: nada sin probar toca a sus clientes.

Si está montando staging específicamente para probar nuestros módulos, nuestro programa Prueba antes de comprar le ofrece una demo completa de 30 días de cualquier módulo, instálelo en staging, póngalo a prueba, decida antes de pagar.

Lecturas relacionadas

• Cómo probar correctamente los módulos de PrestaShop: qué hacer realmente una vez que staging está en marcha
• Desarrollo local de PrestaShop: configuración con XAMPP, WAMP, Docker y Linux: el paso de desarrollo local previo a staging
• Docker para PrestaShop: configuración del entorno de desarrollo: cómo ejecutamos nuestros contenedores en detalle
• Configuración de Docker para PrestaShop: entornos de desarrollo y producción
• Eliminar pedidos de prueba: limpiar PrestaShop antes de pasar a producción

Módulos relacionados

• Password Protection: proteja la tienda de staging tras una contraseña / lista blanca de IP
• MPR Cron Manager: controle qué crons se disparan en staging
• Performance Revolution: pruebe los cambios de rendimiento antes de que lleguen a producción

Preguntas relacionadas

• ¿Cómo limpio correctamente la caché de PrestaShop?
• ¿Puede MPR Digital Revolution ofrecer descargas demo, trial o gratuitas para productos PrestaShop?