方法

CI/CD

持续集成 / 持续交付

每一次代码变更都自动构建、测试、准备发布。一些团队再进一步，每一次通过的构建都自动上生产。

最近审阅: 审阅人Kevin Riedl wiki ↗

Continuous Integration 意味着团队的代码在每次变更时都合并并构建，而不是在最后做一次大爆炸式集成。Continuous Delivery 意味着每一次成功的构建都距离生产只差按一次按钮。Continuous Deployment 把按钮也去掉：每个通过测试的构建自动发布。这三者是一架成熟度阶梯，不是同义词。

多数团队 CI 做得好，CD 时好时坏，Continuous Deployment 几乎从不做。瓶颈很少在工具上。它在于对测试套件的信任，以及团队在一小时内修好一个坏构建的意愿。没有这两样，自动化部署只是让 Bug 跑得更快。

藏在流水线速度里的杠杆，举个实际例子：一支团队有一条要跑 25 分钟的 CI 流水线。工程师不再在本地跑它，把变更攒成批、靠希望去合并，以躲开那段等待。Bug 在合并之间累积，团队当初采用 CI 想躲开的那种集成之痛悄悄回来了。把那条流水线为内循环砍到 10 分钟以内，工程师就会不停地跑它、在上下文还新鲜时抓住问题，整个 Agile 循环随之收紧。流水线速度不是锦上添花；它是每个工程师每一天的力量倍增器。

诚实的取舍与常见错误：创始人要「完整的 CI/CD」，好像它是一个开关，而其实 CI 主要是工具、CD 主要是纪律。CI 你一个下午就能有。真正的 Continuous Delivery 需要一套团队信得过、敢在后面发布的测试套件（靠一种 TDD 习惯）、一条以分钟计的回滚路径，以及一个在部署点着什么时能响应的待命人。Wavect 每个项目从第一天起就配好 CI，作为一段清醒 SDLC 的一部分；是否配置 CD 取决于这个项目是否有让它安全的覆盖率和运维纪律。我们会告诉你你拥有的是哪一种。

// FAQ

常见问题

CI 是「每次提交都自动构建并测试」。CD（Continuous Delivery）是「每次通过的构建都自动准备成可发布形态，按按钮才上线」。Continuous Deployment 把那次按按钮也省掉，每个通过的构建自动上生产。多数团队 CI 做得好，CD 时好时坏，Continuous Deployment 几乎没人做。
因为 CD 需要一种大多数团队并不具备的、对测试套件的信任。没有好的覆盖率和快速回滚，自动化部署只是让 Bug 跑得更快。CI 主要是工具，CD 主要是纪律。
内循环（构建、单测、Lint）控制在 10 分钟以内，含集成测试控制在 30 分钟以内。比这更慢，工程师就不在本地跑它、开始靠希望合并了。流水线速度是一项杠杆指标：值得在它上面投入。