在软件工程实践中，需要将开发完成的最终产品交付给用户（或发布给测试部门），就需要我们将源代码编译为可执行文件。将各个分别开发的模块集合为一个完整的系统，这个过程成为系统集成，我们用一个系统来描述这个集成过程。
集成系统：输入指定的软件资产，输出根据软件资产生产出的软件产品以及其他副产品的系统。
对于一般系统而言（以VC开发为例），软件的生产过程包括：源码获取，源码检查，源码编译，测试，部署。经历以上几个过程之后得到一个可用的系统。
故一般而言集成系统通常会按照顺序经历以下几个模块组成：
1. 版本检查：用于获取代码和其他必要的文件。
2. 源码检查：对于源代码的静态分析，检查可能存在的错误。
3. 源码编译：通过编译器和连接器编译源文件，生产可执行文件或库。
4. 测试：通过对编译出来的文件进行一定测试，并获得测试结果。
5. 部署：若测试通过则文件可以作为最终得到的产物用于交付。
在实践过程中软件的最终集成会存在各种各样的问题而导致集成失败，需要大量的修改和测试，而得到最终可以的交付的产品。故每次版本发布时的加班不可避免，而交付的延期也时常发生，软件的质量不可保证。为了解决这些问题或者说减少修复这些问题所需要付出的成本，我们尽量让这些问题提早发生（问题越早发生修复的代价越小）。因此我们可以以一定频率对工程的更改进行集成，若集成失败则尽早修复，以保证能够得到可交付的产品，这样的实践称为持续集成。
我们可以将系统集成的工作交由项目经理负责，让项目经理定期集成系统并发布版本，我们称之为人肉集成系统：
1. 版本检查：SVN或者Git工具能够check out出代码的工具都可以。
2. 源码检查：使用beyondcompare等工具对比原有版本，通过codereview的方式用肉眼对代码进行检查，好坏全凭项目经理的经验。
3. 源码编译：VS工程的生成功能，将源代码编译，连接，生成可执行文件或库。
4. 测试：跑完单元测试，对文件的功能进行测试，或检查是否功能完备或者bug是否已经得到修复。
5. 部署：将生成的文件打包交付。
人肉集成系统处理了集成最大的问题，通过项目经理以一定频率反复执行以上过程保证交付。但是项目经理的精力完全被消耗在这个重复劳动的过程中，而且质量保证完全取决于项目经理的经验和能力，并且不能量化结果对于决策的支持有限。以上几个模块会被按顺序重复执行，若有一定的工具可以自动完成以上模块的各个功能则可以将项目经理从繁复的重复劳动中解脱出来，大大的节省项目成本。故我们需要构建一个自动持续集成系统来取代人肉集成系统，感谢开源工具让我们能够使用自动化的工具完成以上各个模块的功能，并通过CI工具反复执行，自动集成系统同样包含一下模块：
1. 版本检查：SVN或者Git工具能够check out出代码的工具都可以。
2. 源码检查：使用cpplint检查代码规范，使用cppcheck静态检查代码缺陷，使用cppncss或SourceMonitor分析代码复杂度。
3. 源码编译：通过命令行调用VS工程的生成功能，将源代码编译，连接，生成可执行文件或库。
4. 测试：执行gtest和gmock进行单元测试和回归测试，通过opencppcoverage来检查代码覆盖率。
5. 部署：将生成的文件打包交付。