Utiliza GitHub Actions para el Despliegue de Aplicaciones Angular en Firebase Hosting

Este es otro post sobre cómo lograr este objetivo. Dado que necesito cubrirlo para la serie sobre el uso de ComponentStore, escribiré un post breve (resultó ser más largo de lo que pensé) explicando el proceso.

Parte 1: Agregar y configurar Firebase con nuestro proyecto

El primer paso es instalar firebase-tools. Esto nos permite usar Firebase directamente a través de nuestra consola y nos ayuda a configurar todo para trabajar con Firebase:

npm install -g firebase-tools

Inicia sesión en Firebase a través de la consola:

firebase login

Sigue los pasos hasta que se te solicite abrir una pantalla para iniciar sesión en Firebase usando tu cuenta de Gmail. Al final del proceso, deberías ver una imagen similar a esta en tu navegador:

Después de completar estos pasos, ahora podemos usar firebase-tools para crear un proyecto en Firebase Hosting y configurar todo automáticamente:

firebase init hosting

Esto nos guiará a través de 3 pasos, que incluyen:

1. Inicializar el proyecto:

Crear todos los archivos necesarios en nuestro repositorio, crear el proyecto en Firebase y configurar el proyecto y las credenciales en nuestro Google Cloud.

• Elige Hosting: Configure files for Firebase Hosting and (optionally) set up GitHub Action deploys

• Selecciona Create a new project

• Establece un unique project id intenta escribir un ID único, si no escribes algo único, todo fallará y tendrás que empezar de nuevo.

• Establece un name for your project (lo mismo aquí)

1. Configuración del hosting:

• What do you want to use as your public directory? dist/series-workspace (si no estás seguro, esto se puede cambiar más tarde en el archivo firebase.json)

• Configure as a single-page app (rewrite all urls to /index.html)? Yes, Angular es una aplicación de una sola página (SPA)

• Set up automatic builds and deploys with GitHub? Yes, esto es muy importante, aquí firebase-tools intentará conectarse a Github y obtener información del git actual, abrirá una página de inicio de sesión de una aplicación (aplicación de firebase) que intenta usar GitHub para recuperar datos de nuestra cuenta. Si todo está bien aquí, verás en la consola ✔ Success! Logged into GitHub as YOUR_GITHUB_USER_HERE

• For which GitHub repository would you like to set up a GitHub workflow? aquí, solo quiero una confirmación del nombre del repositorio (OUR_GITHUB_USER/REPO_NAME) si es incorrecto, escribe el correcto

1. Crear los archivos de Actions:

• Set up the workflow to run a build script before every deploy? Yes, esto es importante, con esta pregunta confirmamos que queremos que firebase-tools cree automáticamente un archivo de Github Action para nuestro repositorio usado cuando haces un Pull Request en Github.

• What script should be run before every deploy? yarn install && nx build series-workspace, en mi caso, si no estás seguro, puedes cambiarlo más tarde en el archivo YAML.

• Set up automatic deployment to your site's live channel when a PR is merged? Yes, esto es para crear otra Github Action para detectar un merge a main.

• What is the name of the GitHub branch associated with your site's live channel? main, en mi caso.

Ahora tenemos 4 archivos nuevos en nuestro repositorio:

• firebase.json Es el archivo de configuración para Firebase en nuestro proyecto, en este caso, solo veremos la configuración de hosting, allí podemos cambiar la ruta correcta a la carpeta public, los otros valores se dejan tal como están.

• .firebaserc Aquí puedes ver el project id.

• .github/workflows/firebase-hosting-pull-request.yml GitHub Action se activa al detectar un nuevo PR

• .github/workflows/firebase-hosting-merge.yml Github Action se activa cuando haces un merge a main

En el firebase-hosting-pull-request.yml, notarás dos tokens secretos. FIREBASE_SERVICE_ACCOUNT_SERIES_PROJECT_V1 se crea automáticamente en las configuraciones de secretos de nuestro repositorio (contiene una credencial creada automáticamente en nuestro Google Cloud). El otro token, GITHUB_TOKEN, lo establece automáticamente GitHub cuando ejecuta la GHA.

Este es nuestro archivo base de acción firebase-hosting-pull-request.yml:

## This file was auto-generated by the Firebase CLI
## https://github.com/firebase/firebase-tools

name: Deploy to Firebase Hosting on PR
'on': pull_request
jobs:
  build_and_preview:
    if: '${{ github.event.pull_request.head.repo.full_name == github.repository }}'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: yarn install && npx nx build series-workspace
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_SERIES_V1_DB }}'
          projectId: series-v1-db

Parte 2: Mejoremos la GitHub Action

Github Actions nos permite realizar verificaciones, compilar código, crear imágenes Docker y hacer todo lo necesario para entregar nuestras aplicaciones. Hay muchas formas de lograr las mismas tareas, pero depende del tamaño y la complejidad de nuestra aplicación. Con eso en mente, definamos nuestros requisitos por el momento:

• Al crear un PR, necesitamos:

  • Asegurar que las pruebas se ejecuten sin fallos

  • Asegurar que el lint se ejecute sin fallos

  • Asegurar que nuestro código pueda compilarse (build) sin fallos

  • Enviar a Firebase Hosting al canal de preview para echar un vistazo a la funcionalidad.

• Al realizar un merge:

  • Asegurar que nuestro código pueda compilarse (build) sin fallos, y además

  • Enviar a Firebase Hosting al canal live

Ese es nuestro plan; por simplicidad, continuaremos usando la Github Action generada para PR (firebase-hosting-pull-request.yml) y merge (firebase-hosting-merge.yml) a main.

Con todos los requisitos para el PR agregados al archivo, este es el archivo final firebase-hosting-pull-request.yml

name: Deploy to Firebase Hosting
on: # when does the workflow run?
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
    branches: [main]
permissions:
  actions: read # Needed for nx-set-shas
  contents: read # Needed for nx-set-shas
  checks: write # Needed for GITHUB_TOKEN
jobs:
  build_and_preview: # name of the job
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4 # Checkout the repository at the latest commit
        with:
          fetch-depth: 0 # Fetch all history for all branches so that nx affected can compare against all commits

      - name: Setup Node.js
        uses: actions/setup-node@v3 # Cache node_modules to speed up builds
        with:
          node-version: 18 # Use the version 18 of Node.js
          cache: 'yarn' # Cache node_modules to speed up builds

      - name: Install Dependencies
        run: yarn install --frozen-lockfile # Install dependencies using yarn with a frozen lockfile

      - name: Setup Nx SHA
        uses: nrwl/nx-set-shas@v3 # Sets environment variables for commit SHAs, optimizing Nx's change detection for efficient CI processes

      - name: Check Git Branch
        run: git branch --track main origin/main # This line is needed for nx affected to work when CI is running on a PR

      - name: Run Nx Format Check
        run: npx nx format:check # Run the format check

      - name: Run Nx Affected Commands
        run: npx nx affected -t lint,test,build --parallel=3 # Run the lint, test, and build targets in parallel

      - name: Deploy to Firebase Hosting Preview Channel
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_SERIES_V1_DB }}'
          projectId: series-v1-db
          #channelId: preview by default if you don't specify it.

Podemos observar un total de 8 pasos en nuestro archivo de acción, con los primeros 6 preparando todo para ejecutar el comando Run Nx Affected Commands npx nx affected -t lint,test,build --parallel=3. Este comando ejecuta Nx affected para las tareas (-t) lint, test y build, e incluye una bandera que permite que hasta 3 tareas se ejecuten simultáneamente. Con esto, podemos asegurar que todo en nuestro repositorio esté 100% correcto antes de ejecutar el último paso de nuestro trabajo Deploy to Firebase Hosting Preview Channel.

Cuando la acción se ejecuta exitosamente en GitHub, vemos algo bastante similar a esto en nuestro PR, en la pestaña Checks. Podemos ver la lista de acciones detectadas, y al hacer clic en el nombre de la acción (Deploy to Firebase Hosting en nuestro caso), podemos examinar los detalles de los trabajos y todos los pasos dentro de cada trabajo.

Bien, pero ¿qué pasa con el merge a la rama main? Para eso, configuramos el otro archivo GHA, firebase-hosting-merge.yml. Este archivo es similar, con solo algunos detalles cambiados.

name: Deploy to Firebase Hosting on merge
on: # when does the workflow run?
  push:
    branches:
      - main
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4 # Checkout the repository at the latest commit
        with:
          fetch-depth: 0 # Fetch all history for all branches so that nx affected can compare against all commits

      - name: Setup Node.js
        uses: actions/setup-node@v3 # Cache node_modules to speed up builds
        with:
          node-version: 18 # Use the version 18 of Node.js
          cache: 'yarn' # Cache node_modules to speed up builds

      - name: Install Dependencies
        run: yarn install --frozen-lockfile # Install dependencies using yarn with a frozen lockfile

      - name: Run Build App
        run: npx nx build series-workspace #build the app

      - name: Deploy to Firebase Hosting Preview Channel
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_SERIES_V1_DB }}'
          channelId: live # Deploy to live channel
          projectId: series-v1-db

Las tres (3) principales diferencias son:

1. Lo que activa la acción, en este caso, un merge (push) a main.

on: # when does the workflow run?
  push: # only trigger with a push to main (PR merged to main)
    branches:
      - main

1. Y, a qué canal enviaremos la compilación final, en este caso al canal live en Firebase.

 firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_SERIES_V1_DB }}'
          channelId: live # Deploy to live channel
          projectId: series-v1-db

1. Solo hacemos un build, en lugar de verificar lint, test y format. En el PR, hicimos todos estos pasos para estar seguros de que todo estaba bien. Ahora solo necesitamos compilar la aplicación y enviar el código.

      - name: Run Build App
        run: npx nx build series-workspace #build the app

Si vas a tu Consola de Firebase, al proyecto creado, puedes ver:

• Tu Current release se reemplaza con cada merge a main.

• Previous releases (si quieres hacer un rollback), y,

• Preview channels (Cada PR tiene un enlace diferente, y ese enlace estará disponible solo por 7 días)

Este enfoque hace que el despliegue de tu SPA sea sencillo, y si usas otras herramientas de Firebase como Authentication, Messaging, Functions, Realtime Database o Firestore, tendrás todo lo que necesitas para completar tu proyecto secundario sin problemas.

Aquí está la GHA final ejecutándose en GitHub PR Action y la Merge Action.

Conclusión

GitHub Actions y Firebase Hosting juntos proporcionan una forma poderosa y eficiente de desplegar tus aplicaciones Angular. Al automatizar el proceso de ejecutar pruebas, verificaciones de lint y compilaciones antes del despliegue, puedes garantizar la integridad y confiabilidad de tu código. Además, los canales de vista previa y en vivo de Firebase Hosting permiten una revisión y prueba exhaustiva de tu aplicación antes de que se publique. Este proceso no solo simplifica el despliegue de aplicaciones de una sola página, sino que también se integra perfectamente con otras herramientas de Firebase, lo que lo convierte en una solución ideal para completar proyectos secundarios o incluso aplicaciones a mayor escala.

Deja un comentario y déjame saber si falta algo o si quieres más detalles sobre algún paso.