CI/CD Basics: Automate Deploys with GitHub Actions

Continuous integration (CI) means automatically testing every change. Continuous deployment (CD) means automatically shipping the ones that pass. GitHub Actions gives you both, defined as a file in your repo.

How Actions is structured

• Workflow — a YAML file in .github/workflows/.
• Trigger — what starts it (push, pull_request, a schedule).
• Job — a set of steps that run on a fresh virtual machine.
• Step — a single command or reusable action.

A CI workflow: test every push

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

Now every push runs your test suite on a clean machine. Pull requests show a green check or a red X before anyone merges.

Adding deployment

Extend it to deploy when changes land on main:

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - run: npx wrangler pages deploy dist
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

needs: test ensures deployment only runs if tests passed. The if guard limits it to main.

Two rules that save pain

• Store secrets in repo settings, never in the YAML. Reference them as ${{ secrets.NAME }}.
• Pin action versions (@v4) so a surprise update can’t break your pipeline.

Start with just the test job. Once you trust it, add the deploy step — and never SSH in to deploy by hand again.