Skip to main content

Deploying to a Host & CI/CD

In this section I will demo the deployment of an Angular app to Firebase Hosting.

CI/CD means Continuous Integration and Continuous Delivery/Deployment, and it is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment.

Continuous Integration (CI)​

CI is a coding philosophy and set of practices that drive development teams to implement small changes and check-in code to version control repositories frequently. Because most modern applications require developing code in different platforms and tools, the team needs a mechanism to integrate and validate its changes.

Continuous Delivery (CD)​

CD is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button. In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches, that are easy to troubleshoot in case of a problem.

Continuous Deployment (CD)​

CD is an extension of continuous delivery that involves deploying changes to production without human intervention. With this approach, every change that passes all stages of your production pipeline is released to your customers.

Goals & Purpose of CI/CD​

CI/CD aims to lead to more rapid, reliable, and frequent release cycles in software development. They facilitate faster feedback, lower risk of releases, and speedier delivery of features. They do this by reducing manual processes in the pipeline, replacing them with automated counterparts, limiting scope of changes per release, and promoting a culture of frequent releases and updates.

Deploying to Firebase Hosting

What is Firebase Hosting?​

Firebase Hosting is a static and dynamic web hosting service. It supports hosting static files such as CSS, HTML, JavaScript and other files, as well as dynamic Node.js applications. The service delivers files over a content delivery network (CDN) through HTTP Secure (HTTPS) and Secure Sockets Layer encryption (SSL).

You will need to create a Firebase account and may create a Firebase project now.

Deploying to Firebase Hosting from your local machine​

Step 1: Install the Firebase CLI​

To install the Firebase CLI, run the following command in your terminal:

npm install -g firebase-tools

Step 2: Login to Firebase​

To login to Firebase, run the following command in your terminal:

firebase login

Step 3: Initialize your project​

To initialize your project, run the following command in your terminal:

firebase init

Step 4: Build your project​

To build your project, run the following command in your terminal:

ng build --prod

Step 5: Deploy your project​

To deploy your project, run the following command in your terminal:

firebase deploy

Deploying to Firebase Hosting from GitHub​

We will use Github Actions to automatically deploy our app to Firebase Hosting.

In order to do this, we will need to create a folder in our project named .github, with a subfolder named workflows. In the workflows folder, we will create a file named prod-deployment.yml. This file contains the steps required to build and deploy our app.

.github/workflows/prod-deployment.yml
name: Deploy to Firebase Hosting on PR
'on':
  push:
    branches:
      - release
jobs:
  build_and_preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: yarn install && yarn build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_CODINGSHADOWS_ACADEMY }}'
          channelId: live
          projectId: codingshadows-academy

A breakdown of the config file components:

  • name: The name of the workflow. In this case, it's "Deploy to Firebase Hosting on PR".
  • on: This is the GitHub event that triggers the workflow. In this case, a 'push' event to the 'release' branch will trigger the workflow.
  • jobs: It defines the sequence of tasks (named jobs) that make up a workflow. In this case, we have one job defined, 'build_and_preview'.
  • runs-on: This specifies the type of machine to run the job on. Here, it is an Ubuntu-latest machine.
  • steps: The steps are the commands or tasks that the job will execute. There are three steps in this job:
    • uses: actions/checkout@v3 This step checks out your repository into the Ubuntu runner, allowing it to access the context of your project.
    • run: yarn install && yarn build This step utilizes Yarn (a package manager similar to NPM) to install the project's dependencies and then build the project.
    • uses: FirebaseExtended/action-hosting-deploy@v0 This step leverages a pre-built GitHub Action ('FirebaseExtended/action-hosting-deploy') designed to deploy a project to Firebase Hosting.
  • with: It provides the input parameters to the action. In this case, these parameters are:
    • repoToken: This input uses the secrets.GITHUB_TOKEN secret, which is a GitHub token automatically created for every GitHub repository.
    • firebaseServiceAccount: It holds the secret key of the Firebase service account. secrets.FIREBASE_SERVICE_ACCOUNT_CODINGSHADOWS_ACADEMY is the referenced GitHub secret containing this key.
    • channelId: Specifies which Firebase Hosting channel to deploy to. In this case, it's the 'live' channel.
    • projectId: Specifies the Firebase project to which the deployment should happen.

After this setup, every time you push to the 'release' branch, the workflow will be triggered and the app will automatically be deployed to Firebase Hosting.

Other Github Actions triggers​

You can also trigger the workflow on other events, such as pull requests, tags, or comments.

On every pull request event

This will trigger the workflow whenever a new pull request is made to the 'master' branch.

'on':
  pull_request:
    branches:
      - release

On every push event In this case, the workflow will be triggered whenever there is a 'push' event to the repository.

'on': push

On creating a new tag Here, the workflow will be triggered whenever a new tag is created in the repository.

'on':
  create:
    tags: ...

On pull request review comments In this case, the workflow triggers upon pull request review comments.

'on':
  pull_request_review_comment:
    types: [ created, edited ]

Scheduled Workflows You can set up a cron job to perform actions repeatedly at fixed times, dates, or intervals.

'on':
  schedule:
    - cron: '*/15 * * * *'

This workflow runs every 15 minutes.

Manually triggered workflows GitHub Actions provides the ability to manually trigger workflows via the workflow_dispatch event.

'on': workflow_dispatch