Automate Frontend Deployment with GitHub Actions and Docker: A Step‑by‑Step Guide

Preface

Deploying a front‑end build to production requires more than running npm run build. The generated bundle must be transferred to a server or CDN and made publicly accessible.

Deployment Challenges

Historical context

Earlier static sites were handed to operations and unpacked directly in the web root. Later, with the rise of jQuery, back‑end teams managed the entry page while static assets were still deployed as simple archives, but performance and reliability requirements exposed the limits of this manual approach.

Current pain points

Effective use of browser caching for static files.

Full automation of the release pipeline to eliminate manual steps.

Rapid rollback of a faulty release.

Automated Deployment Before Release

A typical CI workflow includes:

Push code to a remote repository (e.g., GitHub).

Trigger a build on an isolated build machine.

Check out the target branch, lock the Node.js version, install dependencies, run unit tests and linting.

Execute the build script to generate the production bundle.

Upload the bundle to a CDN or static file server.

Send a notification (e.g., DingTalk, Feishu) with version, timestamp and author.

Key questions

Which operating system should host the build?

Who or what should trigger the build?

How to store and protect CDN credentials?

How to ensure the entire pipeline runs without manual intervention?

Solution

Use Docker to provide a reproducible build environment and GitHub Actions as a free CI service. The Actions workflow runs on ubuntu-latest, checks out the repository, sets up a specific Node.js version, installs dependencies, and runs npm run build. After the build, the artifact can be uploaded via SSH or a CDN API.

Example .github/workflows/build.yml:

name: Build and Deploy
on:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node
        uses: actions/setup-node@v1
        with:
          node-version: '14.7.6'
      - name: Install dependencies
        run: npm ci
      - name: Lint and test
        run: |
          npm run lint
          npm test
      - name: Build production bundle
        run: npm run build
      - name: Deploy via SSH
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          source: "dist/*"
          target: "/var/www/html/"

Establish a password‑less SSH trust between the GitHub Actions runner and the target server using a private key stored in repository secrets.

Post‑Release Automation

Deploying directly to production is risky. A pre‑release (staging) environment that mirrors production but is only accessible to testers mitigates this risk.

Problems

Manual release windows require staff to monitor the process.

Large node_modules directories cause long build times (30 minutes or more), increasing downtime.

Solution

Adopt versioned static assets so each release is identified by a unique hash or version number. This enables instant rollback by switching the served version. Combine with gray‑release or A/B testing to expose a new version to a subset of users while keeping other users on the stable version.

GitHub Actions can be extended to tag the build with a Git SHA or timestamp, push the assets to a versioned directory on the CDN, and update a manifest that the front‑end loads.

After deployment, a notification step can post a message to internal chat tools with details such as version, deployment time, and initiator.

Summary

By containerizing the build environment, using GitHub Actions for CI/CD, managing credentials via encrypted secrets, and versioning static assets, teams can achieve fully automated, repeatable, and reversible front‑end deployments.