Configuración por entorno

Qué cambia y qué no

Las tres últimas filas son las importantes: lo que cambia por entorno debe ser configuración, no comportamiento. En cuanto la lógica difiere, lo que pruebas deja de ser lo que publicas.

Cómo se cambia

Tres mecanismos, con usos distintos:

Y una que conviene evitar: leer el entorno en tiempo de ejecución para decidir a qué servidor apuntar. Suena flexible y significa que un binario de producción puede apuntar a otro sitio si alguien pone una variable — que es una superficie que no querías.

Evitar publicar mal

El fallo caro de este nivel: publicar una versión que apunta al servidor de pruebas, o con las herramientas de desarrollo abiertas, o con el registro detallado.

Tres defensas, y las tres son baratas:

• Que la configuración de producción sea la que se usa por omisión, y las otras haya que pedirlas. Así, olvidarse produce lo correcto.
• Una comprobación en la construcción que falle si la dirección del servidor no es la de producción. Es la puerta de publicación del nivel 46.4.
• Y que la propia aplicación lo muestre: si no apunta a producción, que se vea en la interfaz — una franja, un texto en el título. Es imposible publicar por error algo que dice «PRUEBAS» en la ventana.

La tercera es la más efectiva y la que menos se usa.

Y lo que no debe estar en la configuración

Un recordatorio de la fase VI: nada secreto. Ni claves, ni credenciales, ni testigos.

La dirección de un servidor no es un secreto. Una clave de API sí, y el nivel 34.4 explicó por qué no puede vivir en un binario que repartes, con configuración por entorno o sin ella.