前言

在招聘 JD 中经常看到“熟悉 CI/CD”与“了解 GitHub Actions”。CI/CD 本质上是一套工程做法：代码提交后借助脚本自动完成检查、测试、建立和部署，极大减少手动操作导致的遗漏或错误。对很多人最大的痛点是：本地跑通的脚本，在 CI 环境里往往会因为环境差异或依赖问题而失败。

GitHub Actions 是 GitHub 提供的实现工具。只需在仓库中放一份 YAML 配置，GitHub 在云端按配置自动输入命令。正因为它与代码同版本管理，使用最省事。

一、CI/CD 在解决什么问题

一次正常发布要经过哪些环节

以前端项目为例，从改代码到使用者能打开新版本通常需要：

1. 本地跑测试、lint。确认改动没有明显问题
2. git push把 commit 推到 GitHub 远程仓库
3. 与主分支合并
4. 建立，例如 npm run build 生成 dist/
5. 把产物部署到服务器或 Vercel、GitHub Pages 等网站

这些步骤每次发布都要做一遍。CI/CD 的主要目标是：把可脚本化的步骤固定下来在指定时机自动执行。

CI这方面，Continuous Integration

集成：

• 将改动合并进仓库整体后立即验证能否建立并。

持续：

• 每次推送或合并时即刻触发验证，而不是积累多天多 PR 再一次性合并。

痛点： 开发者常遇到“本地通过、CI 报错”，原因多为 Node/依赖版本不一致或缺少程序级工具。

CI 通常做的工作：

• 安装依赖（npm ci)
• 静态检查
• 单元/集成测试（npm test)
• 建立（npm run build...) – 确认能成功打包。

说到CD。Continuous Delivery / Deployment

CIs 验证完后CD 则负责将建立产物送至使用者可访问的环境，如测试服、预发或生产。

• CDE : 自动化准备但上生产仍需人工审批；常用于保留人工门禁的场景。
• CDE : 一旦 CI 成功，即刻无人工干预直接部署；适用于对回滚容忍度高的团队。

痛点： 许多团队因担心上线风险而设置手工审批，但这往往导致上线延迟和人为失误。明确区分交付与部署流程，可帮助你决定是否保留人工卡点。

工具关系说明 & 为什么选 GitHub Actions？

• CICD 是目标；GitHub Actions / GitLab CI / Jenkins 等是实现手段。
• "仓库在 GitHub 上" 时用 GitHub Actions 最省事：配置文件随代码一起 version‑control，无需额外服务安装与维护。

二、代码提交后谁在什么地方输入命令？

Runner 是谁？不过，

Runner 是 GitHub 为每个 Job 分配的一台临时虚拟机。托管 Runner 通常是临时 VM，上面执行你写好的 npm test 等命令。可以把它想象成 “用完就还”的 Linux 环境，专门用来验证此次提交是否正常。

steps这方面。- uses: actions/checkout@v6

这不是你在本地 `git pull`，而是 **Runner 从远程仓库克隆当前触发 Commit** 的文件。整个流程大致如下：

1. 1. GitHub 给该 Job 分配空闲 Runner；
2. 2. actions/checkout 从 GitHub 下载对应 Commit 的文件至 Runner 磁盘；
3. 3. 随后 `npm ci` 、 `npm test` 等均在此 Runner 上针对这份代码执行；

Runner 用完即销毁——关键注意点！

• - 换个角度你不能期望上一次 CI 装好的依赖留给下一次运行。除非显式使用缓存机制，否则每个 Job 都会重新安装依赖；
• - 你不能把 Runner 当作生产服务器使用 —— 使用者访问的网站必须部署到 Vercel、自己的云主机等长期在线环境中。

三、GitHub Actions 怎么知道要跑什么？**配置文件放哪儿，** text .github/ └─ workflows/ └─ ci.yml 如果不推送到远程，这份文件永远不会生效。

---

**完整链路从 push 到命令输出** text 1️⃣ 本机 git push → 2️⃣ GitHub 接收更新并触发 “push” event → 3️⃣ Actions 根据 .github/workflows/*.yml 判断是否匹配 on: 条件 4️⃣ 匹配则创建一次 Workflow Run，为每个 Job 分配独立 Runner 5️⃣ 每个 Job 内按 steps 顺序执行：checkout → 安装 Node → npm ci → npm test …6️⃣ 成功/失败状态写回给 PR 或 Commit 页面 7️⃣ Runner 被释放

---

**YAML 三层结构概览**

BLOOM	BLOOM
Workflow
Job
Step

关键字这方面，* **on:** 指定何种事件触发运行；* **jobs:** 定义工作块列表；怎么说呢，* **steps:** 每个工作块里具体执行什么；默认情况下多个 Job 并行执行。如需顺序控制，可以用 `needs:` 指明前置 Job；话说回来，若前置失败，则后置默认被跳过。

---

uses 与 run 两种写法

写法	用途	示例
run:	在 Runner shell 下直接输入命令	``yaml - run: npm ci - run: npm test
uses:	调用已有 Action，例如官方 checkout 或自定义 action	``yaml - uses: actions/checkout@v6 - uses: actions/setup-node@v6

项目自己的编译、测试脚本用 ``；通用操作如拉取代码、安装运行时则推荐 ``。

---

从示例来看，Vue + Vite 项目 CI 配置

yaml 至于name，CI on的观点是，push: branches: pull_request: branches: 至于jobs，test: runs-on: ubuntu-latest

steps:
# 拉取当前 commit 的源码
- name: Checkout code
再看uses，actions/checkout@v6
# 安装 Node 并缓存依赖，以加速后续建立
- name : Set up Node
uses : actions/setup-node@v6
with :
node-version : ''
cache : 'npm'
# 安装依赖。并保持 lock 文件一致性
- name : Install dependencies
run : npm ci
# 静态检查
- name : Lint
run : npm run lint
# 单元测试
- name : Test
run : npm test
# 建立产物
- name : Build
run : npm run build

配置说明

• on 与 branches – 每当向 main 推送或开启 PR 时触发。
• runs-on – 使用 GitHub 托管的 Ubuntu 虚拟机。
• actions/checkout@v6 – 把当前 Commit 的源码拉取至 Runner。说起来，
• actions/setup-node@v6 + node-version + cache – 明确 Node 主版本。并启用 NPM 缓存，其实，
• npm ci – 按 lock 文件精准复现生产环境依赖。
• 若未生成 lock 文件，将导致 步骤失败——请先生成 package-lock.json 或改为 npm install。

查看结果

Push 后打开仓库的 “Actions” 标签页，每条记录展开即可看到完整终端输出。Commit 与 PR 页面也会显示各 Step 是否通过。

---

四、更进一步：提高功能

缓存提高速度

如果每次都重新下载 node_modules，会浪费大量时间：

yaml - uses: actions/setup-node@v6 with : node-version : '' cache : 'npm'

Cache hit 时会显示 。

拆分 Jobs 控制顺序

例如先跑 lint，再跑 tests：

yaml jobs : lint : runs-on : ubuntu-latest steps : …- run : npm ci && npm run lint

test : needs : lint runs-on : ubuntu-latest steps : …- run : npm ci && npm test

如果 lint 失败，则下游 Job 默认被跳过。

添加 Deploy Job

yaml deploy : needs : test runs-on : ubuntu-latest if : github.ref == 'refs/heads/main' && github.event_name == 'push' steps : ... # 在此接入 Vercel/GitHub Pages/SCP 等

---

五、Secrets 与分支保护

Secrets 管理

API Token、SSH 私钥等敏感信息写入 Repository Secrets：

yaml env这方面，VERCEL_TOKEN  :${ { secrets.VERCEL_TOKEN }}

值在日志中会被掩码显示。

从配置方法来看，

Repository Settings ➜ Secrets and variables ➜ Actions ➜ New repository secret

分支保护策略

在 Settings ➜ Branches 给 main 加规则。如：

• 必须通过所有指定的 CI 检查才允许合并；不过，
• 强制 PR 合并方式；这样，当 CI 未通过时无法合并，提高质量门禁。

---

六、参考资料

• - https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions
• - https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions
• - https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#job-level-keywords

This revised layout keeps all original information but organizes it into clear sections with highlighted pain points and actionable insights for newcomers aiming to start using CI/CD and GitHub Actions effectively.