CI/CD for Modern Web Apps: GitHub Actions Workflows That Work

Your CI/CD pipeline can make or break developer productivity. A well-designed pipeline catches bugs before they hit production, automates tedious deployment tasks, and gives your team confidence with every merge. A poorly designed one creates friction, wastes time waiting for builds, and becomes something developers work around rather than with.

After years of refining GitHub Actions workflows for Next.js applications across teams of various sizes, I've identified patterns that consistently work—and antipatterns that consistently frustrate. This guide covers battle-tested workflows that will transform your deployment experience.

Essential Workflows: Lint, Test, Build, Deploy

Every production-grade CI/CD pipeline needs four core workflows that run in sequence, each serving a distinct purpose in your quality assurance process.

The lint workflow catches code style issues and potential bugs before they're even tested. This should run first because it's fast and catches the most obvious problems:

name: Lint
on:
  pull_request:
    branches: [main, develop]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v2
        with:
          version: 8
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm type-check

Notice the --frozen-lockfile flag—this ensures your CI uses exactly the same dependency versions as your local development, preventing "works on my machine" issues caused by floating dependency versions.

The test workflow validates your business logic and catches regressions. Structure it to run unit tests in parallel for speed:

name: Test
on:
  pull_request:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v2
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm test --coverage
      - uses: codecov/codecov-action@v3

Caching Strategies for Faster Builds

Build times compound across your team. If every CI run takes 10 minutes and you merge 20 PRs a day, that's over three hours of waiting daily. Effective caching can reduce this dramatically.

The most impactful cache is your dependency cache. GitHub Actions supports this natively with the setup-node action's cache option, but you can go further with pnpm's content-addressable storage:

- uses: actions/cache@v3
  with:
    path: |
      ~/.pnpm-store
      node_modules
    key: \${{ runner.os }}-pnpm-\${{ hashFiles('**/pnpm-lock.yaml') }}
    restore-keys: |
      \${{ runner.os }}-pnpm-

For Next.js specifically, caching the .next/cache directory provides enormous benefits. This cache includes compiled JavaScript, optimized images, and ISR pages.

For monorepos using Turborepo, leverage remote caching to share build artifacts across all developers and CI runs. This alone can reduce build times by 80% or more for incremental changes.

Preview Deployments for Every PR

Preview deployments transform code review. Instead of pulling branches locally and running the dev server, reviewers can click a link and see the exact changes live. This speeds up feedback loops and catches visual regressions that automated tests miss.

If you're using Vercel, preview deployments are automatic. For other platforms, configure them explicitly with GitHub Actions. The key is automating the comment with the preview URL so reviewers can find it without digging through build logs.

Environment Management: Secrets and Variables

Managing environment-specific configuration in CI/CD requires careful thought. GitHub provides three mechanisms: secrets (encrypted, for sensitive data), variables (unencrypted, for configuration), and environments (for deployment-specific settings).

Structure your environments to match your deployment targets: development, staging, production. Use required reviewers on the production environment to create a manual approval gate.

The concurrency setting with cancel-in-progress: false ensures that production deployments are never interrupted mid-flight, even if a new commit is pushed.

Monitoring Your Pipeline: Metrics That Matter

What gets measured gets improved. Track these metrics to understand your pipeline's health:

Time to first feedback: How long until a developer knows their PR has issues? This should be under 5 minutes for lint and unit tests.

Total pipeline duration: End-to-end time from push to deployed preview. Target 10-15 minutes for complex applications.

Cache hit rate: Monitor how often your caches are being used effectively. A low hit rate indicates cache key issues.

Flaky test rate: Tests that sometimes pass and sometimes fail erode trust in your pipeline. Track and fix these aggressively.

Advanced Patterns

As your pipeline matures, consider matrix builds for testing across multiple Node versions, conditional workflows based on changed files, and parallel job execution for independent checks.

The key is starting with essentials—lint, test, build, deploy—and adding complexity only when you need it. Add caching to improve speed. Implement preview deployments to transform code review. Manage environments carefully. And measure everything so you can improve continuously.

Your future self—and your team—will thank you for investing in pipeline quality now. The compound effect of faster feedback, fewer production incidents, and confident deployments is transformative.