CI-CD持续集成是什么

CI/CD 是现代开发的标准流程，通俗说是"代码从提交到上线的自动化流水线"。 这篇讲清是什么、价值。

CI/CD是什么

CI/CD 是两个概念的组合，分别对应代码从提交到上线过程中的两个阶段：

• CI（Continuous Integration，持续集成）：开发者把代码提交到代码仓库后，系统自动拉取代码、构建、运行测试。如果构建或测试失败，立刻通知开发者修复。CI 的核心是"频繁集成、及早发现问题"。
• CD（Continuous Deployment/Delivery，持续部署/交付）：CI 测试通过后，系统自动把代码部署到测试环境、预发布环境，甚至生产环境。CD 的核心是"测试通过即可部署"，减少人工干预。

合起来，CI/CD 形成一条完整的流水线：

代码提交 → 自动构建 → 自动测试 → 自动部署

开发者只需要提交代码，剩下的构建、测试、部署都由流水线自动完成。这就是为什么它被称为"自动化流水线"。

为什么用CI/CD

1. 提效

• 自动化构建测试部署：原来开发者手动跑构建、手动跑测试、手动传文件部署，每一步都要人盯着。CI/CD 把这些全自动串联起来，开发者提交代码后可以做别的事。
• 减少手动操作：手动操作不仅慢，还容易出错（漏跑测试、传错文件、配错环境）。自动化把这些风险都消除掉。

2. 减少错误

• 自动化避免人为错误：人是会犯错的，特别是重复性操作。CI/CD 每次执行同样的流程，不会因为疲劳或疏忽出错。
• 测试保障质量：CI 流水线里跑自动化测试，每次代码变更都会触发测试，问题在合并前就被发现，而不是等到上线后用户投诉。

3. 频繁发布

• 小步快跑，频繁发布：有了 CI/CD，可以做到每天甚至每次提交都发布，而不是攒一个月的改动一次发布。
• 降低每次发布风险：每次发布只包含少量改动，出问题容易定位、容易回滚；攒一大波改动发布，出问题排查范围很大。

4. 规范可追溯

• 流程规范：发布流程固化在流水线里，不会因为某个人请假或离职而中断。
• 每次发布有记录：谁在什么时候提交了什么代码、触发了哪次发布、发布了什么内容，全部有记录，方便追溯和审计。

CI/CD vs 手动发布

手动发布的典型场景是：开发者本地构建、手动上传到服务器、手动重启服务。这种方式的问题在于——慢（每一步都要人操作）、易错（容易漏步骤或配错）、不可重复（换个人来做可能就不一样了）。CI/CD 把这些问题都解决了。

CI/CD的价值（对老板）

从老板或甲方的角度看，CI/CD 的价值不在于"用了什么先进工具"，而在于它反映了团队的规范性和交付能力：

• 发布快：提效，新功能能更快上线，响应市场需求更敏捷。
• 质量稳：自动化测试保障质量，减少线上事故。
• 风险低：小步发布，出问题影响范围小、回滚快。
• 规范：用 CI/CD 的团队通常整体开发流程也更规范，是专业性的一种体现。

别踩的坑

• 手动构建部署：不用 CI/CD，每次发布都要开发者手动操作，慢、易错、不可重复。
• 没自动化测试：上了 CD 但 CI 阶段没有自动化测试，相当于"自动发布未经测试的代码"，风险更大。
• 攒大波发布：因为没有 CI/CD，每次发布成本高，就攒一大波一起发，结果一出问题排查范围巨大、回滚困难。
• 不要求团队用：作为甲方不要求团队用 CI/CD，团队图省事继续手动发布，规范性无从谈起。

成本参考

CI/CD 是流程和工具，开源工具成本低：

主流的 CI/CD 工具（GitLab CI、GitHub Actions、Jenkins）都是开源或免费的，主要成本是初期搭建和配置，属于一次性投入。对项目本身不增加成本，反而提升效率、降低事故。

怎么确认团队规范

作为甲方或管理者，可以从这几点确认团队是否规范使用 CI/CD：

1. 团队用 CI/CD 自动化发布：代码合并后自动触发流水线，自动构建测试部署，而不是手动操作。
2. 有自动化测试：CI 阶段跑自动化测试，测试不通过不允许合并和部署。
3. 发布有流程记录：每次发布都能查到触发的代码变更、测试结果、部署时间。
4. 频繁小步发布：发布频率高、每次发布内容少，而不是攒一大波一起发。

广州市汉诺雷斯（HNREIS）用CI/CD规范发布，自动化测试保障质量。把你的项目需求告诉我们，我们规范交付。