Entornos, configuración y secretos

Tres entornos, un mismo código

El mismo código se ejecuta en varios entornos:

• dev (desarrollo): tu máquina, datos de juguete, todo verbose.
• staging (preproducción): copia fiel de producción para probar antes de publicar. Aquí se cazan los fallos que dev no ve.
• prod (producción): lo que usan las personas reales. Estabilidad y rendimiento por encima de todo.

Lo que cambia entre entornos no es el código: es la configuración (URL de la base de datos, claves de API, nivel de logs...).

Variables de entorno y 12-factor

La metodología 12-factor propone, entre otras cosas, separar la configuración del código y leerla del entorno. En Node eso es process.env:

const config = {
  puerto: process.env.PORT || 3000,
  baseDatos: process.env.DATABASE_URL,
  entorno: process.env.NODE_ENV || "development",
};

Así el mismo artefacto (la misma build) corre en dev, staging y prod solo cambiando las variables. Nunca metas valores de producción incrustados en el código.

Gestión de secretos

Las claves y contraseñas son secretos. Reglas de oro:

• Nunca en el repositorio (ni en .env versionado). Un secreto en Git es un secreto filtrado.
• En producción, usa un secret manager o vault (AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, o las "variables de entorno cifradas" de tu PaaS). La app pide el secreto en arranque; nunca queda escrito en disco.
• Rota los secretos periódicamente y da a cada servicio solo los que necesita.

# .env queda IGNORADO por Git; se versiona solo el ejemplo sin valores reales
echo ".env" >> .gitignore
git add .env.example   # documenta QUÉ variables hacen falta, no sus valores

Feature flags

Un feature flag es un interruptor que activa o desactiva una función sin volver a desplegar. Sirve para lanzar a un porcentaje de usuarios, hacer pruebas A/B o apagar algo que está fallando al instante.

if (featureActiva(flags, "nuevo-checkout", usuario)) {
  mostrarNuevoCheckout();
} else {
  mostrarCheckoutClasico();
}