在软件工程实践中，需要将开发完成的最终产品交付给用户（或发布给测试部门），就需要我们将源代码编译为可执行文件。将各个分别开发的模块集合为一个完整的系统，这个过程成为系统集成，我们用一个系统来描述这个集成过程。
集成系统：输入指定的软件资产，输出根据软件资产生产出的软件产品以及其他副产品的系统。
对于一般系统而言（以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. 部署：将生成的文件打包交付。
我们使用jenkins作为CI工具，来完成持续集成的各个模块的管理（jenkins的插件能够帮助我们完成以上工作）。
我们在windows7下构建CI服务器，并使用vs2013作为开发环境来完成一个CITest的持续构建活动。接下来使用CITest的编码来模拟日常的开发工作，并从开发人员与项目经理两个角色参与CI系统的搭建。
1. 使用VS2013新建C++工程CITest，并编写一些代码用于测试。
2. 选择代码仓库，Git不是很熟悉一直用subversion，而且资源有限并不想多架设一条svn的服务器而且作为一个test项目代码需要的空间有限，故选用免费的代码托管服务器（taocode），以此svn地址作为上传下载代码的地址，上传CITest工程代码和工程文件。
3. 将静态代码检查工具集成到VS上
推荐google的c++代码规范 （注释风格参考doxygen的格式），使用代码风格检查工具cpplint：
先安装python2.7，下载cpplint.py到目录C:\cpplint，打开vs，工具菜单，选择外部工具将cpplint添加进去，再通过工具.选项.键盘为cpplint分配快捷键
添加代码段保持注释的风格一致，工具代码段管理器，导入代码段定义文件，并在工具.选项.文本编辑器.c++.制表符中见制表符替换为两个空格：
安装完成后运行一次，修复报告的所有问题
再将静态分析工具cppcheck集成到vs上，与cpplint一样为cppcheck添加快捷键：
修改代码以使得通过检验。
使用SourceMonitor测量代码复杂度：
4. 用命令行编译VS工程
基于后期使用jenkins持续集成系统的考虑，这里使用ant，调用devenv命令来编译解决方案。
先安装ant，并配置环境变量，再配置devenv的环境变量，编写bulid.xml放到工程的根目录下，并作为项目资产加入svn，在工程目录下运行ant。
5. 为工程添加单元测试
感谢google提供的两个工具，使得完成单元测试的工作变得简单。在实际开发中需要采用测试驱动开发的实践：
我们下载gtest和gmock两个工具，然后根据被测试代码所在工程的运行库选项并编译他们：
创建一个空的工程用于单元测试，并将上一步生存的lib文件和头文件拷贝到单元测试工程目录下：
在工程文件中增加一个用于单元测试的配置，定义输出为lib文件，在单元测试的工程中包含他们，编写测试代码：
测试代码的编写参考网上的资料：主要有玩转google开元c++单元测试系统和GMockForDummies，cheat sheet，cookbook这几份资料。
在ant的bulid.xml文件中添加target，实现自动化
6.安装并使用opencppcoverage开查看测试代码的覆盖率
以上在开发端的设置全部完成，或者还有其他的需要补充的工具可以视具体项目再决定如何补充和添加。
接下来使用jenkins来搭建CI服务器，在客户端完成私有构建后将代码提交到svn上，CI服务器将执行以上所有的构建和测试动作，并将结果反馈给相关人员，构建失败应当是优先级最高的处理事件（在错误的基础上做的再多也是白费功夫）。
1.安装Jenkins和需要的插件
2.创建一个自由风格的项目，填写基本信息
2.定义构建动作并解析构建结果（使用以上与客户端相同的工具，并将构建结果解析出来）
cpplint（此处lint.py遍历当前目录，检查所有.h和.cpp文件，并将结果输出到xml文件中）：
cppcheck：
SourceMonitor：
Ant（需要根目录下的build.xml文件支持）
opencppcoverage（在build.xml文件中去掉执行单元测试的部分内容，在此同时输出两个文件）
最后在配置邮件通知：
至此CI系统配置完成，返回上一级，点击立即构建（上边每一步每添加一个功能构建一次，直到这些功能配置完成）：
