El ambiente de staging en Angular es el paso intermedio entre desarrollo y producción que te permite validar features con stakeholders, QA y product managers antes de liberar al usuario final. Aquí aprendes para qué sirve y cómo configurarlo paso a paso modificando environments y angular.json.

Si trabajas con equipos de ingeniería que manejan flujos de despliegue serios, dominar este ambiente te abre la puerta a buenas prácticas de DevOps y de integración continua.

Para qué sirve un ambiente de staging en un equipo de ingeniería

Staging es una réplica casi idéntica de producción, pero apunta a una API y base de datos distintas para no afectar datos reales de los usuarios.

Este ambiente cumple varias funciones dentro del flujo de trabajo:

• Permite que un product manager o stakeholder revise un feature nuevo antes del release.
• Da espacio al equipo de QA para hacer manual testing y aprobar la versión.
• Ofrece al equipo de DevOps un entorno controlado con su propia API y base de datos.
• Reproduce las optimizaciones de producción sin tocar el ambiente real.

¿Qué es el ambiente de staging? Es un entorno intermedio entre desarrollo y producción donde se prueban features con configuraciones casi idénticas a las reales, pero apuntando a una API y base de datos separadas para no afectar usuarios finales.

Cómo crear el archivo environment.staging.ts en Angular

Dentro de tu carpeta de environments ya tienes el de development y el de production. Para sumar staging, duplicas el archivo y lo nombras siguiendo la convención environment.staging.ts [03:20].

La estructura del archivo mantiene las mismas claves, pero cambian los valores:

• production: true para activar las optimizaciones de Angular como code splitting, minificación y transpilación.
• apiUrl apuntando a la URL que te entregue DevOps, por ejemplo staging.ap.school.
• Cualquier otra variable que necesite valores propios del ambiente intermedio.

La lógica detrás es clara: quieres lo mejor de los dos mundos. Angular compilado y optimizado como en producción, pero pegándole a una infraestructura distinta. Cuando ejecutas ng serve en desarrollo, Angular omite optimizaciones para acelerar el flujo, pero staging sí las necesita porque su misión es parecerse a producción.

Cómo modificar angular.json para soportar staging

Angular no tiene un comando como ng generate staging que automatice esta parte, así que toca editar angular.json con cuidado de respetar los niveles del JSON [05:40].

La ruta dentro del archivo es:

1. projects → tu proyecto, en este caso store.
2. architect → bloque que agrupa build, serve, i18n y test.
3. build → dentro encontrarás configurations con production y development.

Dentro de configurations agregas un nuevo bloque llamado staging. La forma más segura es copiar el fileReplacements del bloque de development y apuntarlo al nuevo environment.staging.ts. Así Angular sabe qué archivo intercambiar al construir.

Por qué también debes configurar el bloque serve

El mismo proceso se replica en serve, aunque la configuración es más sencilla: solo conectas el bloque staging al build que acabas de definir [07:50].

Esto te permite levantar el ambiente staging localmente con ng serve cuando quieras hacer pruebas en tu máquina sin desplegar nada. Es útil cuando necesitas reproducir un bug que solo aparece con configuración de producción.

Cómo correr y construir el ambiente de staging desde la terminal

Una vez configurado, los comandos para usarlo son directos. La bandera -c (de configuration) le dice a Angular qué ambiente cargar.

Para correrlo localmente:

bash ng serve -c staging

Angular te lanzará un alert avisando que estás corriendo ng serve con production: true. No es un error, es un recordatorio. Le respondes que sí, que esa es la intención.

Para generar el build listo para desplegar:

bash ng build -c staging

Este comando produce los archivos compilados con todas las optimizaciones de producción, pero con las variables del entorno staging. Desde ahí puedes mandarlo a Firebase, Netlify o cualquier servicio donde tu equipo y stakeholders lo prueben.

¿Para qué sirve la bandera -c en Angular CLI? Le indica a Angular qué configuración usar al servir o construir la aplicación. Sin ella, Angular usa development por defecto en ng serve y production por defecto en ng build.

Cómo encaja staging en el proceso de integración continua

Los equipos de DevOps suelen automatizar el comando ng build -c staging dentro del pipeline de CI/CD. Cada vez que se hace merge a una rama específica, el ambiente staging se actualiza solo.

Si tu equipo aún no tiene esa automatización, puedes correr el build manualmente y subirlo a un hosting estático. La idea es que stakeholders entren a una URL y validen el feature antes de que llegue al usuario final.

Dominar esta configuración te posiciona como alguien que entiende el flujo completo: no solo escribes código, también sabes cómo se entrega. ¿Tu equipo ya usa staging o están saltando directo de development a producción? Cuéntame cómo manejan ese paso intermedio.