Why & Why not那么为什么需要 CI 呢？相比于传统的先开发，再测试，后上线的模式有哪些好处呢？在团队使用 CI 这段时间中，得出了以下主要两个好处：
及时发现错误。CI 并不能消除错误，但 CI 将发现错误的时机尽可能地提前，所以也更加节省时间来改正错误。当开发者提交代码至代码仓库时，其对于代码的熟悉程度是最高的。如果这个时候尽可能的纠正一些错误或不当，开发者将能很快注意到并将错误改正，避免了由于时间或者团队中其他人对于代码的修改所导致的问题，提升了开发效率。
自动化。市面上的 CI 平台都给了开发者比较高的自由度，能够执行脚本或命令。因此很多自动化的操作都可以制定好，来自动化地执行，节省开发者的时间。
如果这两个显而易见的好处还不足以说服，可以参考文末 Reference 中 EKATERINA NOVOSELTSEVA 的文章。那么 CI 会不会也存在什么难处呢？
GitHub with Travis CI
GitHub，人尽皆知，是全球最大的代码托管平台，但 GitHub 本身并没有集成 CI。但有很多 CI 平台为 GitHub 定制 CI 环境，其中使用较多的便是 Travis CI。在 GitHub 仓库中看到有 .travis.yml 文件便意味着该仓库集成了 Travis CI。对于开源的项目，可以选择它就不用开发者再单独配置服务器来运作 CI，当然速度可能会慢些。之前在写个人的一个命令行工具时，便尝试使用了 Travis CI，而且可以非常容易的将 CI 状态和代码覆盖率的 Budge 标示在项目文档中。
GitLab with CI
相比于上述的几个平台，GitLab 真正把代码托管和 CI 结合了起来，并在最新 Release 版中加入了 Auto DevOps，似乎是更加先进的 CI。团队内部目前使用的便是 GitLab EE，后续就将以 GitLab 为主，讲讲其中配合 GitLab Runner 来规范化开发流程。
