Configuración de GitLab Pages para deploy automático de Angular

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:

{
  "scripts": {
    "build": "ng build --configuration $BUILD_CONFIGURATION"
  }
}

Donde $BUILD_CONFIGURATION toma el valor “production” desde el pipeline.

¿Cómo publica Pages los archivos estáticos?

• El job de Pages debe llamarse Pages para que GitLab lo identifique.
• Pertenece al stage de deploy y depende del job de build para obtener dist.
• Crea el directorio public y mueve ahí el contenido de dist/tu-proyecto.
• Declara artifacts con paths: public para que GitLab sirva esos archivos.
• Configura un environment llamado “Producción”.
• Limita por ahora a only: branches y luego a master cuando corresponda.

¿Qué ajustes finales garantizan el despliegue en Pages?

GitLab Pages no sirve desde la raíz del dominio cuando el proyecto vive dentro de un grupo. Por eso Angular debe conocer el BASE_HREF correcto.

¿Cómo ajustar BASE_HREF para una subruta?

• Indicar que la app no vive en root, sino en la ruta del proyecto: platsy DevOps.
• Con ese BASE_HREF, Angular genera referencias válidas a recursos y rutas.
• Nota: cada framework ajusta este detalle de forma distinta, pero la idea es la misma.

¿Cómo validar la sintaxis y activar la publicación?

• Usar el validador de configuración de GitLab, CI Lint, para comprobar .gitlab-ci.yml.
• Confirmar que el pipeline corre con los 4 stages: install, test, build y deploy.
• Al finalizar, ir a Settings > Pages para ver la URL pública del proyecto sirviéndose desde GitLab Pages.

Palabras clave y habilidades practicadas: - Integración continua (CI) y entrega continua (CD). - Pipeline, stages, jobs, dependencies y artifacts en GitLab CI. - GitLab Pages para publicar sitios estáticos. - Angular build con configuración para producción y BASE_HREF en subruta. - Flujo colaborativo con issue, merge request y branching. - Comandos de Git para versionar y enviar cambios. - Validación con CI Lint antes de hacer push.

¿Tú cómo estructurarías los jobs de build y Pages en tu repositorio? Comparte tu enfoque y dudas en los comentarios.