CI/CD 是持续集成（continuous integration）和持续交付（continuous delivery，或持续部署）的简称，指把代码修改从开发人员的电脑送到运行中的网站或应用的步骤自动化。团队不必每次都靠手工构建、检查和发布，而是由流水线（pipeline）对每次修改按相同顺序执行同一套约定好的步骤。
CI 和 CD 分别指什么
- 持续集成（CI）：开发人员经常把修改合并到共用的代码库，每次合并都会自动触发构建和一组检查，例如自动化测试。问题在修改后不久就会暴露，还容易追查。
- 持续交付（CD）：检查通过后，修改会被打包并准备好，可以发布到测试环境或正式环境。最后的发布通常仍由人工批准。
- 持续部署：再往前一步，通过全部检查的修改会自动上线，无需人工批准。并不是每个团队或企业都希望这样做。
“CD”既可以指交付，也可以指部署，所以最好向供应商确认他们指的是哪一种。
典型的流水线做什么
流水线因项目而异，常见步骤有：
- 构建：把源代码转换成可以运行的版本。
- 自动化测试：测试较小的逻辑单元，也测试较完整的流程。每次修改后重复执行之前的检查，就是回归测试的思路。
- 代码和依赖检查：根据项目的设置，应用格式规则，并检查项目所用的库是否存在已知问题。
- 部署到预发布环境：把构建结果放到预发布环境（staging），供进一步审阅。
- 发布到正式环境：经批准后或自动把修改发布到线上系统，最好同时具备回滚的办法。
如果某个步骤失败，流水线会停下来并通知团队，有问题的修改就不会继续往下走。
委托开发软件时为什么要了解它
- 减少手工失误：写成代码的步骤每次都以同样的方式执行，不容易被遗漏。
- 更早得到反馈：有问题的修改在流水线里就会被发现，而不是由客户发现。
- 发布规模更小：频繁的小修改，比一次发布一大批内容更容易审阅，也更容易撤销。
- 留有发布记录：流水线记录会显示哪个版本发到了哪里，以及通过了哪些检查。
CI/CD 做不到的事
- 不能替代好的测试。流水线只会执行已经存在的检查。如果没有测试覆盖预约或支付，流水线通过并不能说明这些功能没有问题。
- 不能替代业务层面的审阅。员工和客户仍需确认软件符合实际工作，例如通过用户验收测试。
- 搭建和维护都需要投入。需要测试、环境、权限，以及负责保持流水线正常运行的人。
- 并非每个项目都同样需要。很少更新的小型网站，用较简单的流程可能就够了。
以下为说明用的示例：一家小公司运营在线预约系统。开发人员修改了时段的选择方式。流水线构建这项修改，运行包括预约流程在内的自动化测试，再部署到预发布环境。员工在预发布环境试用新页面，再由指定人员批准发布到正式系统。如果预约测试失败，这项修改会在到达预发布环境之前停下，开发人员也会收到通知。
可以向开发团队提的问题
- 有没有自动化流水线？它会执行哪些步骤？
- 哪些测试会自动运行？覆盖哪些关键流程？
- 每项修改是否都会经过预发布环境？
- 谁负责批准发布到正式环境？发布时间如何安排？
- 发布后如何回滚？由谁操作？
- 交接后，谁负责维护流水线，并保管其访问密钥和机密信息？
针对关键用户流程的自动化检查，可以作为流水线的一个步骤，也可以在用户收到修改之前，针对预发布版本或候选发布版本运行。想了解 technine.io 的做法，请查看我们的自动化 UI 测试服务。系统上线后，发布、监控和维护通常由托管支持及 SLA覆盖。
常见问题
CI/CD 只适合大型企业吗？
不是。这些做法适用于各种规模的项目，小项目的流水线也可以很简单。不少代码托管和云平台都内置了基本的流水线工具，但仍然需要有人决定运行哪些检查，并持续更新。
用了 CI/CD，网站是不是每天更新很多次？
不一定。CI/CD 让发布有固定的做法，风险也更低。多久发布一次属于业务决定，不少团队按计划好的时间表发布。
CI/CD 等于 DevOps 吗？
不等于。DevOps 是让开发和运维团队相互配合的更广泛的工作方式，CI/CD 是其中一套做法。