¿Qué es un entorno de staging? La copia que nunca llega a ser una copia

Un entorno de staging es una copia en funcionamiento de tu aplicación, tan cercana a producción como te puedas permitir, donde se revisa una versión antes de que la vean personas reales. El mismo código, la misma forma de configuración, la misma estructura de base de datos, otros datos y otro público.

La idea es antigua y sencilla: pruébalo primero donde no importe. Lo interesante es que staging nunca es realmente una copia, y todos los problemas que se le escapan salen de esa distancia.

Entre qué se sitúa

La mayoría de los equipos acaban con tres o cuatro entornos, y las diferencias tienen que ver con quién tiene permiso para romperlos.

• Local es la máquina de quien desarrolla. Se rompe constantemente, y a nadie le importa.
• Staging ejecuta el código que está a punto de salir, con datos que nadie echará de menos. Se rompe de vez en cuando, y a alguien le importa un poco.
• Producción es donde están los clientes.

Algunos equipos añaden un cuarto entre staging y producción para pruebas de carga o de integración, y otros ponen un entorno de vista previa por rama antes de staging. Los nombres varían más que las ideas.

Para qué sirve

Cazar lo que una suite de pruebas no puede. Migraciones contra una base de datos con volumen real. Assets que solo se compilan durante un despliegue. Un valor de configuración que existe en una máquina y no en otra. Nada de eso lo toca una prueba unitaria.

Ensayar el propio despliegue. Una versión es un procedimiento, y el procedimiento también tiene errores. Si desplegar a staging es el mismo comando que desplegar a producción, has practicado aquello que si no se haría por primera vez en el peor momento.

Dar a quien no programa un sitio donde mirar. Las pruebas de aceptación, una demostración, una captura para soporte - todas necesitan algo real que no sea real.

Cómo se desvía staging

Esta es la parte que conviene apuntar, porque un entorno de staging que nadie mantiene es peor que ninguno: produce confianza en lugar de información.

El código se desvía. Todo lo que se fusiona va a staging automáticamente; producción se despliega cuando alguien lo decide. Un staging treinta commits por delante de producción te habla de un software que tus clientes no tienen, y el fallo que no consigues reproducir en staging puede que allí ya esté corregido.

Los datos se desvían. Producción acumula quince años de decisiones - cuentas sin dirección de correo, un pedido de antes de que existiera una columna, un nombre con un apóstrofo. Staging tiene lo que los seeds pusieron ahí. La mayoría de los defectos que llegan a los clientes viven en formas de datos que a nadie se le ocurrió crear.

La configuración se desvía. Una clave puesta en un host y no en el otro, un feature flag activado en un sitio, un servicio de terceros apuntando a un sandbox que se comporta distinto del real. Esta es la clase de problema para la que existe staging y la clase que más a menudo provoca.

La escala se desvía. Un proceso web contra doce, una base de datos con mil filas contra diez millones. Una consulta que es instantánea en staging puede ser la razón por la que producción se cae.

Mantener la distancia honesta

No puedes cerrar la distancia, así que el objetivo es saber dónde está.

• Despliega igual en los dos. Un comando, un script, ningún paso manual que exista solo en un sitio. Si producción tiene un paso que staging no tiene, ese paso nunca se ha probado.
• Despliégalos juntos cuando un cambio afecta a los dos. Cualquier cosa con un cliente - una extensión de navegador, una app móvil, una integración con un socio - que hable con un entorno y no con el otro no está viva en ninguno, en lo que respecta a quien la prueba.
• Usa datos con forma de producción, no datos de producción. Anonimizados o generados, con las formas incómodas incluidas a propósito: la cuenta vacía, la lista enorme, el apóstrofo. Copiar datos reales de clientes a un entorno menos protegido es un incidente de privacidad esperando fecha.
• Mantenlo parado cuando no haga falta, y da por hecho que es un objetivo: los entornos de staging son célebres por estar menos parcheados y más abiertos que los sistemas que reflejan.
• Di cuál es cuál. Un banner, un color, lo que sea. Alguien acabará haciendo una demostración en producción o una prueba destructiva en el host equivocado, y evitarlo cuesta una línea de CSS.

Cuando staging dice una cosa y producción dice otra

Eso no es un fallo de staging, es la información para la que staging existe, y es el momento de averiguar cuál de las cuatro desviaciones de arriba lo explica.

La primera pregunta es qué build está ejecutando cada uno. La segunda es si pasa lo mismo con los mismos datos. Las dos son cosas que un informe debería decir, y las dos son los detalles que suelen faltar en “en staging funciona”.

Una captura de cada entorno convierte una discusión en una comparación: los mismos pasos, dos conjuntos de salida de consola y de registros de red, y normalmente una diferencia evidente. La guía del informe de error tiene el resto de lo que hay que incluir, y nombrar el entorno es la línea que la gente olvida.

La versión corta

Staging es un ensayo, no una copia. Su valor es proporcional a con cuánta honestidad sigas la pista de las formas en que se diferencia de producción - código, datos, configuración y escala - y una diferencia que conoces es una limitación, mientras que una que has olvidado es un falso negativo con una marca verde puesta.