Crea y actualiza un sitio privado de pruebas de PrestaShop

Qué haríamos

Acordaríamos el cambio y sus pruebas de aceptación antes de crear la copia. La vía adecuada depende de tu tienda actual: sus módulos, integraciones, tema, datos, mercados y las personas que la probarán y mantendrán. Un cambio de entrega necesita direcciones y transportistas representativos; una actualización de versión requiere un ensayo más amplio de las dependencias de la tienda. Deja fuera de esa prueba las mejoras no relacionadas para poder rastrear la causa de cualquier fallo.

Usa una copia de pruebas limpia y aislada para ensayar el cambio previsto y planifica después el paso a producción con un responsable de la decisión y una vía de recuperación. Decide si desplegarás un paquete probado en la tienda actual o migrarás la tienda y conciliarás sus datos finales. Son planes de lanzamiento distintos: superar las pruebas en la copia de ayer no resuelve qué ocurrirá con los pedidos de hoy.

Si quieres que nos encarguemos de un cambio de versión, el PrestaShop Upgrade Service: Any Version to PrestaShop 9 parte de los requisitos de tu tienda y de un ensayo en el entorno de pruebas.

Define qué vas a probar en el entorno de pruebas

Un sitio de staging es una copia privada utilizada para ensayar cambios con archivos, datos, temas y módulos representativos de la tienda. Te ayuda a encontrar conflictos de módulos, actualizaciones fallidas, fallos de pago y regresiones de rendimiento antes del despliegue.

Mantén el trabajo de desarrollo bajo control de versiones o un entorno de desarrollo separado. Actualizar la copia de pruebas puede sustituir los cambios locales. Conserva también copias de seguridad independientes y recuperables. El entorno de pruebas no es una copia de seguridad, y la inmutabilidad de las copias solo existe si configuras un almacenamiento y una retención adecuados.

Registra la versión de parche de PrestaShop en producción, la versión y extensiones de PHP, la versión de base de datos, las reglas del servidor web, el tema, los módulos, las tareas y las dependencias externas. Parte de esa base. Cambia una variable prevista, como PHP o la versión de un módulo, cuando pruebes una actualización.

Utiliza el entorno de pruebas para actualizaciones del núcleo o PHP, instalación de módulos, cambios de tema, overrides, migraciones de base de datos y cambios importantes de impuestos, envío o pago. El trabajo rutinario de contenido puede recibir una revisión proporcional, pero editar un precio, un envío o un impuesto también puede afectar al pago y merece pruebas.

Restringe el acceso y los efectos externos antes de copiar datos

1. Crea un directorio, una base de datos y un usuario de base de datos separados para pruebas. Restringe ese usuario a la base de datos de pruebas.
2. Aplica autenticación en el servidor web, una lista de permitidos a nivel de red o una red privada antes de introducir datos de producción en el entorno. Incluye la tienda, la administración, los archivos estáticos y los endpoints auxiliares.
3. Mantén detenidos el tráfico de la aplicación, las tareas cron, los procesos de trabajo y las tareas programadas durante la clonación y el saneamiento de datos y ajustes.
4. Restringe las conexiones salientes para que las credenciales copiadas no puedan acceder a servicios reales de pago, correo, envío, ERP, marketplaces o webhooks.
5. Guarda los volcados y las credenciales fuera de la raíz web con permisos restringidos.

El modo de mantenimiento y robots.txt no proporcionan un control de acceso completo. Un módulo que protege la tienda con contraseña no protege todos los archivos ni los endpoints administrativos. Password Protection controla el acceso a las solicitudes del front office; su página de ayuda explica ese alcance en la tienda.

Usa credenciales de servicios exclusivas del entorno de pruebas y un transporte de captura de correo. Minimiza o anonimiza los datos de los clientes según las pruebas que necesites. Conserva las relaciones y los formatos necesarios para que las pruebas sean significativas: eliminar direcciones o registros de personalización indiscriminadamente puede ocultar fallos del proceso de compra. Da preferencia a clientes de prueba ficticios cuando sus datos sean suficientes. Limita el acceso a los datos personales copiados y elimina los clones y volcados obsoletos.

Verifica que las solicitudes no autorizadas no puedan recuperar una imagen, una URL administrativa, una copia de configuración o un volcado de base de datos. Prueba el control de acceso antes de permitir que arranque la aplicación.

Elige un entorno de alojamiento o contenedores equivalente

Contenedores

Fija la imagen exacta de aplicación/PHP y la versión de base de datos, preferiblemente con identificadores hash inmutables de las imágenes. Una imagen sin versión o una etiqueta genérica no reproduce producción. Utiliza un volumen y una base de datos separados para pruebas. Configura explícitamente el host de base de datos de la aplicación, como el nombre de servicio de Compose db.

Publica un puerto local solo cuando sea necesario, por ejemplo 127.0.0.1:8080:80, detrás de una vía de acceso autenticada. Publicar 8080:80 generalmente expone el puerto en las interfaces del host. Sigue la documentación de Docker sobre enlace de puertos y aplica controles de salida por separado.

Inicia solo la base de datos durante la importación. Espera una comprobación real de disponibilidad en lugar de una pausa fija. Prepara la configuración de pruebas de la aplicación clonada antes de iniciar su servicio web o sus procesos de trabajo. Comprueba el punto de entrada de la imagen para que la instalación automática o las tareas de arranque no puedan ejecutarse con ajustes de producción copiados.

Utiliza la versión real de la base de datos de producción para reproducir un entorno antiguo y después prueba por separado una vía de actualización compatible. MySQL 5.7 es una dependencia antigua, no un valor predeterminado para un entorno de pruebas nuevo. Evita compartir espacios de nombres de caché/sesiones con producción.

Subdominio en el panel de alojamiento

Crea un subdominio privado con su propia raíz de documentos y base de datos. Aplica restricciones antes de importar. Comprueba los permisos reales del plan: el nombre de un panel no determina la disponibilidad de Docker, y algunos proveedores ofrecen compatibilidad con contenedores.

Desarrollo local

Docker, XAMPP, MAMP, WAMP o una pila Linux local pueden ser útiles para probar. Iguala los detalles pertinentes del entorno de ejecución y vuelve a probar los comportamientos específicos de plataforma en el entorno de despliegue. La etiqueta del sistema operativo por sí sola no determina si una prueba local es útil.

Sigue la guía de Docker y la guía de desarrollo local para configurar el entorno.

Copia una base de datos coherente y todos los archivos

Haz una copia de recuperación y registra la hora de la instantánea. Para tablas transaccionales InnoDB, mysqldump --single-transaction puede proporcionar una instantánea coherente sin bloquear las escrituras normales durante todo el volcado. No hace coherentes las tablas no transaccionales ni protege frente a cambios simultáneos del esquema. Coordina la instantánea de archivos/base de datos para las subidas y descargas que cambian.

Utiliza una cuenta de copias restringida y una configuración de cliente segura o una solicitud interactiva de contraseña. Evita las contraseñas en argumentos de shell y scripts. Comprueba la finalización del volcado, el estado de salida y el tamaño del archivo antes de importar en la base de datos de pruebas confirmada. Espera a que la base de datos esté disponible y aborta si falla cualquier importación.

Copia los archivos ocultos, módulos, overrides, temas, imágenes, descargas, subidas y recursos personalizados. Excluye los ajustes de conexión específicos del entorno y las cachés de ejecución cuando corresponda. Por ejemplo, estas rutas locales describen una instantánea ya obtenida y una raíz de pruebas separada:

rsync -av   --exclude='app/config/parameters.php'   --exclude='var/cache/'   --exclude='var/logs/'   /srv/prestashop-snapshot/   /srv/prestashop-staging/html/

La barra final del origen copia el contenido del directorio, incluidos los archivos ocultos. La alternativa cp -a /srv/prestashop-snapshot/. /srv/prestashop-staging/html/ también incluye los archivos ocultos, pero copia configuración que debes sustituir antes de cualquier solicitud a la aplicación.

Confirma origen y destino antes de sincronizar. Para actualizaciones de la copia que utilicen borrado, examina una simulación y protege los archivos exclusivos de pruebas. Nunca elijas la raíz de documentos de producción como destino.

Para PrestaShop 1.7 a 9, prepara explícitamente app/config/parameters.php con credenciales de base de datos exclusivas de pruebas. La configuración antigua de 1.6 es config/settings.inc.php. Conserva o sustituye las claves criptográficas de forma deliberada, teniendo en cuenta la compatibilidad de contraseñas y datos cifrados. Copiar claves no justifica conservar credenciales de servicios externos reales.

Diagnostica los errores de importación a partir de la salida real de la base de datos. Comprueba versiones, juegos de caracteres, intercalaciones y compatibilidad DDL. Añadir SET NAMES utf8mb4 no es una reparación general para intercalaciones incompatibles o datos previamente mal codificados. Utiliza las opciones de volcado y restauración correspondientes.

Reescribe todas las URL de tienda y sanea las integraciones

Trabaja solo en la base de datos de pruebas confirmada mientras el tráfico y las tareas de la aplicación siguen detenidos. Identifica el prefijo de tablas configurado y cada URL de tienda y registro de configuración con su ámbito. No supongas que el ID de tienda es 1.

Empieza con una inspección de solo lectura. Estos ejemplos utilizan el prefijo ilustrativo ps_:

SELECT id_shop_url, id_shop, domain, domain_ssl,
       physical_uri, virtual_uri, main, active
FROM ps_shop_url
ORDER BY id_shop, id_shop_url;

SELECT id_configuration, id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL')
ORDER BY id_shop_group, id_shop, name;

Define una correspondencia explícita entre cada fila de URL pertinente y el nombre de host y la ruta física o virtual del entorno de pruebas. Actualiza las filas de configuración correspondientes según su ámbito o sus ID reales. Conserva la topología multitienda prevista. Revisa los ajustes de módulos, las redirecciones, los dominios de servidores multimedia, la configuración canónica y las URL codificadas para localizar destinos de producción restantes. Si una URL sigue volviendo a producción, inspecciona la cadena de redirecciones y las cabeceras de respuesta: una regla antigua del servidor web, un proxy inverso o un ajuste de CDN pueden redirigir antes de que PrestaShop gestione la solicitud. Mantén los nombres de host y certificados de pruebas separados del enrutamiento de producción.

1. Sustituye las credenciales de pago reales por credenciales de pruebas o desactiva la integración.
2. Desactiva la compra de etiquetas y otras acciones de envío facturables. Utiliza un servicio de pruebas cuando esté disponible.
3. Desactiva o aísla las conexiones de ERP/WMS, marketplaces, stock de proveedores, CRM, marketing, analítica y webhooks salientes.
4. Configura el correo del núcleo para desactivar el envío o utilizar un transporte de captura en Parámetros avanzados > Correo electrónico. Cubre los clientes SMTP independientes de módulos y las API de correo con captura verificada o restricciones de salida.
5. Desactiva las tareas de producción en cron del sistema, temporizadores, paneles de alojamiento, programadores de módulos, procesos de colas y programadores externos.
6. Desactiva la generación y el envío de sitemaps de pruebas en el módulo de sitemap instalado y elimina los archivos generados exclusivos de producción cuando corresponda.
7. Utiliza controles de acceso privados, además de cabeceras noindex o reglas de robots como controles adicionales de indexación.

Los ajustes de correo del núcleo por sí solos no pueden bloquear el transporte independiente de todos los módulos. Reescribir DNS o URL por sí solo no neutraliza una clave de pago real. Mantén las restricciones de salida hasta comprobar cada integración.

Vacía las cachés y prueba el clon aislado

Cuando se hayan completado la configuración de pruebas y el saneamiento de datos y ajustes, vacía las cachés de la aplicación adecuadas para la versión como usuario de la aplicación. En una tienda moderna, las cachés de Smarty y del framework utilizan rutas específicas por entorno dentro de var/cache. Las versiones antiguas tienen estructuras distintas.

Utiliza la operación de vaciado compatible de la aplicación desde la raíz de pruebas confirmada. En un contenedor, ejecútala mediante el servicio de aplicación en su directorio de trabajo de la tienda. Docker exec no expande por sí mismo los comodines del shell; un shell del host puede expandir un comodín sin comillas sobre el sistema de archivos equivocado. Evita recetas de borrado amplio.

Si los ajustes de despliegue lo requieren, reinicia OPcache del entorno web de pruebas mediante el procedimiento del alojamiento/servicio. Un reinicio solo desde CLI normalmente no reinicia la caché de PHP-FPM. Comprueba los permisos y la reconstrucción de la caché antes de abrir la vía web restringida.

1. Confirma que la aplicación solo se conecta a la base de datos de pruebas.
2. Comprueba las URL de inicio, categoría, producto y administración de cada tienda en busca de redirecciones a producción.
3. Examina los registros en busca de errores de base de datos, permisos, plantillas y PHP.
4. Realiza un pedido de prueba con cada método de pago en modo de pruebas, incluidas las notificaciones de pago asíncronas cuando se utilicen. Confirma que el proveedor apunta a la URL de retorno del entorno de pruebas y puede acceder al endpoint necesario sin exponer el resto del clon. Verifica los impuestos, el envío, los descuentos, el stock y los reembolsos.
5. Activa un correo de prueba y confirma que solo llega al sistema de captura.
6. Comprueba los intentos de conexiones salientes y verifica que los servicios reales siguen bloqueados.
7. Verifica que las tareas siguen detenidas salvo las activadas explícitamente para una prueba.

Usa un perfil de navegador separado para reducir errores humanos al trabajar con producción y pruebas. Comprueba los nombres de las cookies y los atributos Domain, especialmente si ambos entornos comparten un dominio padre: algunas cookies pueden llegar a ambos hosts. Usa el perfil de navegador separado para mantener sus sesiones independientes. Identifica claramente el nombre de host y la administración del entorno de pruebas.

Prueba una actualización de un módulo de entrega

Supón que tus tiendas del Reino Unido y Francia comparten un módulo de entrega y que los pedidos aceptados se exportan a un almacén. Antes de actualizarlo, documenta un carrito representativo de cada mercado: dirección, idioma, moneda, productos, transportista, gastos de envío e importe final. Incluye un carrito que las restricciones del transportista deban rechazar. Estos serán los resultados esperados, en lugar de limitarte a comprobar que se abre el proceso de compra.

En la copia aislada, instala la versión propuesta y compara los mismos carritos. Completa un pago en modo de pruebas e inspecciona el transportista, la dirección de entrega y los datos de exportación del pedido resultante sin enviarlos al almacén real. Confirma que no se haya comprado ninguna etiqueta de pago. Si una tarifa negociada de transportista no tiene equivalente de pruebas, documenta esa carencia y acuerda por separado una comprobación controlada en producción.

Inspecciona las exportaciones en cola además de las solicitudes inmediatas. Una conexión bloqueada con el almacén puede dejar tareas pendientes de reintento; no conectes después esa cola de pruebas a la cuenta real para ver si se vacía. Usa un destino de pruebas aislado o inspecciona los datos en cola. Conserva los resultados esperados y reales junto a la versión del paquete para que el personal pueda aprobar este cambio basándose en pruebas.

Prueba un módulo y ensaya el despliegue

1. Lee los requisitos del módulo sobre versiones, PHP, tema, multitienda y licencia. Examina el contenido del paquete y las dependencias externas. Buscar cadenas de eval o decodificación base64 no es una revisión de seguridad completa.
2. Haz una instantánea de recuperación de pruebas y registra las páginas y los tiempos de referencia.
3. Instala el ZIP exacto de la versión mediante el Gestor de módulos. Comprueba errores de instalación, tablas creadas, registro de hooks y registros.
4. Guarda la configuración y utiliza la función prevista. Comprueba las páginas de inicio, categoría, producto, carrito, pago y cuenta según corresponda.
5. Prueba en móvil, en los idiomas/monedas compatibles y en cada contexto multitienda que utilices. Examina los errores del navegador y las solicitudes fallidas.
6. Completa los procesos de compra, cancelación y reembolso en modo de pruebas. Comprueba los módulos existentes importantes junto con la nueva función.
7. Compara mediciones repetidas de tiempos y comportamiento de páginas con condiciones equivalentes de caché y tráfico.
8. Prueba el comportamiento de actualización, desactivación y desinstalación en una copia desechable. Algunos módulos conservan deliberadamente datos de negocio; compara la limpieza con la política documentada.

Confirma los derechos para dominio de producción, dominio de pruebas, localhost y período de prueba de cada licencia. No supongas que todos los módulos ofrecen activaciones locales gratuitas ilimitadas o un período de demo idéntico. Para dudas de licencias de mypresta.rocks, utiliza la guía de licencias o contacta con soporte.

Si quieres que instalemos y comprobemos un paquete existente, el PrestaShop Module Installation & Configuration Service cubre su configuración acordada y el recorrido del cliente o del personal.

Aprueba el resultado y planifica el paso a producción

Pide al propietario o al evaluador designado que apruebe el resultado de negocio y deja al desarrollador la responsabilidad de aportar las pruebas técnicas. Mantén visibles los fallos sin resolver y las integraciones sin probar; una instalación sin errores no equivale a la aceptación del proceso de compra.

1. Documenta la instantánea de tienda probada, el entorno de ejecución, las versiones de los paquetes y los cambios de configuración. Una actualización posterior de la copia o del código puede invalidar ese resultado.
2. Conserva los resultados esperados y reales de los mercados, dispositivos e integraciones afectados, incluidos los fallos y las vías de recuperación.
3. Confirma quién desplegará el cambio, quién puede detener el paso a producción y quién vigilará después los pedidos, los pagos y la preparación de pedidos.
4. Acuerda la ventana de lanzamiento y cualquier pausa de pedidos, ediciones del personal o importaciones. Usa el ensayo para estimar la interrupción en lugar de prometer una duración fija.
5. Demuestra la recuperación en una copia desechable y define el fallo que la desencadena. Incluye en ese plan los cambios de base de datos y la nueva actividad comercial.

Antes del despliegue en producción, crea una copia de seguridad reciente y recuperable de producción y acuerda el procedimiento para revertir el cambio. Despliega el paquete probado y la configuración prevista durante una ventana adecuada. Realiza una comprobación básica en producción y supervisa los registros y el flujo de pedidos. Excluye de la configuración de producción las credenciales exclusivas de pruebas, los pedidos de prueba y las restricciones específicas de ese entorno. Conserva los ajustes de privacidad y consentimiento previstos para producción.

Separa los archivos de la versión de los datos comerciales finales

Para un cambio de módulo o tema, despliega los archivos probados y los ajustes previstos sobre los datos actuales de producción mediante el procedimiento de instalación o actualización compatible. No sustituyas la base de datos de producción por la de pruebas. Los pedidos de prueba, los clientes anonimizados y los valores antiguos de stock no deben pasar a producción.

Para una migración de versión o una tienda de sustitución, ensaya por separado la conciliación final de datos. Identifica qué ha cambiado desde la instantánea: pedidos, clientes, stock, ediciones del catálogo, reembolsos y estado de las integraciones. Usa el proceso de copia final o de cambios incrementales admitido por la migración, teniendo en cuenta las diferencias de esquema. Si no existe un proceso incremental compatible, ensaya una pausa de escrituras que cubra la instantánea final de producción, la migración y la validación, y acuerda esa interrupción antes de aprobar el cambio. Una fusión a ciegas de tablas seleccionadas puede romper relaciones aunque coincida el número visible de pedidos.

En el momento acordado, coordina las escrituras del proceso de compra, el trabajo del personal, las importaciones, los procesos de trabajo y las notificaciones de pago retrasadas para que la actividad comercial no se reparta entre la tienda antigua y la nueva. Concilia los registros finales y las colas de integración antes de permitir la preparación de pedidos. Tras reabrir, restaurar una copia de seguridad anterior puede perder pedidos nuevos o actualizaciones de pagos; la recuperación debe tener en cuenta esa actividad. Restaurar solo los archivos PHP antiguos no revierte una migración incompatible de base de datos.

Qué preguntar al desarrollador o a la agencia

• ¿Qué diferencias respecto a producción persisten en el entorno de pruebas y qué nos impiden demostrar?
• ¿Qué archivos, ajustes y cambios de esquema desplegarás y qué datos se conservarán en su sitio?
• ¿Cómo se conciliarán los pedidos, pagos, reembolsos y cambios de stock finales si se traslada toda la tienda?
• ¿Dónde están las pruebas de aceptación y los pasos de recuperación, y quién responde ante un incidente después de reabrir?

Repite el aislamiento en cada actualización de la copia

Actualiza la copia antes de pruebas importantes cuando el clon ya no represente producción. Elige la frecuencia según tus cambios de versiones y catálogo, en lugar de prometer un tiempo fijo de preparación o actualización de la copia.

1. Conserva cualquier trabajo que deba sobrevivir a la actualización de la copia.
2. Vuelve a aplicar las restricciones de acceso y salida y después detén el tráfico de la aplicación, las tareas y los procesos de trabajo.
3. Obtén y verifica una instantánea nueva. Aborta si falla el volcado, la transferencia o la importación.
4. Importa en la base de datos de pruebas y sincroniza los archivos de pruebas confirmados.
5. Vuelve a preparar los ajustes de conexión de pruebas y asigna cada URL de tienda.
6. Vuelve a aplicar la captura de correo, las credenciales de pruebas, los controles de programadores, la minimización de datos y las restricciones de integraciones. La nueva base de datos ha restaurado los ajustes de producción.
7. Vacía las cachés de pruebas y verifica los permisos del entorno de ejecución.
8. Repite las comprobaciones de aislamiento y del proceso de compra antes de habilitar el uso restringido.

Automatízalo como pasos que se detengan de forma segura ante fallos: comprueba la disponibilidad de la base de datos, los estados de salida de comandos y que las copias no estén vacías, y detente ante cualquier error. Informa de una actualización de la copia correcta solo después de validarla. Mantén separadas la instantánea de producción y la configuración de pruebas para que una actualización de la copia no pueda restaurar silenciosamente el acceso a servicios reales.

Utiliza la guía de pruebas de módulos y la guía de copias de seguridad para mantener la lista de comprobación para cada lanzamiento.

Preguntas de los propietarios de tiendas

¿Y si una integración no tiene entorno de pruebas?

Usa un sustituto aislado o inspecciona la solicitud sin enviarla y deja constancia de que la interacción real no se ha probado. Acuerda cualquier validación necesaria en producción con el proveedor y la persona responsable de la facturación o de la preparación de pedidos. Una solicitud bloqueada demuestra el aislamiento, pero no que la integración funcione.

¿Puede el desarrollador actualizar la copia mientras el personal la está validando?

Acuerda una ventana de pruebas e identifica la compilación que se está revisando. Actualizar la copia cambia los datos y puede restablecer la configuración, así que avisa a los evaluadores y repite las comprobaciones afectadas. No combines resultados de compilaciones distintas como si describieran la misma versión.

¿Por qué el entorno de pruebas puede parecer más rápido que la tienda en producción?

Puede tener menos visitantes, otros recursos o un comportamiento distinto de la caché y los servicios externos. Documenta esas diferencias antes de comparar tiempos. Una compra en un entorno de pruebas sin carga aporta información funcional útil, pero no demuestra la capacidad de producción.

¿Cuándo debemos eliminar una copia de pruebas?

Consérvala solo mientras cumpla una finalidad de pruebas o soporte acordada. Cuando la retires, elimina la aplicación expuesta y los volcados obsoletos, revoca sus credenciales y elimina sus tareas y permisos de acceso. Gestiona las copias de recuperación conservadas según su política de retención independiente.