Staging: pruebas seguras
Módulo 8: Copias de seguridad, entorno de pruebas (staging) y actualizaciones de PHP · Tiempo de lectura: 9 minutos
Objetivo de aprendizaje: Después de esta lección podrá crear un entorno de pruebas (staging), protegerlo y restaurar cambios de forma segura en su sitio real.
Conceptos clave: staging, producción, clonación, subdominio, noindex, contraseña en la carpeta, correo desactivado, proveedor de pagos en modo de prueba, sincronizar, sobrescribir base de datos, entorno de desarrollo local
Qué es staging
Un entorno de pruebas (staging) (o sitio de prueba) es una copia de su sitio real, en una dirección propia, donde puede probar cambios. Su sitio real se denomina entonces producción. En staging puede permitirse que algo salga mal: un tema nuevo, una actualización importante, una actualización de PHP (lección 8.4), un nuevo plugin. Solo cuando funcione, lo aplica en producción.
Utilice staging para cambios con riesgo: versiones importantes de WordPress o de un plugin de tienda online, un tema distinto, una actualización de PHP, poner orden en los plugins (lección 5.4), un rediseño. Para un cambio de texto o una pequeña actualización de un plugin no es necesario.
Formas de crear un entorno de staging
| Forma | Cómo | Para quién |
|---|---|---|
| Función de clonación de su instalador | En Installatron "Copiar" con "Create a staging site", en Softaculous "Create Staging", en el WP Toolkit "Clone" | La forma más sencilla si su sitio se creó con un instalador |
| Staging de su proveedor de alojamiento | En alojamiento gestionado de WordPress suele ser un solo botón | Si su proveedor de alojamiento lo ofrece |
| Un plugin de staging | Un plugin crea una copia en una subcarpeta o en un subdominio | Si no dispone de instalador ni de función del proveedor de alojamiento |
| A mano | Restaurar una copia de seguridad junto al sitio (lección 8.2) y ajustar las direcciones | Instructivo, y siempre posible |
| Localmente en su propio ordenador | Un programa para desarrollo local de WordPress o un entorno Docker | Para desarrolladores y cambios más grandes |
Un entorno de staging en un subdominio (staging.example.com) suele ser mejor que en una subcarpeta (example.com/staging): se comporta más como su sitio real, y las cookies y las reglas en .htaccess no se mezclan. Cree primero el subdominio, con un certificado.
Protección: tres cosas que debe resolver de inmediato
Una copia de su sitio es un sitio completo con todo su contenido, y a veces con todos los datos de sus clientes. Por eso, resuelva de inmediato lo siguiente:
1. Fuera de los buscadores
Sin protección, Google puede encontrar e indexar su staging. Entonces tendrá contenido duplicado, y quienes busquen acabarán en su sitio de prueba. Haga al menos una, preferiblemente dos, de estas cosas:
- Una contraseña en todo el staging (autenticación básica a través de su panel de alojamiento, una "carpeta protegida"). Así nadie ve el sitio sin contraseña, tampoco los buscadores. Esta es la más eficaz.
- Desalentar a los buscadores en Ajustes > Lectura (lección 2.4). Esto coloca
noindexen cada página. Los buscadores suelen respetarlo, pero es una petición, no un cerrojo.
Tenga en cuenta lo contrario: si más adelante sincroniza el staging de vuelta a producción, no traslade la casilla de noindex. Un sitio de producción que desaparece de Google tras una sincronización "exitosa" es un clásico. El ejercicio de esta lección comprueba ambos casos.
2. Nada de correo a personas reales
Una copia de una tienda online o un sitio de miembros puede enviar correo: confirmaciones, recordatorios, boletines, enlaces de contraseña. Los clientes recibirían entonces correos confusos desde su sitio de prueba. Desactive el correo saliente en staging o rediríjalo a su propia dirección (con un plugin para interceptar el correo, o desactivando el plugin SMTP en staging, lección 9.1). Desactive también las tareas programadas que envían correo.
3. Pagos y conexiones en modo de prueba
Una tienda online en staging debe funcionar con el modo de prueba del proveedor de pagos, no con pagos reales. Otras conexiones (contabilidad, inventario, CRM) debe desactivarlas o conectarlas a un entorno de prueba, de lo contrario recibirán pedidos de prueba como si fueran reales.
Si trabaja con datos reales de clientes en staging, el RGPD se aplica igualmente allí (lección 9.3): no conservarlos más tiempo del necesario, y eliminar el staging cuando haya terminado.
Vuelta a producción: la trampa de la base de datos
El paso más difícil es restaurar sus cambios en producción. Los instaladores y los plugins de staging tienen una función para ello (en Installatron "Synch", en otros "Push to live"). El riesgo:
- Crea un staging el lunes. De martes a jueves prueba un tema nuevo.
- Mientras tanto, en producción se añaden veinte pedidos, tres entradas nuevas y cincuenta comentarios.
- El viernes sincroniza la base de datos de staging a producción. La base de datos de staging es la del lunes: los pedidos, entradas y comentarios de martes a viernes desaparecen.
Por eso:
- Haga primero una copia de seguridad de producción (lección 8.1), justo antes de sincronizar.
- Sincronice solo lo necesario. Actualizar un tema o un plugin es cuestión de archivos; la base de datos a menudo no necesita trasladarse. Muchas funciones de sincronización permiten elegir: solo archivos, o solo determinadas tablas.
- En una tienda online o un sitio con mucha actividad: aplique el cambio directamente en producción (los mismos pasos que en staging, ahora que sabe que funcionan) en lugar de trasladar la base de datos. O planifique un momento tranquilo con una breve interrupción de la tienda.
- Compruebe después producción: la lista de verificación de la lección 8.2, y la casilla de noindex.
Staging es un lugar para aprender qué ocurre. El cambio en sí es más seguro volver a aplicarlo directamente en producción.
Poner orden
Un staging que se mantiene durante meses se convierte en un sitio olvidado: sin actualizar, con plugins antiguos y datos reales. Exactamente el punto débil de la lección 7.1. Elimine el staging cuando haya terminado, o manténgalo como un sitio completo (actualizaciones, contraseña). Un clon también ocupa tanto espacio como el original y tiene su propia base de datos.
Resumen
- Staging es una copia de su sitio en una dirección propia para probar cambios con riesgo.
- Créelo con su instalador, su proveedor de alojamiento, un plugin o a mano, preferiblemente en un subdominio con certificado.
- Protéjalo de inmediato: contraseña y/o noindex, nada de correo a personas reales, pagos en modo de prueba.
- No sincronice ciegamente de vuelta: la base de datos de staging sobrescribe lo que se añadió en producción. Haga primero una copia de seguridad, sincronice solo lo necesario, o vuelva a aplicar el cambio.
- Elimine el staging cuando haya terminado, y no traslade la casilla de noindex a producción.
Cuestionario
Ejercicio
Ejercicio A8.3: ¿Está protegido su entorno de pruebas (staging)? Introduzca la dirección de su staging (un subdominio de su propio dominio, por ejemplo del ejercicio D8.2) y la de su sitio real. Demuestre con el código del ejercicio que el dominio es suyo. El programa comprueba en el staging: ¿responde mediante https, y está protegido (una solicitud de contraseña, o noindex en el HTML o en la cabecera X-Robots-Tag)? ¿La referencia REST (wp-json) apunta al propio staging y no a su sitio real? Y en su sitio real: ¿no hay ningún noindex?
Para saber más
Estos artículos describen los pasos en los paneles de WebOké; en otros paneles funcionan de forma similar.