第六篇：《CI/CD 流水线：从前端构建到自动化部署》

代码提交只是起点，让代码安全、快速地交付到用户手中才是终点。CI/CD（持续集成/持续部署）流水线是现代前端工程化的"最后一公里"------它将代码从"提交"到"上线"的整个流程自动化、标准化。一个设计良好的前端 CI/CD 流水线，能够让团队从"手动打包上传"的繁琐中解放出来，将发布周期从"天"压缩到"分钟"。本文从前端 CI/CD 的典型阶段出发，深入讲解构建缓存优化、多环境配置管理、部署策略（CDN/SPA/SSR），并通过 GitHub Actions 和 GitLab CI 的完整示例，帮你建立一套可落地的前端自动化交付体系。

一、前端 CI/CD 流水线的典型阶段

一条完整的前端 CI/CD 流水线通常包含以下核心阶段。对于大多数前端团队来说，GitHub Actions 或 GitLab CI 提供了灵活性与简洁性的最佳平衡。

一个完善的 CI/CD 流水线需要设置多重质量门禁（Quality Gates）：Lint 检查、格式检查、测试、类型检查等。常见的执行策略包括：依赖缓存加速安装、并行执行检查任务、快速失败在首个错误处停止、以及清晰的报告反馈。

二、构建缓存优化

前端构建中最耗时的环节往往是依赖安装（npm install）和构建过程。合理的缓存策略可以将流水线执行时间缩短 50% 以上。

2.1 依赖缓存

核心原则：package-lock.json / pnpm-lock.yaml 不变时，依赖无需重新下载。

GitHub Actions 依赖缓存示例：

yaml 复制代码

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup pnpm
        uses: pnpm/action-setup@v3
        with:
          version: 8

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'

      - name: Install dependencies
        run: pnpm install --frozen-lockfile

      - name: Lint
        run: pnpm lint

      - name: Type check
        run: pnpm type-check

      - name: Test
        run: pnpm test

      - name: Build
        run: pnpm build

⚠️ 关键提示：使用 --frozen-lockfile（npm）或 --frozen-lockfile（pnpm）确保依赖版本与锁文件完全一致，避免因版本漂移导致的"本地能跑、CI 挂掉"问题。

2.2 构建产物缓存

对于 Monorepo 项目，增量构建是提升效率的关键------只构建发生变更的部分，而非每次都全量构建。Turborepo 通过远程缓存（Remote Cache）实现跨机器共享构建结果，团队成员之间、CI 与本地之间可以复用构建产物。

三、环境配置管理

前端应用通常需要部署到多个环境（dev、staging、production），每个环境的 API 地址、功能开关、监控 ID 各不相同。

3.1 环境变量的分层策略

Vite 环境变量示例（.env.production）：

bash 复制代码

VITE_API_BASE_URL=https://api.example.com
VITE_SENTRY_DSN=https://xxx@sentry.io/xxx
VITE_ENABLE_FEATURE_X=false

3.2 多环境构建策略

推荐做法：一次构建，多环境部署------在 CI 中构建一次产物，然后通过不同的环境变量注入部署到不同环境。

yaml 复制代码

# 构建阶段：只构建一次
- name: Build
  run: pnpm build

# 部署阶段：根据环境注入不同配置
- name: Deploy to staging
  run: |
    # 将 staging 环境的 .env 文件复制到构建产物目录
    cp .env.staging dist/.env
    # 部署到 staging 服务器

- name: Deploy to production
  if: github.ref == 'refs/heads/main'
  run: |
    cp .env.production dist/.env
    # 部署到生产服务器

四、部署策略

不同类型的应用需要不同的部署策略。

4.1 静态站点（SPA / 静态 HTML）

SPA 的部署本质上是将静态文件（HTML、JS、CSS、图片）上传到 CDN 或对象存储。

部署流程：

构建生成 dist/ 目录

上传到 CDN（如 AWS S3 + CloudFront、阿里云 OSS + CDN）

配置路由回退（SPA 的 index.html fallback）

GitHub Actions + S3 部署示例：

yaml 复制代码

- name: Deploy to S3
  uses: jakejarvis/s3-sync-action@master
  with:
    args: --acl public-read --follow-symlinks --delete
  env:
    AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    SOURCE_DIR: 'dist'

缓存策略：

HTML 文件：不缓存或短缓存（Cache-Control: no-cache）

JS/CSS 文件：长期缓存（使用 $contenthash$ 命名）

4.2 SSR 应用（Next.js / Nuxt）

SSR 应用运行在 Node.js 服务器上，需要容器化部署。

部署流程：

构建 SSR 应用（next build）

构建 Docker 镜像

推送到镜像仓库

部署到 Kubernetes 或云服务（Vercel、Netlify）

Dockerfile 示例（Next.js）：

dockerfile

FROM node:20-alpine AS builder

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

RUN npm run build

FROM node:20-alpine AS runner

WORKDIR /app

COPY --from=builder /app/.next ./.next

COPY --from=builder /app/public ./public

COPY --from=builder /app/package.json ./package.json

COPY --from=builder /app/node_modules ./node_modules

EXPOSE 3000

CMD $"npm", "start"$

五、回滚策略

六、完整的 GitHub Actions 前端 CI/CD 流水线

yaml 复制代码

# .github/workflows/deploy.yml
name: Deploy Frontend

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'

jobs:
  # ===== Job 1: 质量检查（并行） =====
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm run test

  # ===== Job 2: 构建（依赖质量检查） =====
  build:
    runs-on: ubuntu-latest
    needs: quality
    if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/develop'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  # ===== Job 3: 部署到 Staging（develop 分支自动部署） =====
  deploy-staging:
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/develop'
    environment: staging
    steps:
      - name: Download build artifacts
        uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist
      - name: Deploy to staging
        run: |
          # 部署到 staging 服务器的命令
          echo "Deploying to staging..."

  # ===== Job 4: 部署到 Production（main 分支，需审批） =====
  deploy-production:
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/main'
    environment:
      name: production
      url: https://example.com
    steps:
      - name: Download build artifacts
        uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist
      - name: Deploy to production
        run: |
          echo "Deploying to production..."

七、小结

前端 CI/CD 流水线典型阶段：Lint → Test → Build → Deploy，每个阶段设置质量门禁。

构建缓存优化：依赖缓存（npm ci + 缓存配置）可将安装时间缩短 50% 以上；Monorepo 项目使用增量构建只构建变更部分。

多环境配置：推荐"一次构建，多环境部署"策略，通过环境变量注入不同配置。

部署策略：静态站点（CDN 上传 + 路由回退）、SSR 应用（容器化部署）、蓝绿部署和金丝雀发布。

回滚策略：根据部署方式选择对应的回滚方案，核心原则是"快速、可验证"。