CI/CD with GitHub Actions: Automated Testing & Deployment

What is CI/CD?

Without CI/CD, shipping code looks like this: you write code, run tests manually (maybe), build the project, SSH into a server, pull the code, restart services, and pray nothing breaks. With CI/CD, you push code and everything else happens automatically.

A typical CI/CD pipeline:

• 1. Developer pushes code to GitHub
• 2. CI runs Go tests (go test -race ./...)
• 3. CI runs frontend tests (pnpm test)
• 4. If all tests pass, CD deploys to staging
• 5. On tag push (v1.0.0), CD deploys to production

Grit's Scaffolded CI

When you run grit new, it scaffolds a .github/workflows/ci.yml file. This is a complete CI workflow that runs automatically on every push and pull request.

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.24'
      - run: cd apps/api && go test -race ./...

This workflow does 3 things:

• • Checks out your code — downloads the repo to the runner
• • Sets up Go — installs the specified Go version
• • Runs tests — executes all Go tests with race detection enabled

Understanding the Workflow

YAML workflows can look intimidating. Let's break down every section so you can read and write them confidently.

# name: Human-readable name shown in GitHub UI
name: CI

# on: Events that trigger this workflow
# [push, pull_request] = run on every push AND every PR
on: [push, pull_request]

# jobs: Groups of steps that run on a fresh virtual machine
jobs:
  # "test" is the job ID (you choose the name)
  test:
    # runs-on: The OS for the virtual machine
    runs-on: ubuntu-latest

    # steps: Commands that run sequentially
    steps:
      # uses: Run a pre-built action (like a plugin)
      - uses: actions/checkout@v4

      # with: Configuration for the action
      - uses: actions/setup-go@v5
        with:
          go-version: '1.24'

      # run: Execute a shell command
      - run: cd apps/api && go test -race ./...

Key concepts:

• • Jobs run in parallel by default — unless you use needs to create dependencies
• • Steps run sequentially within a job — if one fails, the rest are skipped
• • Each job gets a fresh VM — nothing persists between jobs unless you use artifacts
• • Actions are reusable — actions/checkout@v4 is maintained by GitHub

Adding Frontend Tests

The scaffolded CI only tests the Go API. For a complete pipeline, add a separate job that tests the frontend — Vitest for unit tests, Playwright for end-to-end tests.

  test-frontend:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g pnpm
      - run: pnpm install
      - run: pnpm test

This job runs in parallel with the Go test job. Both must pass for the overall CI to be green. If either fails, the PR gets a red X.

For end-to-end tests with Playwright, you need a running API. Use a service container:

  test-e2e:
    runs-on: ubuntu-latest
    needs: [test, test-frontend]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g pnpm
      - run: pnpm install
      - run: npx playwright install --with-deps
      - run: pnpm test:e2e

The Release Workflow

Grit also scaffolds a release.yml workflow. Unlike CI (which runs on every push), the release workflow only triggers when you push a version tag like v1.0.0. It builds cross-platform binaries and creates a GitHub Release with downloadable files.

name: Release
on:
  push:
    tags: ['v*']

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.24'
      # Build for Linux, macOS, and Windows
      # Create GitHub Release with binaries attached

To create a release:

# Tag the commit
git tag v1.0.0

# Push the tag (triggers the release workflow)
git push origin v1.0.0

# GitHub Actions will:
# 1. Build binaries for linux/amd64, darwin/amd64, darwin/arm64, windows/amd64
# 2. Create a GitHub Release
# 3. Attach the binaries as downloadable assets

Automated Deployment

The most powerful CI/CD feature: automatic deployment. After tests pass, the deploy job ships your code to production. No SSH, no manual steps, no forgetting to restart the service.

  deploy:
    needs: [test]
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.24'
      # Run: grit deploy --host DEPLOY_HOST --domain DEPLOY_DOMAIN
      # Uses secrets for sensitive values

Key parts of the deploy job:

• • needs: [test] — only runs after tests pass
• • if: github.ref == 'refs/heads/main' — only deploys from the main branch (not PRs or feature branches)
• • Secrets store sensitive values like server addresses and SSH keys

Branch Protection

CI is only useful if you enforce it. Branch protection rules prevent merging code that fails CI. No green checkmark, no merge — period.

To set up branch protection:

• 1. Go to Repository Settings
• 2. Click Branches in the sidebar
• 3. Add a branch protection rule for main
• 4. Enable "Require status checks to pass before merging"
• 5. Select the CI jobs (test, test-frontend) as required checks
• 6. Optionally require pull request reviews

With this setup, the development workflow becomes:

# 1. Create a feature branch
git checkout -b feature/add-comments

# 2. Write code, commit, push
git push origin feature/add-comments

# 3. Open a Pull Request on GitHub
# CI runs automatically on the PR

# 4. If CI passes: green checkmark, merge allowed
# If CI fails: red X, merge blocked

# 5. After merge to main: deploy job runs automatically

Environment-Specific Deploys

Production apps need a staging environment — a copy of production where you test changes before they go live. Different branches deploy to different environments:

  deploy-staging:
    needs: [test]
    if: github.ref == 'refs/heads/staging'
    runs-on: ubuntu-latest
    steps:
      # Deploy to staging.myapp.com
      # Uses STAGING_HOST and STAGING_DOMAIN secrets

  deploy-production:
    needs: [test]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      # Deploy to myapp.com
      # Uses PRODUCTION_HOST and PRODUCTION_DOMAIN secrets

The branching strategy:

• • Feature branches — where you write code. CI runs tests.
• • staging branch — merge features here first. Auto-deploys to staging.myapp.com for testing.
• • main branch — merge from staging when ready. Auto-deploys to myapp.com (production).

Notifications

When CI fails at 2 AM, you want to know. When a deployment succeeds, the team should celebrate. Notifications close the feedback loop — the pipeline tells you what happened.

  # Add this step at the end of any job
  - name: Notify on failure
    if: failure()
    # Send a POST request to Slack webhook
    # Body: "CI failed on branch main - commit abc123"
    # The webhook URL is stored as a secret

Common notification patterns:

• • Test failure — urgent notification to Slack/Discord with the failing branch and commit
• • Successful deploy — info notification: "v1.2.0 deployed to production"
• • New release — announcement: "Release v1.2.0 published with 5 new features"
• • Deploy failure — critical alert: "Production deploy failed — rollback may be needed"

Summary

Here's everything you learned in this course:

• CI automatically tests code on every push — catching bugs before they reach production
• CD automatically deploys code after tests pass — no manual SSH deployments
• Grit scaffolds ci.yml (test on push/PR) and release.yml (build on tag push)
• GitHub Actions runs jobs on GitHub servers triggered by events (push, PR, tag)
• YAML workflows define jobs, steps, triggers, and environment configuration
• Frontend tests run as a separate parallel job alongside Go tests
• GitHub Secrets store sensitive values like deploy credentials securely
• Branch protection prevents merging code that fails CI
• Environment-specific deploys: staging branch to staging server, main to production
• Notifications keep the team informed of failures, deploys, and releases