1. 开发&运维
Develop - Operations
2. 核心概念
- 【集成】是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；
- 【部署】是代码尽快向可运行的开发/测试节交付，以便尽早测试；
- 【交付】是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题。
如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。
而所谓的“持续”，就是说每完成一个完整的部分，就向下个环节交付，发现问题可以马上调整。问题不会放大到其他部分和后面的环节。
这种做法的核心思想在于：既然事实上难以做到事先完全了解完整的、正确的需求，那么就干脆一小块一小块的做，并且加快交付的速度和频率，使得交付物尽早在下个环节得到验证。早发现问题早返工。
以装修厨房为例：
- 其中一项是铺地砖，边角地砖要切割大小。如果一次全切割完再铺上去，发现尺寸有误的话浪费和返工时间就大了，不如切一块铺一块。这就是“持续集成”。
- 装修厨房有很多部分，每个部分都有检测手段，如地砖铺完了要测试漏水与否，线路铺完了要通电测试电路通顺，水管装好了也要测试冷水热水。如果全部装完了再测，出现问题可能会互相影响，比如电路不行可能要把地砖给挖开…… 那么每完成一部分就测试，这是“持续部署”。
- 全部装修完了，你去验收，发现地砖颜色不合意，水池太小，灶台位置不对，返工吗？所以不如每完成一部分，你就去用一下（试用验收），这就是“持续交付”。
【补充】从敏捷思想中提出的这三个观点，还强调一件事：通过技术手段自动化这三个工作；加快交付速度。
2.1 持续集成 CI
在软件工程中，持续集成（Continuous Integration）是指将所有开发者工作副本每天多次合并到主干的做法。
2.2 持续交付 CD
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付（Continuous Delivery）可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
2.3 持续部署 CD
对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署（Continuous Deployment）。作为持续交付（自动将生产就绪型构建版本发布到代码存储库）的延伸，持续部署可以自动将应用部署到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。
3. 持续集成组成要素
1. 版本管理系统
项目的源代码需要托管到适合的版本管理系统中，一般我们使用 Git 作为版本控制库，版本管理软件可以使用 GitHub、GitLab、Stash 等。
2. 构建脚本&工具
每个项目都需要有构建脚本来实现对整个项目的自动化构建。比如 Java 的项目就可以使用 Gradle 作为构建工具。通过构建工具实现将编译、静态扫描、运行测试、样式检查、打包、发布等活动串起来，可以通过命令行自动执行脚本。
3. CI 服务器
CI 服务器可以检测项目中的代码变动，并及时的通过构建机器运行构建脚本，并将集成结果通过某种方式反馈给团队成员。
4. 应用场景
5. 工作流
5.1 传统的工作流
5.2 常见的工作流
6. 效率工具对比
即「代码的零库存管理」，是精益生产的精髓。
- 代码越早 push 出去，用户能越早用到，快就是商业价值；
- 用户越早用到就越早反馈，团队越早得到反馈，好坏都是有价值的输入；
- 用户不反馈，说明我们做了用户不想要的东西（通过用例跟踪）或者 marketing 没做好，还能帮助产品市场人员调整策略；
- 代码库存越是积压，就越得不到生产检验，积压越多，代码间交叉感染的概率越大，下个 release 的复杂度和风险越高；
- 代码库存越多，workflow 的包袱越重，管理成本越大，说敏捷就越可笑。