CI-CD 是什么
一句话总结
CI-CD 是代码变更自动走「集成测试 → 构建 → 部署」管线的工程实践，减少手动操作和发布事故。
🤔 为什么会有它 / 解决了什么问题
手动部署经常漏步骤、配错环境、忘记测试。CI-CD 把从提交代码到上线的流程编码为自动化管道，每次 push 都走同一套流程，可重复、可追溯。
🔍 具体运作逻辑
开发者推送代码到 Git 仓库 → Webhook 触发 CI 服务器拉代码、跑测试、构建产物 → 产物推送到 Registry → CD 系统自动部署到目标环境。
更硬核的技术细节（点击展开）
CI-CD 管线的每个阶段通常运行在独立的 Docker 容器中，保证环境一致性。CF Pages 的自动部署是典型的 CI-CD：git push → Cloudflare 自动构建静态站点 → 推送到全球边缘网络。
🧭 什么情况下会用到 / 什么场景会遇到它
- Frappe Press 的 Bench 构建（Docker 镜像 build → Registry → Deploy）
- CF Pages 接入 Git 仓库后自动部署静态站点
🛠️ 怎么上手 / 在哪操作
GitHub Actions、GitLab CI 或 Cloudflare Pages 自带 CI：在仓库根目录放配置文件，定义构建和部署步骤。
⚖️ 副作用 / 代价 / 取舍
- 调试失败的 CI 管道常常比手动部署更花时间，尤其构建环境与本地不一致时
- 管线配置本身也需要测试和维护——“CI 的 CI”
🕰️ 来历
- 谁提出/创造的：持续集成概念由 Grady Booch 在 1991 年提出，持续部署由 ThoughtWorks 的 Jez Humble 在《Continuous Delivery》（2010）中系统化
- 什么时候出现的：CI 工具 Jenkins 2005 年发布；GitHub Actions 2019 年上线，让 CI-CD 配置像写 YAML 一样简单
🔗 关联 / 经常一起出现的概念
- Deploy Candidate：Press 中 Build 成功的镜像产物，CI-CD 管线的输出
- Cloudflare Pages：我们用的 CD 工具——git push 后自动构建并部署到 CF 边缘
⚠️ 注意事项 / 常见误区
CI-CD 不是「装了工具就自动好」——管线的每一步（测试覆盖率、构建缓存策略、回滚机制）都要持续投入。配置放 Git 仓库本身是好事也意味着每次改配置都要走一遍 PR 流程。
📎 记忆锚点
“CI-CD = 把「应该但经常忘的事」交给机器每天每次重复做。Press 的 Bench build + deploy 就是典型 CD 管道。”
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-13 | 首次创建 | - |