Qué sale mal cuando prescindes del entorno de pruebas: tres historias reales

Los entornos de pruebas (staging) son uno de esos hábitos profesionales que parecen una carga hasta que te salvan. «Es solo un cambio pequeño», se piensa. «Edito el sitio en producción, actualizo y listo». La mayoría de las veces funciona. Las pocas veces que no, el coste se traduce en horas de recuperación, clientes perdidos o un sábado entero arreglando lo que debería haber sido una edición de un martes.

Tres situaciones reales de los últimos dos años en Defyn, anonimizadas pero ligeramente noveladas. En cada caso, un cambio de cinco minutos hecho en el sitio en producción costó entre medio día y una semana completa. En cada caso, un entorno de pruebas habría detectado el problema antes de que llegara a un cliente.

Historia 1: La actualización de plugin que se comió el pago

Un sitio de comercio electrónico con WooCommerce aplicó una actualización rutinaria de plugin un sábado por la tarde directamente en producción. Una pasarela de pago recibió una subida de versión menor. El propietario hizo clic en actualizar, el panel se puso verde y se fue a cenar.

Lo que no sabía era que la nueva versión había introducido un pequeño cambio en la forma de sanear el formato de los campos de tarjeta de crédito. El sitio funcionaba bien con la versión de PHP de la agencia. En la versión de PHP más antigua del alojamiento, la pasarela lanzaba un error silencioso en cada transacción. Los pagos empezaron a fallar de inmediato.

El domingo por la mañana, cuando el propietario lo comprobó, 31 clientes se habían topado con el pago roto y habían desistido. El plugin se revirtió en menos de una hora, pero esos 31 clientes nunca se recuperaron. Un entorno de pruebas con una sola transacción de prueba lo habría detectado antes de perder un solo pedido real.

Historia 2: El retoque de CSS que rompió el móvil

Un sitio de servicios B2B necesitaba un pequeño cambio visual. Un botón de la página de inicio debía ser un poco más grande y de un tono de rojo distinto. La responsable de marketing abrió el personalizador, hizo el cambio, guardó y lo dio por terminado.

El cambio rompió la maquetación móvil. El botón ahora desbordaba el contenedor en pantallas de menos de 400 píxeles de ancho, empujando el resto de la página hacia un lado y provocando que el menú de navegación se plegara de forma extraña. La responsable de marketing nunca abrió el sitio en un teléfono, así que no se dio cuenta.

La agencia lo detectó tres semanas después, durante una revisión trimestral. Para entonces, tres semanas de tráfico móvil (que era el 60 por ciento de la audiencia del sitio) habían visto una página de inicio rota. La tasa de rebote en móvil había subido en silencio un 18 por ciento durante ese periodo.

Historia 3: La actualización de tema que perdió la página de inicio

El tema de WordPress de un cliente tenía disponible una versión mayor. Las notas de la versión prometían mejoras de rendimiento y algunas funciones nuevas. El cliente aplicó la actualización un viernes por la tarde. El sitio se reconstruyó y toda la maquetación de la página de inicio desapareció. Fue reemplazada por una plantilla predeterminada que traía la nueva versión del tema.

La versión mayor había cambiado la forma en que el tema almacenaba los datos de maquetación, y el script de migración se ejecutó de forma imperfecta sobre la base de datos en producción. Recuperarlo exigió restaurar la versión anterior del tema, reimportar manualmente la maquetación de la página de inicio desde una copia de seguridad y volver a aplicar tres semanas de ediciones incrementales. Tiempo total de recuperación: 11 horas a lo largo de un fin de semana largo.

En una copia de pruebas, el fallo habría sido visible en 30 segundos. La agencia habría señalado esa versión del tema como arriesgada y habría recomendado otra vía de actualización. Cero tiempo de inactividad de cara al cliente, cero fin de semana perdido.

Qué es realmente un entorno de pruebas

Un entorno de pruebas es una copia privada del sitio en producción, alojada en una URL distinta, que replica la producción con la mayor fidelidad posible. La versión del tema coincide, las versiones de los plugins coinciden, el contenido es reciente y la base de datos está razonablemente actualizada. El equipo hace los cambios ahí, los prueba y solo los pasa a producción una vez confirmado que funcionan.

Los alojamientos WordPress gestionados modernos (Pantheon, WP Engine, Kinsta, SiteHost) incluyen entornos de pruebas con un solo clic. La mayoría de los buenos proveedores lo incluyen en sus planes. Configurarlo por primera vez en un alojamiento gestionado es cuestión de 10 minutos, tras lo cual queda ahí de forma indefinida como un seguro barato.

La parte de la disciplina

La configuración técnica es fácil. Lo más difícil es el hábito. «Es solo un cambio pequeño» debe desaparecer del vocabulario del equipo. Cada actualización de plugin, cada actualización de tema y cada cambio estructural de CSS pasa primero por el entorno de pruebas. Punto.

Las ediciones de contenido (cambios de texto, sustituir una imagen destacada, publicar una nueva entrada de blog) suelen poder saltarse el entorno de pruebas sin riesgo. Los cambios estructurales y de infraestructura, no.

Si tu sitio no tiene entorno de pruebas, o tiene uno que nadie usa de verdad, el equipo de desarrollo WordPress de Defyn puede montarlo y establecer un flujo de trabajo sensato. Cuando un equipo lleva tres meses con un proceso de pruebas que funciona, nadie vuelve a querer editar el sitio en producción directamente.