CI/CD 实战：从 Git Push 到页面上线

在前端工程化的闭环中，CI/CD（持续集成与持续部署） 是将代码从“开发者机器”推向“用户屏幕”的自动化传送带。作为全栈工程师，构建一套丝滑的流水线不仅能解放双手，更能消除人为发布导致的生产事故。

本篇我们将以 GitHub Actions 为例，实战拆解一条工业级的自动化流水线。

---

一、 核心概念：CI 与 CD 的分工

• CI（Continuous Integration - 持续集成）： 侧重于验证。每当你提交代码，流水线会自动运行安装、检查、测试。目标是确保新代码不会破坏原有功能。
• CD（Continuous Delivery/Deployment - 持续交付/部署）： 侧重于发布。通过验证后，自动执行构建并推送到服务器或 CDN。目标是实现“一键上线”甚至“无人值守上线”。

---

二、 实战：构建 GitHub Actions 流水线

在项目根目录创建 .github/workflows/deploy.yml，这就是我们的自动化剧本。

1. 触发时机：精准控制

我们希望只有在 main 分支的代码变更时才触发部署，而其他分支只跑测试。

YAML

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

2. Job 1：质量检查（CI 阶段）

这是流水线的“安检口”。

• 环境初始化： 使用 ubuntu-latest 镜像，配置 Node.js 环境。
• 依赖缓存（重点）： 利用 actions/cache 缓存 node_modules，能让构建速度提升 50% 以上。
• 执行任务： pnpm install -> pnpm lint -> pnpm test。

3. Job 2：自动部署（CD 阶段）

只有 Job 1 成功后才会运行。

• 构建产物： 运行 pnpm build。

• 多环境分发： * 独立站/静态页： 部署至 Vercel, Netlify 或 GitHub Pages。

  • 私有服务器： 通过 appleboy/ssh-action 使用 SSH 远程登录服务器并拉取镜像或直接 rsync 产物。

---

三、 高阶进阶：全栈视角的流水线优化

1. 自动化版本与 CHANGELOG

利用 semantic-release 或 changesets，流水线可以根据 Commit 信息自动判定版本号（Major/Minor/Patch），生成发行说明并自动打 Tag。

2. 安全性保障：Secrets 管理

永远不要在 YAML 文件中写死 API Key 或服务器密码。

• 使用 GitHub 的 Actions Secrets 存储敏感信息。
• 流水线执行时通过 env 注入环境变量。

3. 钉钉/飞书通知

部署成功或失败后，通过 Webhook 向群聊发送通知，实时掌握生产环境动态。

---

四、 性能优化的底层哲学：构建缓存

在 CI 环境中，最耗时的通常是下载依赖和重复编译。

• 锁文件校验： 基于 pnpm-lock.yaml 的 Hash 值作为缓存 Key。如果依赖没变，直接秒级恢复 node_modules。
• 持久化计算缓存： 如果你使用 Nx 或 Turbo，流水线可以只编译那些受改动影响的子包（Affected Build），极大地节省算力。

---

💡 给前端开发者的硬核贴士

• 失败优先原则： 如果单元测试覆盖率下降或 Lint 不通过，必须强制中断流水线。不要带着隐患上线。
• 金丝雀发布： 对于核心业务，考虑先部署到预发环境（Staging），手动验证后再推送到生产环境。

---

结语

一条完美的 CI/CD 流水线，是工程化成熟度的终极体现。它让部署从一种“充满仪式感且提心吊胆的操作”变成了一个“静默且可靠的后台进程”。