Herramientas

Una variable de entorno es un valor con nombre muy sencillo - una clave y un valor, como DATABASE_URL=postgres://localhost/app - que el sistema operativo pone a disposición de un programa en ejecución. Vive en el entorno del proceso en lugar de dentro de tu código fuente, de modo que el programa puede leerla en tiempo de ejecución sin que el valor se escriba nunca en el propio código. Cada proceso arranca con un conjunto de estas variables, heredadas de aquello que lo lanzó.

¿Por qué no codificarlo de forma fija?

El sentido de guardar un valor en el entorno en vez de codificarlo de forma fija es la separación: el mismo código puede comportarse de forma distinta según dónde se ejecute, y los valores sensibles nunca tienen que estar en los archivos que confirmas. Un programa le pide un ajuste al entorno cuando lo necesita, y el entorno entrega lo que se haya configurado para esa máquina, contenedor o despliegue en concreto.

Configuración que cambia según el entorno

El uso más común es la configuración que cambia según el entorno. Tu aplicación podría hablar con una base de datos local en desarrollo y con una gestionada en producción, o ejecutarse en modo depuración en tu portátil pero no en el servidor. En lugar de editar el código para cada sitio, lees una variable - DATABASE_URL, PORT, LOG_LEVEL - y le das un valor distinto en cada entorno. El código sigue siendo idéntico; solo cambia el entorno.

• Un par clave=valor que el SO da a un proceso
• Configuración que cambia según el entorno (dev/prod)
• Secretos y claves de API, fuera del código
• Definir con export VAR=valor; leer con process.env / os.environ
• Mantén .env en .gitignore - nunca confirmes secretos

Secretos y claves de API

El segundo uso común son los secretos: claves de API, contraseñas de bases de datos, tokens y otras credenciales que nunca deben acabar en el control de versiones. Como las variables de entorno viven fuera del árbol de fuentes, son una forma estándar de alimentar esos valores a un programa sin confirmarlos. El código lee API_KEY desde el entorno; la clave real solo existe en la máquina que lo ejecuta, nunca en el repositorio.

Variables que ya usas

Ya te has encontrado con variables de entorno aunque no hayas definido ninguna. PATH le indica al shell en qué directorios buscar los comandos, HOME apunta a tu directorio personal, y variables como LANG o TZ describen tu idioma y tu zona horaria. Las define el sistema operativo y el shell en cada sesión, y los programas se apoyan en ellas discretamente todo el tiempo.

Definirlas y leerlas

Definirlas y leerlas es sencillo. En un shell tipo Unix escribes export VAR=valor para definir una en la sesión actual, y la vuelves a leer como $VAR; en Windows la sintaxis difiere pero la idea es la misma. En el código, llegas al entorno a través de tu lenguaje: process.env.VAR en Node.js, os.environ["VAR"] en Python, y llamadas equivalentes en la mayoría de los demás lenguajes. El programa recibe una simple cadena de texto, que luego puede usar como necesite.

Escribir los exports a mano se vuelve tedioso enseguida, así que los proyectos suelen guardar sus variables en un archivo - a menudo llamado .env - con una CLAVE=valor por línea. Una pequeña biblioteca carga ese archivo en el entorno cuando arranca el programa: dotenv es la opción muy extendida en el mundo Node.js, y herramientas como direnv pueden cargar y descargar variables automáticamente al moverte entre directorios de proyecto. Esto mantiene los ajustes de un proyecto juntos en un solo sitio.

Nunca confirmes tus secretos

Esa comodidad viene con la regla más importante: nunca confirmes tus secretos. Un archivo .env que contenga claves reales debe figurar en .gitignore para que quede fuera del control de versiones, y los equipos suelen versionar un .env.example con los nombres de las variables pero con valores vacíos o de ejemplo. La metodología twelve-factor app, una guía muy citada para construir servicios, hace del almacenamiento de la configuración en el entorno uno de sus principios fundamentales, precisamente por esta razón.

Trampas que vigilar

Conviene conocer algunas trampas. Las variables de entorno son cadenas de texto, así que un valor como "false" o "0" sigue siendo una cadena no vacía y puede confundir las comprobaciones de veracidad. Su alcance es el proceso y lo que este lance, de modo que una variable definida en un shell no aparecerá en otro. Y como a menudo llevan secretos, ten cuidado de no imprimir todo el entorno en los registros o en la salida de errores, donde una clave podría filtrarse. Trátalas como simple configuración, mantén los secretos fuera de tu repositorio, y las variables de entorno se convierten en una de las herramientas más sencillas y fiables de la caja del desarrollador.