本系列文章包含：
持续集成（Continuous Integration），以自动化方式实现“从开发阶段性完毕到部署上线之前”这一阶段的工作。当然也可做到简单部署，复杂的要涉及到持续部署阶段。
下面为摘抄各网站的定义：
百度：持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
搜狗：持续集成是指开发阶段，对项目进行持续性自动化编译、测试，以达到控制代码质量的手段。持续集成是一种软件开发实践。
在敏捷开发过程中，持续集成的使用尤为频繁。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。
持续集成的核心价值在于：
1) 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；
2) 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能；
3) 持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。
业界普遍认同的持续集成的原则包括：
1) 需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 IBM Rational ClearCase、CVS、Subversion 等；
2) 开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；
3) 需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；
4) 必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。
说了不少废话，现在开始上干货。
一个完整的构建系统必须包括：
1) 一个自动构建过程，包括自动编译、分发、部署和测试等。
2) 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
3) 一个持续集成服务器。
其中1)自动构建和2)代码存储库，都是有相应的软件配合，开发人员需要的学习成本不高，复杂在各模块的相互配合，这一期间可能需要大量时间去调试。一旦调试完毕，对于之后工作效率的提升是成倍的。
自动构建，做.Net开发的同仁相信大多数都会使用VS，而Visual Studio用MSBuild构建.NET项目。MSBuild所需的仅仅是一个脚本，在脚本中指定要执行的target；项目中的.csproj和.vbproj 文件都是MSBuild脚本。当编写好MSBuild脚本后，只需要一条简单的命令，即可实现代码的编译与测试工作。下面将介绍MSBuild的基本语法。
虽然MSBuild实现了自动编译与测试，但是在调用MSBuild时，我们还是通过输入命令进行调用的，这里掺杂了人工干预的成分，因此要将这部分工作剔除。
目前主流的版本管理有传统的SVN、分布式的Git和Mercurail各有利弊，自行选择。
【资料中使用的是Mercurail，我以前没用过，也懒得配环境学习了；我使用的是Git，why？因为有GitHub（可以在线托管，嘿嘿；当然，如果是局域网环境，可以自己搭建版本管理服务器，Git、SVN、Mercurail随你喜欢）。如果你知道其他好用的在线版本管理工具，请一定要留言给我，让我学习下。】
Jenkins是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。下面将介绍 Jenkins 的安装与配置。
Jenkins配置好了，以后每次变更代码，提交新的版本后，Jenkins都会自行执行单元测试，在其设置页面，还可以根据需要将运行报告发送给指定的人，方便跟踪。
整个的部署实际上无需花费过多时间，而且如果已搭建好持续集成服务器，那么每次新增的只是一个Job以及它的配置。麻烦的就是在刚学习时，会出现各种难以预料的问题，有时会是一个简单的拼写错误，有时可能是版本等问题导致你所看到的资料所描述的，与你实际搭建的环境所需要的不一致，因此就需要自己学会排查、解决这些问题。总的来说，持续集成是个好东西。
原文：http://www.cnblogs.com/Leo_wl/p/4728745.html