持续集成

即在多人协作开发的情况下，每天多次将dev代码合并到master。
好处：

可以快速发现并定位错误。因为每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。这一点对于团队协作开发软件非常重要。

目的：让project快速增量迭代，同时保证项目的质量。
实现手段：核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。所以从另一角度解读的话，可以认识持续集成是一种测试驱动的软件开发方法。自动化测试在持续集成中扮演了reviewer的角色。累活都交给了自动化测试。

补充一些测试的概念：

单元测试（unit test）
也叫模块测试，指对软件中的最小可测试单元进行检查和验证，小到每个变量、每个函数、每个类。
集成测试
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行整体测试。简单说：集成测试是把各个模块合并在一起，作为整体进行功能测试，发现错误，并输出。软件开发的生命周期中，集成是必然的，具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件模块合并过程中不出任何问题的情况。且集成测试需要花费的时间远远超过单元测试，但进行集成测试是极有必要的。
端对端测试（黑盒测试）
不管内部的实现，测试应用的效果，看是否满足预期。

流程

commit 开发者从一个分支，向master提交commit
单元测试 代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。
通过单元测试合并到master
对master进行build（所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源等等。）
全面测试 单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。测试的是否严格，直接决定了软件的质量。
部署将这个版本的所有文件打包（ tar filename.tar * ）存档，发到生产服务器。生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。
回滚一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
image.png