04. III. Configuraciones

Guarda la configuración en el entorno.

¿Qué es “configuración”?

Configuración es todo lo que varía entre despliegues (desarrollo, staging, producción): credenciales de base de datos, tokens de servicios externos (Amazon S3, Twitter, Stripe), nombres de host, feature flags específicos de entorno.

No es configuración: rutas internas de la app, nombres de constantes de negocio, o cualquier cosa que sea igual en todos los despliegues — eso es código y va en el repositorio.

El anti-patrón: config en el código

Es común encontrar credenciales guardadas como constantes en el código fuente, o en archivos de configuración versionados junto al repo (config/database.yml, application.properties). Esto viola la separación estricta entre configuración y código que exige la metodología.

El test del open source

Existe una prueba directa para saber si tu configuración está bien separada:

¿Podrías publicar el código fuente de tu aplicación como open source ahora mismo, sin exponer ninguna credencial?

Si la respuesta es “no, primero tendría que sacar las claves de tal archivo”, tu configuración vive en el lugar equivocado.

Por qué no usar archivos de configuración versionados

Los archivos de config no versionados (.gitignored) también tienen problemas:

• Riesgo real de terminar committeados por accidente (git add -A un mal día).
• Se fragmentan en múltiples formatos y ubicaciones según el lenguaje/framework.
• Es difícil auditar “toda la configuración” de un vistazo, porque está dispersa.

La solución: variables de entorno

Una aplicación twelve-factor almacena su configuración en variables de entorno (env vars):

DATABASE_URL=postgres://user:pass@host:5432/dbname
STRIPE_SECRET_KEY=sk_live_xxxxx
S3_BUCKET=mi-app-uploads

Ventajas frente a archivos de config:

• Se modifican sin tocar ni recompilar código.
• Son un mecanismo estándar, independiente del sistema operativo y del lenguaje.
• Son granulares y ortogonales: cada variable se gestiona de forma independiente, sin agrupar en “entornos” predefinidos que combinan mal (ej. no hace falta un entorno llamado “staging-cliente-A” distinto de “staging-cliente-B” sólo porque cambia una URL).

Un error común: agrupar en “entornos” con nombre

El manifiesto advierte contra crear un archivo config/environments/staging.rb por cada combinación posible de valores. Esto no escala: cada nuevo despliegue (una demo para un cliente, un entorno de QA extra) obliga a crear un nuevo “entorno” nombrado. Las variables de entorno, al ser independientes entre sí, evitan esa explosión combinatoria.

Checklist del factor III

• Ninguna credencial, token o secreto está en el código fuente ni en archivos versionados.
• El código pasa el “test del open source”: se podría publicar sin exponer nada sensible.
• Toda la configuración que varía entre desarrollo/staging/producción vive en variables de entorno.
• No existen archivos environments/<nombre>.ext que agrupen configuración por combinaciones ad-hoc.

Ya separamos código (I), dependencias (II) y configuración (III). El siguiente factor trata los recursos externos que la app consume: los backing services.