Configura un flujo CI/CD sólido en Angular con GitLab CI y GitLab Pages para publicar en producción de forma continua. Aquí verás cómo pasar de un commit a un sitio activo, usando stages de install, test, build y deploy, variables de ambiente, artifacts y ajustes de Angular como BASE_HREF para servir correctamente en Pages.
¿Cómo se prepara el flujo de trabajo en GitLab?
Comienza con una integración continua ya operando: cada commit detona un pipeline que ejecuta install y test. El objetivo es extenderlo para publicar automáticamente en GitLab Pages con un proceso claro de colaboración.
¿Qué roles cumplen issue y merge request?
Crear un issue: “Integrar con GitLab Pages”.
Asignarlo y describir: “desarrolla el código para integrar la app con GitLab Pages”.
Abrir un merge request y generar el branch de trabajo.
Trabajar en el branch y fusionar a master cuando esté listo.
¿Qué comandos de Git se usan?
git branch y git pull: obtener referencias remotas.
git checkout: cambiar al branch de trabajo.
git status: revisar cambios.
git add .: preparar archivos.
git commit -m: documentar el cambio.
git push: enviar al remoto con autenticación SSH y firma PGP.
¿Cómo se configura el pipeline de GitLab CI para Angular?
El archivo .gitlab-ci.yml ya incluye install y test. Se añaden dos stages: build y deploy, y los jobs correspondientes para construir y publicar la app estática.
stages:- install
- test
- build
- deploy
¿Qué hace el job de build en producción?
Declara una variable de ambiente para la configuración: production.
Define dependencies del job de instalación para reutilizar node_modules.
Ejecuta el script: npm run build.
Exporta artifacts del directorio dist con expiración de 1 hora.
Aplica optimizaciones de Angular para producción como tree shaking y código compacto.
Ejemplo del ajuste en package.json para usar la variable de ambiente en el build de Angular:
