Definición
Un entorno es una copia completa donde vive la aplicación: su código, su configuración, su base de datos y sus servicios. Lo habitual es tener al menos dos, y lo recomendable tres.
Local (desarrollo). En tu ordenador. Datos de mentira, todo se puede romper y no pasa nada.
Pruebas (staging o preproducción). Una copia lo más parecida posible a producción, donde se comprueba lo que se va a publicar. Datos de prueba o una copia anonimizada de los reales.
Producción. Donde están los clientes y los datos de verdad. Aquí no se experimenta.
La razón de separarlos es directa: necesitas un sitio donde equivocarte sin consecuencias. Si el único entorno es producción, cada cambio es una apuesta.
Qué cambia entre entornos
Lo que debe cambiar: las credenciales, la dirección de la base de datos, las claves de las APIs (modo de prueba frente a modo real), si se envían correos de verdad, y si se muestran los errores en pantalla.
Lo que no debería cambiar: el código. Idealmente es el mismo binario o los mismos ficheros, y solo cambia la configuración que se le pasa por variables de entorno.
Cuando el código tiene condiciones del tipo "si estamos en producción, haz esto otro", esas ramas no se prueban nunca hasta que ya estás en producción.
Ejemplo práctico
Tuve un fallo que enseña muy bien por qué las diferencias entre entornos son peligrosas, y no tenía nada que ver con el código.
En el panel de AEWorks, los presupuestos y los avisos aparecían con fecha del día anterior, pero solo entre las diez de la noche y medianoche. En mi máquina no pasaba nunca.
La causa: el servidor corre en horario UTC y yo estoy en Madrid. En verano vamos dos horas por delante, así que a las 22:05 aquí, para el servidor eran las 20:05 del mismo día... y a partir de las 00:00 de aquí, para el servidor seguía siendo el día anterior hasta las 02:00. Cualquier cosa fechada en ese rango salía con el día equivocado.
En local nunca ocurría porque mi ordenador está en horario de Madrid. Era una diferencia de entorno pura.
La solución fue fijar la zona horaria explícitamente en el arranque de la aplicación, en lugar de confiar en la del sistema. Y la lección más general: si algo depende del entorno, decláralo en el código en vez de heredarlo.
El segundo caso, más caro: probando una funcionalidad, un script escribió sobre el fichero de contenidos de producción y luego abortó. Durante unos minutos la web estuvo enseñando una oferta falsa de prueba. Lo restauré enseguida, y la lección quedó: a partir de ahí las pruebas usan una copia del fichero, nunca el original.
Errores comunes
- Probar en producción. Aunque sea "solo un momento". Es la vía rápida a un incidente.
- Datos reales en pruebas sin anonimizar. Nombres, teléfonos y correos de clientes en un entorno con menos protección es un problema de protección de datos.
- Preproducción que no se parece a producción. Otra versión del lenguaje, otro tipo de base de datos, otra configuración del servidor. Entonces no prueba nada: solo da una falsa sensación de seguridad.
- Credenciales de producción en local. El día que un script de prueba apunte donde no debe, ya sabes qué pasa.
- Enviar correos de verdad desde pruebas. Es la forma clásica de mandarle a un cliente real un correo de prueba.
- Una sola base de datos compartida entre entornos. Nunca. Es cuestión de tiempo que alguien la borre.
Cómo separarlos bien
- La configuración fuera del código, en variables de entorno.
- Un fichero de ejemplo en el repositorio con los nombres de las variables y sin sus valores, para que cualquiera sepa qué hace falta.
- Que se note dónde estás. Una banda de color en la interfaz que diga PRUEBAS evita muchos sustos.
- Las APIs externas en modo de prueba en todo lo que no sea producción. Stripe y casi todos los servicios serios lo ofrecen.
- Fija la zona horaria, el idioma y la codificación explícitamente. No dependas de lo que traiga el servidor.
Cuándo montarlos
Local y producción, desde el primer día de cualquier proyecto que alguien vaya a usar.
El de pruebas, en cuanto haya usuarios reales cuyo trabajo se estropee si publicas algo roto. Con un cliente ya compensa; con veinte es imprescindible.
