Actualiza PrestaShop en un entorno de pruebas (staging): el paso que evita el 90% de los sustos

Actualiza PrestaShop en un entorno de pruebas
Solucionex
21
Abr 26

Este post pertenece a una serie de posts explicativos de Actualizaciones en PrestaShop sin sustos. Puedes ver los posts previos en estos enlaces:

  • Capítulo 1/7: Tipos de actualizaciones en PrestaShop: cuáles hay y por qué importan. Ver publicación.

  • Capítulo 2/7: Cada cuánto actualizar PrestaShop: frecuencia recomendada y señales de alerta. Ver publicación.

  • Capítulo 3/7: Copias de seguridad y vuelta atrás en minutos. Ver publicación.

Por qué “staging” es la mejor inversión antes de actualizar

Actualizar directamente en producción es el equivalente a “cambiar el motor del coche en plena autopista”. A veces sale bien, pero cuando sale mal… el coste real llega en forma de ventas perdidas, errores difíciles de reproducir y horas de investigación.

Un staging (entorno de pruebas) te permite:

  • Ensayar la actualización sin impactar a clientes.

  • Detectar incompatibilidades de módulos y tema antes de que sea tarde.

  • Medir si hay cambios de rendimiento, errores JS, fallos en checkout, etc.

  • Tener un “OK” objetivo antes de pasar a producción.

Qué es exactamente un staging (y qué NO es)

Un staging es una copia funcional de tu tienda: mismo PrestaShop, mismos módulos, mismo tema, mismos datos (o datos anonimizados), pero en otra URL y sin indexación.

Lo que NO es staging:

  • Un “backup” descargado y guardado en local.

  • Un clon incompleto sin imágenes o sin base de datos real.

  • Un entorno que comparte base de datos con producción (eso es una bomba de relojería).

Requisitos mínimos de un staging “de verdad”

Para que el staging sirva, tiene que cumplir estos puntos:

1) Misma versión y stack

  • Misma versión de PHP y extensiones

  • Misma configuración de servidor (Apache/Nginx), límites de memoria, etc.

2) Misma base de datos (idealmente)

  • Si copias la BD real, lo ideal es anonimizar (emails, teléfonos, direcciones) o restringir accesos.

3) Misma carpeta /img

  • Muchas pruebas (tema, listados, producto) dependen de imágenes.

4) No indexable

  • Añadir noindex o bloquear por robots

  • Proteger con contraseña / IP whitelist

5) Mails y pagos “capados”

  • Desactivar envío real de emails o redirigir a buzón de pruebas.

  • Checkout con pasarelas en modo sandbox o desactivadas.

Formas de montar staging (de simple a pro)

Opción A: “Clonado rápido” en subdominio (válido para la mayoría)

  • staging.tutienda.com

  • Copia de archivos + BD

  • Ajustes de dominio/URL en PrestaShop

Pros: rápido y económico
Contras: hay que hacerlo bien para que sea fiable

Opción B: Staging gestionado por hosting (si tu proveedor lo ofrece)

Algunos hostings permiten “crear staging” con un click.

Pros: rápido y suele incluir mapeo de URL
Contras: a veces no clona todo igual (cron, workers, cachés, etc.)

Opción C: Entorno “pro” con Docker/CI (para equipos técnicos o tiendas grandes)

  • Staging reproducible

  • Deploy automatizado

  • Tests automatizados

Pros: calidad top, escalable
Contras: más inversión inicial

Checklist de pruebas antes de pasar a producción

Una actualización “aprobada” en staging no es “entra al back y no rompe”. Tiene que pasar un checklist.

A. Navegación y rendimiento

  • Home, categorías, fichas de producto

  • Búsqueda

  • Paginación y filtros

  • Tiempo de carga razonable

B. Carrito y checkout (crítico)

  • Añadir al carrito

  • Cupones / descuentos

  • Gastos de envío

  • Método de pago (sandbox)

  • Confirmación de pedido

C. Back-office

  • Acceso sin errores

  • Crear/editar producto

  • Crear/editar CMS

  • Pedido en admin: estados, facturas, devoluciones

D. Módulos clave

  • Métodos de pago (PS Checkout, Redsys, Stripe…)

  • Transportistas

  • Facturación, ERP, marketplaces

  • SEO: redirecciones, sitemap, URLs amigables

E. Logs

  • Revisar var/logs (si aplica en tu versión)

  • Revisar consola del navegador (errores JS)

“Vale, pero… ¿qué pasa con los datos reales?”

Buena pregunta. Hay dos enfoques:

1) Clonar BD real (recomendado para fiabilidad)

  • Pro: descubres problemas reales

  • Contra: debes anonimizar o restringir acceso

2) Usar BD “de muestra”

  • Pro: menos riesgo de privacidad

  • Contra: te puedes comer un bug en producción que staging nunca vio

En la práctica, para actualizaciones serias, la copia real (controlada) es la mejor.

Cómo pasar a producción sin sorpresas (mini-plan)

Una vez staging está OK, el salto a producción se hace con un plan:

  1. Ventana de mantenimiento (si aplica)

  2. Backup + snapshot (Capítulo 3)

  3. Actualizar en producción replicando exactamente los pasos de staging

  4. Validación express: checkout, login admin, páginas clave

  5. Monitorizar 30–60 min: logs, rendimiento, pedidos

Errores típicos que staging te ayuda a evitar

  • “En mi ordenador iba”: en producción se rompe por caché, PHP distinto, permisos, etc.

  • Módulo de pago incompatible: checkout muerto.

  • Tema con overrides antiguos: errores silenciosos hasta que el cliente intenta comprar.

  • JS roto: el carrito no responde, y lo descubres tarde.

  • SEO afectado: URLs o redirecciones cambiadas.

Cierre

Si te quedas con una idea de este capítulo es esta: actualizar sin staging es jugar a la ruleta. Un entorno de pruebas bien montado convierte las actualizaciones en un proceso repetible, predecible y controlado.

En el Capítulo 5/7 veremos el “núcleo duro” del proceso: la compatibilidad de módulos y tema, cómo detectar qué va a fallar antes de actualizar y cómo priorizar actualizaciones para no bloquear tu tienda. ver capítulo 5: Actualiza PrestaShop en un entorno de pruebas (staging): el paso que evita el 90% de los sustos

PrestaShop