本文是个人总结摘记，部分文字摘自其他大神博文等，如有雷同，未列参考文献，请见谅；
定义
- CI，持续集成。它通过自动化来提供有效的反馈机制以及高效的部署，大大降低代了码集成和项目交付的风险。在敏捷开发中，它是一个项目开始前必须搭建起来的基础设施。当代的软件开发项目中，几乎没有项目是只有一个人在开发的。超过一个人就形成了团队，每个人同时并行开发不同模块的功能，这就涉及到代码的集成，所以代码集成是几乎所有开发团队都要面临的问题（一个人的开发项目不在本文范畴中）。
形式
- 持续集成跟团队开发人员独立开发没有冲突，相反，借助一些工具（ Jenkins , GoCD(ThougthWorks 开发) , Travis CI ），它能快速的对我们开发人员提交到代码库的代码作出反馈。开发人员每天都在代码库提交代码，版本控制工具（比如 Git ）在提交前必须更新代码库最新的代码（解决冲突，代码合并，应用更改），然后将代码提交到代码库中。
- 开发人员对自己编写的代码添加足够的测试覆盖率。这是基本，基本最无敌：一来验证代码的正确性，二来防止被误更改。
- 每个人提交代码到代码库之前在自己的机器上保证单元测试都能通过，很耗时集成测试和 E2E 测试可以更多的交给 CI 去跑。
- 借助一些 CI 工具（见上文）, 将代码集成的结果反馈展示在团队所有人都能看到的 Dashboard 上，一定要大家都可以看到。
- CI 定期检查代码库的更新，只要有更新，就要运行所有的测试。这里有个权衡：不耗时的单元测试每次全部运行，集成测试也要频繁的运行，耗时的 E2E 测试可以稍微执行少一点（比如设置夜间执行）。我们这个项目，是 每次检查到更新就会运行所有的测试（单元测试 + 集成测试 6 分钟，E2E 测试 30 分钟）
- CI 如果没有通过，所有人都应该停止向代码库中提交代码，直到 CI 被修复，所以如果 CI 挂了，能够及时通知相关开发人员，要第一时间修复。
- 所有测试通过之后，CI 负责自动化部署到不同的环境（Test，开发团队测试环境；Staging，客户 ShowCase 环境；UAT 和 Production，用户验收测试环境和生产环境，通常开发团队没有权限），并正常启动所有的服务。
好处
- 减少重复的过程。CI 通过自动化，将一些需要重复执行的操作（代码审查、编译、测试、构建、部署）自动化管理起来，大大减少了重复的过程，节省了大量的时间。
- 降低风险。开发过程中，每天进行多次集成，并且添加了足够相应的测试，每次集成 CI 都会快速检查代码中的缺陷并提供及时的反馈，降低了未知的风险。
- 可视化。CI 提供了大量真实且最新的数据，能够让我们关注当前集成的趋势（例如构建时间、构建失败比例、测试覆盖率等），有利于有效决策。
- 增强团队的信心。每次构建的结果都是公开透明的，所有人清楚地知道自己的每次提交改动对软件所造成的影响。
- 随时随地可以生成可部署的软件（CD）。对于客户来说，可以部署的软件产品是最实际的资产，而 CI 让我们可以在任何时间发布可以部署的软件。
