CI/CD 技能指南 / A CI/CD Skills Guide
本文档记录了关于 CI/CD 高级使用技巧的讨论，包含跳过部署、Commit 规范等
目录
一、跳过部署的"逃生舱"
跳过 CI/CD 的关键字
| 关键字 | 平台支持 |
|---|---|
[skip ci] | Vercel, GitHub Actions, GitLab CI |
[ci skip] | 大多数 CI 平台 |
no-check | 某些平台 |
skip-checks: true | 某些平台 |
使用方法
git commit -m "docs: update readme [skip ci]"Vercel 特有方式
| 关键字 | 说明 |
|---|---|
[vercel skip ci] | 仅跳过 Vercel |
[skip vercel] | 仅跳过 Vercel |
二、Vercel 部署分级
环境对比
| 环境 | 触发条件 | 访问地址 | 价值 |
|---|---|---|---|
| Preview (预览版) | Push 到非 main 分支或 PR | project-git-dev-username.vercel.app | 可测试，不影响线上 |
| Production (正式版) | 合并到 main 分支 | 主域名 | 线上生产环境 |
三、Commit & CI/CD 高级技巧
1. 约定式提交 (Conventional Commits)
格式：<type>(<scope>): <description>
| Type | 说明 | 示例 |
|---|---|---|
| feat | 新功能 | feat: add login jwt logic |
| fix | 修 Bug | fix: resolve memory leak in backend |
| docs | 文档 | docs: update api documentation |
| style | 格式化 | style: format code with prettier |
优势：
- 自动生成 Changelog
- 决定小版本/大版本升级
2. 自动化触发过滤 (Paths Filter)
on:
push:
paths:
- 'backend/**' # 只有 backend 文件夹变动才触发3. 部署保护栅栏
npm run test # 测试不通过则不部署4. 原子化回滚
| 平台 | 回滚方式 |
|---|---|
| Vercel | Dashboard 点击旧 Deployment → Promote to Production |
| Docker | 拉取旧镜像运行即可 |
四、CI/CD 操控总结
| 需求 | 技巧 |
|---|---|
| 想省事 | 用 [skip ci] |
| 想稳健 | 用 Preview URL 测试，没问题再 Merge 到 main |
| 想专业 | 规范 Commit 信息 + paths 过滤避免无效构建 |
完整对话记录
用户提问：对了，我们能否讨论一下CICD的使用，就是我已经体会到vercel的CICD了，就是我push到main分支会产生production是吧？？然后push到dev分支或者其他分支就没有，好像只是产生预览对吧。然后就是我不想每次push都redeploy是不是可以在commit信息里面添加ski-CICD还是啥啊？？这好像是一种commit技巧？？还有哪些技巧啊我们都可以详细说说
AI回答：你的观察非常敏锐。Vercel 的这种机制其实是 GitOps 的核心：代码即触发器。
既然你已经对 Vercel 的默认行为（Production vs Preview）有了实感，咱们就深度拆解一下 CI/CD 的"控制术"，包括你提到的 Commit 技巧以及更多高级玩法。
一、 跳过部署的"逃生舱"
有时候你只是改了个文档（README）或者修了个注释，确实没必要让 Vercel 或 GitHub Actions 浪费资源去跑一次部署。
1. [skip ci] 技巧
绝大多数 CI/CD 平台（包括 Vercel, GitHub Actions, GitLab CI）都支持在 Commit Message 中识别特定关键字来跳过构建。
常用关键字：
- [skip ci]
- [ci skip]
- no-check (某些平台支持)
- skip-checks: true
如何使用：
git commit -m "docs: update readme [skip ci]"Vercel 特有方式： 如果你想针对 Vercel 专门跳过，可以在 Commit 信息里包含 [vercel skip ci] 或 [skip vercel]。
二、 Vercel 的部署分级（Production vs Preview）
你提到的"预览"和"正式版"是 CI/CD 里的 环境隔离 概念。
1. Preview (预览版)
- 触发条件： 除了 main 分支以外的所有 Push，或者 Pull Request (PR)。
- 价值： 它会给你一个唯一的 URL（例如 project-git-dev-username.vercel.app）。你可以把这个链接发给前端看，或者自己点点看有没有 Bug，而不影响线上运行的正式版。
2. Production (正式版)
- 触发条件： 通常只有合并（Merge）到 main 分支。
- 价值： 自动绑定到你的主域名。
三、 更多 Commit & CI/CD 高级技巧
既然你追求"工程化"，这里有几个能让你的 Workflow 看起来像大厂资深架构师的技巧：
1. 约定式提交 (Conventional Commits)
不要只写 update 或者 fix。采用这种格式：<type>(<scope>): <description>。
- feat: add login jwt logic (新功能)
- fix: resolve memory leak in backend (修 Bug)
- docs: update api documentation (文档)
- style: format code with prettier (仅格式化，不改逻辑)
为什么这对 CI/CD 有用？
- 你可以配置脚本，让 CI 自动根据 Commit 信息生成 Changelog（更新日志），或者决定是进行"小版本升级"还是"大版本升级"。
2. 自动化触发过滤 (Paths Filter) —— 强烈推荐
回到你之前的 Mono-repo 结构。如果你只改了 frontend 的代码，为什么后端也要重新部署？ 在 GitHub Actions 里可以这样写：
on:
push:
paths:
- 'backend/**' # 只有 backend 文件夹变动才触发此工作流3. 部署保护栅栏 (Deployment Protection)
在正式部署到腾讯云之前，你可以在 Actions 里加一环：自动化测试。
npm run test # 如果测试不通过，CI 会直接报错停止，不会把坏的代码推到服务器上4. 这里的"原子化"回滚
如果你发现刚推的代码有问题，不要急着写 fix 然后重新推。
- Vercel： 在 Dashboard 点击之前的任意一个 Deployment，选择 Promote to Production，可以实现秒级回退到旧版本。
- Docker： 也是同样的逻辑，拉取旧的镜像运行即可。
四、 总结：你的 CI/CD 操控感
- 想省事： 用 [skip ci]。
- 想稳健： 充分利用 Preview URL 进行测试，没问题再 Merge 到 main。
- 想专业： 规范你的 Commit 信息，并利用 paths 过滤避免无效构建。
你现在是不是经常遇到"只是想改个 README，结果 Vercel 又在那转圈跑部署"的情况？ 试试下次 commit 的时候加上 [skip ci]，看看 Vercel 的 Dashboard 是不是真的"变安静"了。这会给你一种掌握了自动化权力的快感。