GitHub Actions and CI/CD: a designer's guide to automated deployments

The first time I set up a GitHub Actions workflow that automatically built and deployed my project on every push, it felt like a superpower. No more manual builds. No more “it works on my machine.” No more forgetting to deploy after merging. CI/CD—continuous integration and continuous deployment—is one of those engineering practices that sounds intimidating until you understand the mechanics, after which it sounds obvious. For designers who work in code, automated deployment pipelines change the entire shape of the work: you stop thinking about deployment as a separate task and start thinking about it as the natural end of every change.

What CI/CD actually means for design-technical work

CI/CD stands for continuous integration and continuous deployment. These are two related but distinct practices.

Continuous integration (CI) means that every time you push code to a branch, automated checks run: the project builds, linting passes, tests run. If something breaks, you know immediately—before it gets merged into the main branch and before it reaches production. For design work in code, the relevant CI checks are: does the project build successfully, does the CSS lint without errors, and (if you’ve set it up) do your components pass accessibility audits.

Continuous deployment (CD) means that when code is merged to the main branch, it automatically deploys to production. No manual deploy steps, no “who has the deploy key,” no coordination required. For a feature branch, CD often means deploying a preview URL so you can see the actual live output before merging.

Together, CI/CD creates a workflow where: push → check → preview → merge → deploy. Each step is automatic. The feedback loop from writing code to seeing it live in a browser is measured in minutes, not hours or days.

The anatomy of a GitHub Actions workflow

GitHub Actions workflows are defined in YAML files that live in .github/workflows/ inside the repository. Each file defines a set of automated jobs that run in response to triggers—pushes, pull requests, scheduled times, or manual dispatches.

A minimal workflow for an Astro or static site:

name: Build and Preview

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build

This workflow runs on every pull request targeting main. It checks out the code, installs dependencies, and runs the build. If the build fails, the PR is flagged and you know before merging.

The key concepts in the YAML:

• on: the trigger. pull_request means it runs when a PR is opened or updated. push would run on every push. schedule runs on a cron.
• jobs: the units of work. Each job runs on a fresh virtual machine.
• steps: the individual actions within a job. Each step is either a reusable action (uses:) or a shell command (run:).
• runs-on: the operating system for the virtual machine. ubuntu-latest is standard for most web projects.

How do you set up PR preview deployments for design review?

Preview deployments are the single highest-value thing CI/CD adds to a design workflow. A preview deployment means every pull request automatically gets a live URL where you can see exactly what the branch looks like in a real browser, at real scale, on real devices. Design review becomes reviewing the actual output, not inferring it from a Figma mockup.

Most static site hosts (Vercel, Netlify, Cloudflare Pages) provide this as a first-class feature—every PR gets a unique preview URL automatically. For self-hosted setups or more control, you can configure it directly in GitHub Actions using a deployment workflow.

With Vercel (simplest setup):

1. Connect your GitHub repository to Vercel
2. Vercel automatically creates a GitHub App that handles preview deployments
3. Every PR gets a comment with a preview URL from Vercel, no YAML required

With GitHub Pages + custom workflow (more control):

name: Deploy Preview

on:
  pull_request:

jobs:
  deploy-preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - name: Deploy to preview
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist
          destination_dir: preview/${{ github.event.pull_request.number }}

This deploys the PR build to a subdirectory on GitHub Pages, making it accessible at https://your-username.github.io/your-repo/preview/123. The PR number is the directory, so every PR gets its own URL. Share it with stakeholders for review before merging.

For landing pages and marketing sites built with the design-marketing workflow covered in shipping landing pages with Cursor, Claude Code, and GitHub, this PR preview setup is the infrastructure that makes real-time collaboration between design and marketing possible.

Automated accessibility checks in your CI pipeline

One of the most valuable automated checks you can add is accessibility linting. Accessibility issues that slip into production are expensive to fix and damaging to users. Catching them in CI—before they merge—changes the economics.

The axe-core library is the standard for automated accessibility testing. Combined with pa11y or direct Playwright integration, you can run accessibility audits against your built HTML automatically:

- name: Accessibility audit
  run: |
    npm install -g pa11y-ci
    npm run build
    npx serve dist &
    sleep 2
    pa11y-ci http://localhost:3000

This spins up a local server from the built site and runs pa11y against it. Any WCAG 2.1 AA violations fail the CI check and block the merge. The result: accessibility becomes a non-negotiable constraint, not an afterthought.

For design system component libraries, you can integrate Storybook with the a11y addon and run Storybook tests in CI to audit every component variant automatically. This creates a feedback loop where accessibility regressions in components are caught at the component level before they propagate to the product.

What does a mature CI/CD setup look like for design-engineering teams?

A mature pipeline for a design-engineering team typically has three layers of automation:

Per-commit checks (fast, lightweight):

• Build verification: does the project build without errors?
• Linter: does the CSS/TypeScript lint clean?
• Type checks: no TypeScript errors?
• Total: 2–3 minutes

Per-PR checks (more thorough):

• Build + full lint suite
• Accessibility audit against key pages
• Visual regression tests (screenshot comparison against baseline)
• Preview deployment to a shareable URL
• Total: 5–10 minutes

On-merge-to-main (production deployment):

• Full build and test suite
• Production deployment
• Post-deployment health check (does the production URL respond 200?)
• Notification to team Slack channel with deployment status
• Total: 5–10 minutes

The visual regression testing layer is particularly valuable for design-engineering teams. Tools like Chromatic (built for Storybook) or Percy take screenshots of your components and pages on every PR and compare them against the last approved baseline. Any visual change—intended or accidental—is flagged for review. This catches the subtle regressions that human PR review misses: a font-weight change, a shadow that shifted, a component that renders differently on a specific viewport width.

How do you get started with GitHub Actions without an engineering background?

The best starting point is one of the built-in workflow templates GitHub provides. When you navigate to the Actions tab in any repository, GitHub suggests starter workflows based on your project type. For a JavaScript project, it will suggest Node.js workflows. For an Astro project, there are community templates.

Start with the simplest possible workflow: a build check on every PR. Add one thing at a time—lint check, accessibility audit, preview deployment. Each addition is a single step in the YAML. Read the GitHub Actions documentation for the step you’re adding; the documentation is well-written and the examples are directly usable.

The learning curve is real but shallow. The YAML syntax is strict about indentation, which causes most beginner failures. Use a YAML validator before pushing. Beyond that, the concepts translate directly from what you already know: triggers are like event listeners, jobs are like functions, steps are like lines of code.

For the broader context of how version control and branching strategies support design-engineering collaboration, git for designers: rebase, amend, and how to earn engineering trust covers the git foundations that CI/CD builds on.

Key Takeaways

• CI/CD creates a push → check → preview → merge → deploy loop that is entirely automatic—deployment becomes the natural end of every change, not a separate coordinated task
• PR preview deployments are the highest-value single improvement to a design workflow: every branch gets a live URL, so design review is reviewing the actual output
• Accessibility checks in CI make accessibility a non-negotiable constraint rather than a late-stage audit—violations are caught before they merge
• A mature pipeline has three layers: per-commit checks (fast, ~3min), per-PR checks with preview deployment (~10min), and on-merge production deployment
• Start with one workflow—a build check on every PR—and add one step at a time; the YAML syntax is strict about indentation but the concepts are straightforward