Los entornos de pruebas (staging) son uno de esos h\u00e1bitos profesionales que parecen una carga hasta que te salvan. \u00abEs solo un cambio peque\u00f1o\u00bb, se piensa. \u00abEdito el sitio en producci\u00f3n, actualizo y listo\u00bb. La mayor\u00eda de las veces funciona. Las pocas veces que no, el coste se traduce en horas de recuperaci\u00f3n, clientes perdidos o un s\u00e1bado entero arreglando lo que deber\u00eda haber sido una edici\u00f3n de un martes.<\/p>\n\n\n\n
Tres situaciones reales de los \u00faltimos dos a\u00f1os en Defyn, anonimizadas pero ligeramente noveladas. En cada caso, un cambio de cinco minutos hecho en el sitio en producci\u00f3n cost\u00f3 entre medio d\u00eda y una semana completa. En cada caso, un entorno de pruebas habr\u00eda detectado el problema antes de que llegara a un cliente.<\/p>\n\n\n\n
Un sitio de comercio electr\u00f3nico con WooCommerce aplic\u00f3 una actualizaci\u00f3n rutinaria de plugin un s\u00e1bado por la tarde directamente en producci\u00f3n. Una pasarela de pago recibi\u00f3 una subida de versi\u00f3n menor. El propietario hizo clic en actualizar, el panel se puso verde y se fue a cenar.<\/p>\n\n\n\n
Lo que no sab\u00eda era que la nueva versi\u00f3n hab\u00eda introducido un peque\u00f1o cambio en la forma de sanear el formato de los campos de tarjeta de cr\u00e9dito. El sitio funcionaba bien con la versi\u00f3n de PHP de la agencia. En la versi\u00f3n de PHP m\u00e1s antigua del alojamiento, la pasarela lanzaba un error silencioso en cada transacci\u00f3n. Los pagos empezaron a fallar de inmediato.<\/p>\n\n\n\n
El domingo por la ma\u00f1ana, cuando el propietario lo comprob\u00f3, 31 clientes se hab\u00edan topado con el pago roto y hab\u00edan desistido. El plugin se revirti\u00f3 en menos de una hora, pero esos 31 clientes nunca se recuperaron. Un entorno de pruebas con una sola transacci\u00f3n de prueba lo habr\u00eda detectado antes de perder un solo pedido real.<\/p>\n\n\n\n
Un sitio de servicios B2B necesitaba un peque\u00f1o cambio visual. Un bot\u00f3n de la p\u00e1gina de inicio deb\u00eda ser un poco m\u00e1s grande y de un tono de rojo distinto. La responsable de marketing abri\u00f3 el personalizador, hizo el cambio, guard\u00f3 y lo dio por terminado.<\/p>\n\n\n\n
El cambio rompi\u00f3 la maquetaci\u00f3n m\u00f3vil. El bot\u00f3n ahora desbordaba el contenedor en pantallas de menos de 400 p\u00edxeles de ancho, empujando el resto de la p\u00e1gina hacia un lado y provocando que el men\u00fa de navegaci\u00f3n se plegara de forma extra\u00f1a. La responsable de marketing nunca abri\u00f3 el sitio en un tel\u00e9fono, as\u00ed que no se dio cuenta.<\/p>\n\n\n\n
La agencia lo detect\u00f3 tres semanas despu\u00e9s, durante una revisi\u00f3n trimestral. Para entonces, tres semanas de tr\u00e1fico m\u00f3vil (que era el 60 por ciento de la audiencia del sitio) hab\u00edan visto una p\u00e1gina de inicio rota. La tasa de rebote en m\u00f3vil hab\u00eda subido en silencio un 18 por ciento durante ese periodo.<\/p>\n\n\n\n
El tema de WordPress de un cliente ten\u00eda disponible una versi\u00f3n mayor. Las notas de la versi\u00f3n promet\u00edan mejoras de rendimiento y algunas funciones nuevas. El cliente aplic\u00f3 la actualizaci\u00f3n un viernes por la tarde. El sitio se reconstruy\u00f3 y toda la maquetaci\u00f3n de la p\u00e1gina de inicio desapareci\u00f3. Fue reemplazada por una plantilla predeterminada que tra\u00eda la nueva versi\u00f3n del tema.<\/p>\n\n\n\n
La versi\u00f3n mayor hab\u00eda cambiado la forma en que el tema almacenaba los datos de maquetaci\u00f3n, y el script de migraci\u00f3n se ejecut\u00f3 de forma imperfecta sobre la base de datos en producci\u00f3n. Recuperarlo exigi\u00f3 restaurar la versi\u00f3n anterior del tema, reimportar manualmente la maquetaci\u00f3n de la p\u00e1gina de inicio desde una copia de seguridad y volver a aplicar tres semanas de ediciones incrementales. Tiempo total de recuperaci\u00f3n: 11 horas a lo largo de un fin de semana largo.<\/p>\n\n\n\n
En una copia de pruebas, el fallo habr\u00eda sido visible en 30 segundos. La agencia habr\u00eda se\u00f1alado esa versi\u00f3n del tema como arriesgada y habr\u00eda recomendado otra v\u00eda de actualizaci\u00f3n. Cero tiempo de inactividad de cara al cliente, cero fin de semana perdido.<\/p>\n\n\n\n
Un entorno de pruebas es una copia privada del sitio en producci\u00f3n, alojada en una URL distinta, que replica la producci\u00f3n con la mayor fidelidad posible. La versi\u00f3n del tema coincide, las versiones de los plugins coinciden, el contenido es reciente y la base de datos est\u00e1 razonablemente actualizada. El equipo hace los cambios ah\u00ed, los prueba y solo los pasa a producci\u00f3n una vez confirmado que funcionan.<\/p>\n\n\n\n
Los alojamientos WordPress gestionados modernos (Pantheon, WP Engine, Kinsta, SiteHost) incluyen entornos de pruebas con un solo clic. La mayor\u00eda de los buenos proveedores lo incluyen en sus planes. Configurarlo por primera vez en un alojamiento gestionado es cuesti\u00f3n de 10 minutos, tras lo cual queda ah\u00ed de forma indefinida como un seguro barato.<\/p>\n\n\n\n
La configuraci\u00f3n t\u00e9cnica es f\u00e1cil. Lo m\u00e1s dif\u00edcil es el h\u00e1bito. \u00abEs solo un cambio peque\u00f1o\u00bb debe desaparecer del vocabulario del equipo. Cada actualizaci\u00f3n de plugin, cada actualizaci\u00f3n de tema y cada cambio estructural de CSS pasa primero por el entorno de pruebas. Punto.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n