This exercise walks through automating the deployment (Continuous deployment) of the front-end application using GitHub actions.

Objective

Create a system that automatically deploys the code to the S3 bucket and invalidates the caches on CloudFront whenever a pull request is merged or the code is pushed to the main branch on GitHub.

Description

Acceptance criteria

Hints

Introduction: GitHub Actions

GitHub actions is a way to automate your workflows. You can set up GitHub actions to run whenever you push code to GitHub, or when someone opens a pull request. GitHub actions can also be triggered by events such as new issues, comments, or commits. GitHub actions is a great way to automate your development process and make sure that your code is always up-to-date.

GitHub Action allows you to create custom automated workflows directly into your GitHub repository. You can write individual tasks (actions) and combine them to create workflows. Workflow can be considered as automating all the tasks (actions) that you would otherwise perform manually.

In order to create a workflow, you would write down the steps in a configuration file.

Example: Install dependencies -> Build the project -> Deploy

GitHub Action uses YAML files to define this configuration.

You can configure to trigger a workflow when an event occurs on GitHub such as when a code is pushed to a branch, or when a pull request is created. Workflow can spin up one or more containers for you in the cloud, then you provide a set of steps or instructions for the container to do something useful. GitHub logs the progress of each step and makes it very clear if something fails.

When you visit your repo on GitHub you can see the “Actions” tab. This is where you can monitor your actions. When it is triggered it will give you a log of everything that has happened.

Development workflow:

The above figure describes the development workflow.

• The “Main” branch contains the code for the production version of the application.
• For developing a new feature, a developer creates a “feature” branch from the stable “main” branch.
• The developer adds commits and opens a Pull Request for the feature to be added to the main branch.
• The code is reviewed and once approved, the developer merges the “feature” branch into the “main” branch.

Deployment workflow:

The figure above describes the proposed deployment workflow.

• GitHub actions workflow should be triggered once the feature branch is merged into the “main” branch or new code is pushed to the “main” branch.
• GitHub actions should now install the dependencies, build the project, deploy to S3 bucket, and invalidate the cache on CloudFront.
• If any of the steps fails, GitHub actions will show a red checkmark automatically and the deployment will be failed as expected. If everything goes according to the plan, the GitHub actions will show a green checkmark and the code will be deployed.

Create a workflow file:

In the source code create a new directory “.github/workflows” that GitHub Actions will watch to know which steps to execute. Anything in this workflow directory will be picked up by Github and set up as a workflow in the cloud.

Next, create a file “deploy.yml”. We will define the workflow in this YAML file.

mkdir .github/workflows/

touch .github/workflows/deploy.yml

Inside the “deploy.yml” file, we will begin by giving it the name “Production build”. name: Production Build

Then, we need to tell it on which event or events to run. We do that with the “on” object. In our example, we want to run it when code is pushed to the master branch.

on:
  push:
    branches:
    - master

Each workflow should have one or more jobs. You define these jobs on the “job” object. You can give the job the name “build” and from there we need to tell the job which VM to run on. We will run this on Ubuntu.

jobs:
  build:
    runs-on: ubuntu-latest

Next, we need to give this job instructions that will actually build and run this code.

First, we need to get the source code into the virtual machine using an action called “Checkout”. This brings the source code into the current working directory and that means you can run commands as you would from the command line

We also need to set up Node.js to run those commands. So we use the node setup action and then specify the version.

jobs:

  build:

    runs-on: ubuntu-latest

    strategy:

    matrix:

      node-version: [12.x]

    steps:

    - uses: actions/checkout@v1

    - name: Use Node.js ${{ matrix.node-version }}

      uses: actions/setup-node@v1

      with:

        node-version: ${{ matrix.node-version }}

Then, we are ready to start running our own commands. We need to install all dependencies using the npm install or npm ci command. Then, we will build the code with npm run build.

name property specifies a name for your step to display on GitHub.

action property selects an action to run as part of a step in your job. An action is a reusable unit of code.

Syntax to write the action: {owner}/{repo}@{ref}

In this action actions is the owner of the repo set-up node. And ref is the version v1.

- name: NPM Install

  run: |

    npm ci

- name: Production Build

  run: |

    npm run build

Next, we need to run commands that will deploy the built project to AWS. If we were doing this locally, we can use AWS CLI by authenticating with the AWS keys. Similarly, we can share a secret token with GitHub.

To deploy to our AWS S3 bucket from our GitHub Action we first need to configure two new secrets in our repository. These secrets are for our AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

Navigate to the Settings section of your GitHub repository and locate the Secrets section on the left-hand side.

Once there we are going to add a new secret for AWS_ACCESS_KEY_ID and paste in the access_key. Then we are going to add another secret for AWS_SECRET_ACCESS_KEY and paste in our secret_access_key.

GitHub will automatically encrypt this value for us and then we can access it from Action’s VM. This gives us a way to securely authenticate with AWS from the GitHub actions workflow.

Next, add the S3 bucket name (AWS_S3_BUCKET) and CloudFront invalidation id (CLOUDFRONT_DISTRIBUTION_ID) as secret keys respectively.

Now to deploy to AWS, we will use a third-party action from the Action Marketplace.

Select an “Actions” that takes care of all steps required to set up AWS CLI on GH Actions and run AWS commands.

For deploying to S3, we will use the S3-sync action: https://github.com/marketplace/actions/s3-sync

For CloudFront invalidation, we will use the invalidate CloudFront action:

https://github.com/marketplace/actions/invalidate-cloudfront

- name: Deploy to S3 production bucket

  uses: jakejarvis/s3-sync-action@master

  with:

    args: --acl public-read --delete

  env:

    AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}

    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

    AWS_REGION: 'us-east-1'

    SOURCE_DIR: "dist"

    DEST_DIR: "prod/"

The action will run the AWS command and then we tell it to use the arguments required to make our static assets public.

--acl public-read makes your files publicly readable

--delete permanently deletes files in the S3 bucket that are not present in the latest version of your repository/build.

It will be looking for environment variables of AWS tokens. We can access our secret GitHub values as follows: ${{ secrets.token }}

Similarly, we use actions to invalidate the CloudFront cache by setting the default parameters required by the action and AWS command (eg. distribution id, paths, and aws region) along with AWS access keys.

  uses: chetan/invalidate-cloudfront-action@master

  env:

    DISTRIBUTION: ${{ secrets.DISTRIBUTION_PRODUCTION_ID }}

    PATHS: '/*'

    AWS_REGION: 'us-east-1'

    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Now if we commit this new workflow file we should then be able to see in the Actions section of our GitHub repository that the job runs to completion.

We now have continuous deployment configured for our static website repository living on GitHub but deploying to our S3 bucket

Now, the above-created workflow will be triggered whenever a Pull Request is merged into the master branch.

It automatically builds and deploys the code to AWS, and the changes are reflected on the webpage.

  uses: chetan/invalidate-cloudfront-action@master

  env:

    DISTRIBUTION: ${{ secrets.DISTRIBUTION_PRODUCTION_ID }}

    PATHS: '/*'

    AWS_REGION: 'us-east-1'

    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Now if we commit this new workflow file we should then be able to see in the Actions section of our GitHub repository that the job runs to completion.

We now have continuous deployment configured for our static website repository living on GitHub but deploying to our S3 bucket

Now, the above-created workflow will be triggered whenever a Pull Request is merged into the master branch.

It automatically builds and deploys the code to AWS, and the changes are reflected on the webpage.

Managing workflow with GitHub Actions:

You can manage the workflow by navigating to the actions tab on your GitHub repo. The above image shows the successful completion of a GitHub Action that installed dependencies, built the project, deployed the code to the S3 bucket, and invalidated the cache.

YAML file for GitHub Actions

name: Automate deployment - Production build

on:
    push:
        branches: - main

jobs:
    build:
        runs-on: ubuntu-latest

        strategy:
            matrix:
                node-version: [12.x]

    steps:
    - uses: actions/checkout@v1
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}

    - name: NPM Install
    run: |
        npm ci

    - name: Production Build
    run: |
        npm run build

    - name: Deploy to S3 bucket
    uses: jakejarvis/s3-sync-action@master
    with:
        args: --acl public-read --delete
    env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'us-east-1'
        SOURCE_DIR: "dist"
        DEST_DIR: "prod"

    - name: Invalidate CloudFront
    uses: chetan/invalidate-cloudfront-action@master
    env:
        DISTRIBUTION: ${{ secrets.DISTRIBUTION_STAGE_ID }}
        PATHS: '/\*'
        AWS_REGION: 'us-east-1'
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}