Qué significa staging en Shopify
En un proyecto Shopify, staging es un entorno controlado donde se puede revisar un cambio antes de publicarlo. Para un theme, normalmente se materializa como un theme de desarrollo o no publicado conectado a una rama. Para apps e integraciones, puede requerir una development store, credenciales separadas y datos de prueba.
No existe un botón universal que duplique toda la tienda con pedidos, configuración y sistemas externos. Por eso el diseño del entorno debe empezar por la pregunta: ¿qué riesgo queremos probar?
Si el equipo publica cambios de forma continua, este proceso debe formar parte del soporte y mantenimiento Shopify, no depender de recordar una checklist cada vez.
Entornos mínimos para un theme
| Entorno | Uso | Regla principal |
|---|---|---|
| Local/desarrollo | Construir y comprobar rápido | Nunca contiene secretos en el repositorio |
| Preview | Revisión funcional y visual compartida | No se utiliza como theme publicado |
| Producción | Tienda que recibe tráfico real | Solo recibe cambios aprobados |
Shopify CLI puede crear themes de desarrollo temporales y generar previews. Un theme no publicado es más estable para una validación que necesita durar varios días o ser compartida con distintos equipos.
Flujo de una release de theme
- Crear una rama con un alcance pequeño y un resultado verificable.
- Implementar el cambio sin mezclar correcciones no relacionadas.
- Ejecutar Theme Check y las pruebas del proyecto.
- Subirlo a un theme de preview.
- Revisar las plantillas afectadas en móvil y escritorio.
- Validar compra, apps e integraciones cuando el cambio las toca.
- Registrar la aprobación.
- Integrar el cambio en la rama de producción.
- Publicar el theme correspondiente.
- Comprobar la tienda real y mantener preparada la reversión.
La integración de Shopify con GitHub puede vincular ramas a themes publicados o no publicados. Hay que acordar si se permiten ediciones desde el administrador, porque esas modificaciones pueden generar commits y cambiar el estado esperado de la rama.
Qué debe entrar en el QA
No revises toda la tienda de la misma manera para cada cambio. Define una matriz por riesgo.
Un ajuste de estilos en una sección necesita comprobar la sección, sus variantes y los breakpoints. Un cambio en selector de variantes necesita producto, disponibilidad, precio, media, carrito y eventos. Un cambio global de scripts exige además rendimiento, consentimiento y posibles conflictos con apps.
La prueba de humo habitual incluye:
- home, colección, producto y búsqueda;
- navegación, menú y footer;
- variante, cantidad y añadir al carrito;
- carrito, descuento y checkout;
- customer account si cambia;
- mercados e idiomas afectados;
- eventos de analítica relevantes;
- accesibilidad de teclado en el componente modificado.
Publicar y volver atrás
Rollback no significa “deshacer algunos archivos a mano”. Debe existir un theme anterior conocido, una versión etiquetada o un commit que pueda volver a publicarse.
Antes de la release, registra el theme publicado, el nuevo theme, el commit, la hora prevista y la persona que toma la decisión. Después, comprueba el flujo crítico y observa errores. Si aparece una regresión, decide entre corregir hacia delante o volver a la versión previa; no improvises una mezcla en producción.
Los datos creados después del despliegue requieren un plan distinto. Volver al theme anterior no revierte pedidos, cambios de catálogo ni escrituras de una app.
Cambios urgentes sin romper el proceso
Un hotfix puede recorrer una ruta abreviada, pero no invisible:
- reproducir el problema;
- aislar la corrección mínima;
- probarla en preview;
- aprobar y publicar;
- verificar producción;
- integrar el mismo cambio en la rama principal;
- documentar la causa.
Si el cambio urgente solo se hace en el editor de Shopify, la siguiente publicación puede borrarlo. El cierre del hotfix incluye reconciliar repositorio y theme real.
Apps e integraciones necesitan otro staging
Un preview de theme no aísla webhooks, pagos, ERP o WMS. Para esos componentes define:
- tienda y credenciales de prueba;
- endpoints separados;
- productos, pedidos y clientes ficticios;
- forma de impedir envíos o cobros reales;
- registros y alertas;
- limpieza o caducidad de datos de prueba.
La arquitectura de integraciones Shopify debe dejar claro qué sistemas aceptan pruebas y cuáles solo ofrecen un entorno productivo controlado.
Señales de que el proceso necesita mejorar
- nadie sabe qué código corresponde al theme publicado;
- existen muchas copias con nombres ambiguos;
- se editan archivos en producción durante una campaña;
- la aprobación llega por distintos canales y no queda registrada;
- el QA empieza después de publicar;
- volver atrás depende de una persona concreta;
- un hotfix reaparece porque nunca llegó a la rama principal.
Corregir el proceso no requiere empezar con una plataforma compleja. Una rama, un preview, una checklist breve y una versión recuperable ya eliminan una parte importante del riesgo.
Preguntas frecuentes
¿Se puede tener un staging idéntico a producción en Shopify?
No siempre. El theme puede previsualizarse con datos de la tienda, pero pagos, apps, Markets e integraciones pueden comportarse de otra manera. El entorno debe documentar esas diferencias.
¿Duplicar el theme es suficiente para controlar versiones?
Sirve como copia rápida, pero no reemplaza Git. Una duplicación no explica cambios, autores, revisiones ni permite comparar versiones con la misma precisión.
¿Conviene automatizar la publicación del theme?
Puede ser útil cuando existen pruebas y protecciones maduras. Si la revisión todavía es manual, automatizar el despliegue sin automatizar controles solo acelera la llegada del error.
Fuentes oficiales revisadas
Referencias usadas para contrastar recomendaciones técnicas, documentación de plataforma y criterios de búsqueda.
