Pregunta 1De las tres etapas del despliegue, ¿cuál reúne app.js y los archivos necesarios en una forma que el servidor público pueda ejecutar?
Despliegue y variables de entorno — de funcionar en tu computadora a estar publicado
Este artículo forma parte del curso Fundamentos de informática, que construye desde cero los conocimientos prácticos de informática que necesitas como mínimo para programar y hacer vibe coding.
Cuando algo funciona en tu computadora pero deja de funcionar al publicarlo, la causa está fuera del código. Con diagramas comprobamos las tres etapas (build, colocación y publicación) y las variables de entorno que cambian los valores según el entorno.
Este artículo trata el despliegue, los pasos que llevan una aplicación que funciona en tu computadora hasta publicarla, y las variables de entorno que cambian los valores según el destino.
El mismo app.js se ejecuta en dos sitios: tu computadora y el servidor público.
Cuando algo funciona en tu computadora pero no en el servidor público, la causa está fuera del código.
La diferencia entre estos dos sitios es la razón de que deje de funcionar al publicarlo.
El despliegue tiene tres etapas: build, colocación y publicación
El despliegue es el trabajo de ponerlo en un servidor público para que cualquiera pueda usarlo, y por dentro son tres etapas: build, colocación y publicación.
La primera etapa es el build (build: reunir app.js y los archivos necesarios en una forma que el servidor público pueda ejecutar), y a los archivos que resultan se les llama archivos generados (build output).
Los archivos de configuración que solo usas en tu computadora se quedan fuera de los archivos generados y permanecen ahí.
Al servidor público solo llegan los archivos ya reunidos.
Volver a los archivos generados anteriores es un rollback.
La palabra deploy a veces se refiere solo a la colocación y a veces a las tres etapas.
También aparece CI/CD (Continuous Integration / Continuous Delivery: el mecanismo que ejecuta estas tres etapas de forma automática cada vez que registras el código), pero lo único nuevo es la automatización; las etapas son las mismas.
Despliegue es el nombre de tres trabajos juntos
Desplegar es hacer tres cosas seguidas: reunir, enviar y aceptar.
Reunir es el build, enviar y arrancar es la colocación, y aceptar las solicitudes de la URL es la publicación; los archivos de configuración que solo usas en tu computadora no entran en lo que se reúne, así que nunca llegan al servidor público.
Entorno de desarrollo y entorno de producción: el mismo código, pero distinto alrededor
Que un app.js que funcionaba en tu computadora no funcione en el servidor público no se debe a que el código haya cambiado.
Se debe a que el entorno (environment: el conjunto de computadora, sistema operativo, entorno de ejecución, base de datos y valores de configuración reunidos para ejecutar app.js) es distinto.
En el artículo «Qué es un entorno de desarrollo», el entorno de desarrollo es una combinación de herramientas; aquí es el sitio donde lo ejecutas con esas herramientas.
Dos entornos, un mismo app.js
- El app.js que ejecutas es el mismo archivo en los dos entornos
Entorno de desarrollo — tu computadora
- node que instalaste tú
- Una base de datos en la misma computadora
- Una configuración que muestra el detalle del error en pantalla
Entorno de producción — el servidor público
- node que está instalado en el servidor
- Una base de datos en otro servidor
- Una configuración que deja los errores fuera de la pantalla y los guarda en el log
Dentro del marco exterior hay dos entornos, y el app.js que ejecutan es el mismo archivo.
Lo único igual es el código: la URL que abres, el sitio de la base de datos y la clave de API son distintos.
| Supuesto que se cumplía en tu computadora | En el servidor público | Qué pasa al publicarlo |
|---|---|---|
| Se conecta a localhost:5432 | No hay ninguna base de datos con ese nombre | Error al guardar |
| La clave de API es de prueba | Las claves de prueba no se aceptan | El servicio externo lo rechaza |
| Muestra los errores en pantalla | Aparecen tal cual en la pantalla del usuario | La gente ve el detalle |
| El contenido de app.js | El mismo app.js | Funciona tal cual |
Las tres primeras filas son supuestos que solo se cumplían en tu computadora.
Cuando deja de funcionar al publicarlo, sospecha antes del alrededor que del código.
Si entras al servidor público y corriges a mano los archivos generados o la configuración, el siguiente despliegue los reemplaza y tus cambios desaparecen.
Lo que corriges es el app.js del entorno de desarrollo, y después vuelves a desplegar.
Lo único igual es el código
El entorno es todo lo que hay reunido alrededor de app.js para que pueda ejecutarse.
Tu computadora es el entorno de desarrollo y el servidor público es el entorno de producción, y aunque en los dos lados haya elementos con el mismo papel, el destino de conexión y las claves tienen valores distintos, así que cuando no funciona después de publicar, empieza por comprobar este alrededor.
Las variables de entorno cambian los valores de cada entorno sin tocar el código
El mecanismo que pone el valor fuera del código y hace que el código lea solo el nombre es la variable de entorno (environment variable: un valor que se configura fuera del programa y que se lee por su nombre al ejecutarlo).
En app.js escribes solo el nombre, y en tu computadora escribes el valor en .env (un archivo que enumera nombres y valores de variables de entorno).
Tu computadora (entorno de desarrollo)
La carpeta my-app
- app.js — escribes solo el nombre DATABASE_URL
- .env — escribes el valor, DATABASE_URL=localhost:5432
- .env se queda fuera de los archivos generados y fuera de Git
Servidor público (entorno de producción)
Carpeta generada
- app.js — llega con solo el nombre escrito
Configuración del destino
- Registras DATABASE_URL=db.example.com
- El app.js arrancado lee este valor por su nombre
Tu .env local solo se lee dentro de la computadora donde lo pusiste.
Como .env contiene claves de API, no se registra en Git, y tampoco está en los archivos generados, así que nunca llega al entorno de producción.
Cuando un manual dice «configura las variables de entorno de producción», se refiere a registrar los mismos nombres en el lado del servidor público.
| Dónde arrancó | De dónde sale el valor | Valor de DATABASE_URL | Resultado de la conexión |
|---|---|---|---|
| Tu computadora | Tu .env local | localhost:5432 | A la base de datos local |
| Servidor público, registrado | Configuración del destino | db.example.com | A la base de datos de producción |
| Servidor público, sin registrar | En ninguna parte | Se queda vacío | No se conecta y se para con un error |
Con el mismo app.js, el valor que lee cambia según dónde arrancó.
El valor se lee al arrancar, así que después de cambiar un valor hay que volver a arrancarlo.
Lo que se ejecuta en los recuadros de la izquierda y la derecha es el mismo app.js.
Lo único distinto son los valores puestos fuera de él.
El nombre en el código, el valor en el entorno
Una variable de entorno es un valor puesto fuera del código y llamado por su nombre.
En tu computadora lo escribes en un archivo llamado .env, y en el servidor público registras ese mismo nombre como una configuración de ese sitio, así que cuando no funciona después de publicar, lo primero que miras es si olvidaste ese registro.
La información secreta va solo en variables de entorno, nunca en el código fuente ni en los archivos generados
De los valores que pones en variables de entorno, los que piden más cuidado son la información secreta (secret: cadenas que, si alguien las conoce, le permiten hacerse pasar por ti), y los ejemplos principales son las claves de API y las contraseñas.
Las variables de entorno que lee el frontend tienen su valor escrito dentro de los archivos generados en el momento del build.
Ese valor escrito llega tal cual al dispositivo de quien abre la URL.
La información secreta va solo en variables de entorno de producción, que se quedan fuera de los archivos generados, y se registra en la pantalla de configuración del destino del despliegue.
El valor registrado no está en los archivos generados: el servidor público se lo pasa a app.js cuando lo arranca.
Si olvidas registrarlo, arranca con el nombre presente pero sin valor.
El valor registrado está solo en el lado del servidor público, y ese mismo valor no se copia ni a los archivos generados ni a tu .env local.
Después de publicar, el valor en sí está en un solo sitio.
Servidor público
Variables de entorno
- API_KEY contiene el valor de producción
- Solo pueden leerlo el app.js arrancado y quienes pueden operar el servidor
Carpeta generada
- En app.js solo está el nombre API_KEY
- El valor en sí no está escrito ahí
Equipo del usuario
- Solo llegan el HTML y el JavaScript de la pantalla
- No incluyen ningún valor secreto
El valor está solo en las variables de entorno de producción, no en los archivos generados ni en el dispositivo del usuario.
Cuánta gente puede leer cada sitio donde lo pones se trata en el artículo «Qué cuidar en seguridad».
Deja el valor en un solo sitio
La información secreta son cadenas que otras personas pueden usar si llegan a conocerlas.
Si las escribes en el código, el build las reúne y llegan hasta el dispositivo del usuario, así que en lugar de escribir el valor, regístralo como configuración del servidor público y escribe solo el nombre en el código.
QUIZ
Verificación de conocimientos
Responde cada pregunta una a una.
Pregunta 2my-app funcionaba en tu computadora, pero al publicarlo se paró con un error. ¿Cuál de estas causas, de las que da el artículo, es la correcta?
Pregunta 3¿Qué sitio para la información secreta, como las claves de API y las contraseñas de la base de datos, coincide con lo que explica el artículo?