Gestión de Ambientes en Angular: Desarrollo vs Producción
Resumen
Los desarrolladores o desarrolladoras del Core de Angular ya pensaron en todos los problemas típicos que ocurren cuando programas en front-end. Uno de ellos es la posibilidad de diferenciar entre ambientes de un mismo proyecto.
Ambientes de Desarrollo y Producción
En tu proyecto de Angular encontrarás una carpeta llamada environments y por defecto con dos archivos dentro:
environments.ts
environments.prod.ts
Ambos lucen de manera muy similar.
// environments.ts// This file can be replaced during build by using the `fileReplacements` array.// `ng build` replaces `environment.ts` with `environment.prod.ts`.// The list of file replacements can be found in `angular.json`.exportconst environment ={production:false};
Presta atención a los comentarios en el archivo environments.ts, pues explican como Angular, cuando compila la aplicación, se reemplaza por el correspondiente dependiendo del ambiente.
Busca en el archivo angular.json la propiedad fileReplacements:
Es equivalente a hacer un ng serve --configuration development.
Mientras que cuando haces un ng serve --configuration production se compila en modo producción y utilizará las variables de entorno que le corresponda.
De esta manera puedes manejar N cantidad de ambientes, cada uno con sus propias variables de entorno y su propia configuración dependiendo la necesidad.
Si, como yo, vienes del futuro donde existe Angular 15 y superiores, debes saber que el equipo de Angular ha hecho una labor de minimizar los archivos necesarios para crear una aplicación, por lo que varios archivos han desaparecido. Debido a esto, es posible que no encuentres el directorio environments que utiliza Nico en esta clase. Pero no te preocupes, aún puedes usarlo.
Para usar los ambientes lo que tendrás que hacer es agregarlos manualmente, lo que es bastante sencillo, te muestro cómo.
Creando tus ambientes
Primero necesitas ubicarte en el directorio src de tu aplicación.
Estando en src vas a crear un directorio nuevo llamado environments.
En este nuevo directorio, vas a crear tus ambientes. Inicialmente se utilizan dos: desarrollo y producción. Como el de desarrollo es el ambiente por defecto, puedes nombrarlo environment.ts. Por su parte, al ambiente de producción lo llamarás environment.prod.ts.
Puedes crear más ambientes si lo necesitas, por ejemplo, puedes tener un ambiente staging y lo nombrarías environment.staging.ts.
Una vez creados, lo importante es la configuración que les des. La configuración más básica es tal que así:
exportconst environment ={ production:false};
Esta te puede servir para tu ambiente de desarrollo (environment.ts). Para tener un ambiente de producción (environment.prod.ts), solo hace falta cambiar la propiedad production a true. Así:
exportconst environment ={ production:true};
A partir de aquí puedes agregar todas las configuración y variables que gustes, tal como muestra Nico.
Por último, es importante notar que para que Angular sepa que quieres hacer un build con una determinada configuración, se lo debes indicar. Por ejemplo, para hacer un build para producción usaríamos:
ng build --prod
Y eso es todo, espero que les sirva este pequeño aporte 😁.
Vengo de Angular 14 lo actualice al 15 y cuando creer mis proyectos sentía que algo me hacía falta, pero no me había dado cuenta. Te has pasado con este aporte, muchas gracias <3
PREGUNTA, si creo un ambiente staging, crearia el archivo y al hacer el build lo corro con ng build --staging? gracias de antemano por tu respuesta, me serviria mucho
Recuerda que un PROXY creado en angular no corre en PRODUCCION solo en el ambiente de desarrollo
todo es cuestión de gustos.. pero angular me gusta más que react
Leí el documento y está haciendo al revés de lo que hizo Nicolas Molina, estoy confundido, Nicolas mencionó que "debería funcionar el ng serve" (minuto 4:10) pero no funciona, y si hago lo que dice el link que enviaste, sí estaría funcionando.
Para que Angular sepa que estas en un ambiente de producción, debes compilar el proyecto con el comando:
ng build --prod
Si solo utilizas ng build, las variables de entorno no serán tomadas en cuenta.
gracias
Me ha gustado la forma en que Angular ha pensado en todas estas soluciones a problemas comunes de desarrollo.
al poner ng serve no me toma las variables de entorno ni la del proxi, me deja el link de la api vacío alguien sabe por qué ?
A mi me pasa igual. Ayuda :c
¿Han podido solucionar el problema?
Estuve leyendo la documentación y encontré esto:
Configurar ambientes
Puse el mismo url en mi ambiente de desarrollo, no sé si será una solución válida, pero la tengo como temporal.
con ng generate environments se crea la carpeta environments con los archivos necesarios para los ambientes, solo tocaría poner production: true o production: false según se necesite y renombrar los archivos también si se quiere
https://angular.io/guide/build
Gracias por actualizarnos.
Para Angular 15, el ambiente por defecto se cambió a producción, lo que significa que el build se genera directamente para productivo, por lo que se deben realizar alguna configuración adicionales para que se tomen los respectivos archivos environment para cada ambiente.
Por defecto el archivo de producción se llamaría environment.ts, mientras que el de desarrollo podría llamarse environment.dev.ts, lo importante viene cuando se realiza la configuración en el archivo angular.json donde se especifica, para cada ambiente, como se comporta el reemplazo de los respectivos archivos.
Por ejemplo, para el ambiente de desarrollo quedaría de la siguiente manera:
Mientras que para la configuración de productivo no hay necesidad de configurar nada adicional, ya que su archivo environment.ts se toma por defecto.
Adjunto un artículo que amplía la información relacionada Angular 15: what happened to environment.ts
También adjunto otro artículo donde se ejemplifica una forma de manejar los datos que varían entre ambientes al momento de ejecución y no de compilación, como se hace con lo environments nativos de Angular: Runtime environment configuration with Angular
Nota importanteEstas variables no serán tomadas en cuenta si solo haces un ng build; debes hacer un ng build --prod para crear un “build de producción”
Muchoénfasis en que solo funciona en desarrollo ya que nosotros desplegando nuestras apps no entendiamos porque no funcionaban jaja, hasta que vimos que era un problema de API Gateway de AWS
En las reglas del proxy para hacer peticiones a una API con restricciones de Cors si quiero trabajar desde local con el proxy solo debería colocar target: http//localhost y el puerto en el que trabajaré
¿?. Agradezco la respuesta compañeros :D
Claro, si no me equivoco bastaria con ponener el dominio y puerto de tu api local en target en el proxy.config.json para que tu fronte simule hacerle la peticion desde el mismo dominio que tu back
Muy buena clase.
Sí, muy importante esta clase de 'Manejo de ambientes'.
TRabajo con una plicacion de angular y tengo un problema especificamente con los repositorios de github.
tenemos 3 ambientes: desarrollo, release y produccion, pero cada uno tiene diferentes variables de entorno cuando cambio una variable de entorno en release, no quiero que estos cambios vallan a la rama de producción, por ovias razones pero al hacer pero cuando hago el merge de las dos ramas paso los cambios de release a produccion incluidos las variables de entono, como puedo hacer para ignorar esto especificamente?
ACLARO QUE DESARROLLO PRODUCCION Y RELEASE SON AMBIENTES DE "PRODUCCION"
Angular 15 eliminó la carpeta environments y quise crearla manualmente, pero no ejecuta el comando ng build --prod ni me construye el proyecto con esa variable de entorno. ¿Cómo puedo agregarla?
Ooh, sí. Puedes crearla manualmente. Y tienes que configurar un pequeño pasito en tu angular.json.
A Partir de angular 15 decidieron quitar esta opcion y tu podrías agregarlas manualmente o usar cualquier método para alternar urls entre ambientes.
Pero si se desea generar esos archivos usar:
ng generate environments
En Angular 16^ se puede crear la carpeta de environments desde el CLI, más detalles aquí ==>
IMPORTANTE: Por ningun motivo se deberia incluir una API_KEY dentro de uno de estos archivos environment. Cualquier persona podria ver los detalles de la peticion en el navegador y asi averiguar su valor. Lo mas aconsejable seria tener un proxy server que reciba el request y luego ejecute la llamada a la API usando la clave desde el lado del backend