如何进行持续集成？
在进行持续集成实践前，应当正确的选择并配置持续集成服务器。列出了所有的持续集成服务器 ，其中比较成熟的持续集成服务器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作为开源产品，以其对于各种SCM以及构建工具的广泛支持而被许多开发团队所接受。
在一个典型的持续集成过程中：
－ 开发者每次将代码提交到SVN之前，必须运行本地测试： 尽量保证不会破坏持续集成服务器的构建过程。
－ 开发者每天进行多次提交：小步前进会大大减少服务器构建失败的概率，并且使得修复失败构建的时间大大缩短。
－ 持续集成在一台服务器上不断运行：保证在稳定的环境中进行测试。
－ 所有的测试必须全部通过：保证软件现有的功能不被破坏并且没有引入新的缺陷
－ 生成构建结果(War, Jar，exe等) ： 用以开展下一步的工作，譬如QA的探索测试等。
－ 生成报表 ：帮助管理人员评估开发状态。
－ 修复失败的构建 ： 失败的构建意味着软件现有的功能已经被破坏或者有新的缺陷被引入，修复的速度越慢使修复难度越高，并带来更大的损失。
持续集成坏味道：
－ 持续编译
［现象］某些团队仅仅使用持续集成服务进行编译并生成最终的构建结果。
［影响］持续集成无法给开发人员，管理人员带来有价值的快速反馈。
［原因］开发团队可能缺乏编写易于测试的代码的能力，或者不了解现代软件开发中测试的流程和作用
［解决方案］测试优先，单元测试，功能测试，验收测试
－ 构建长时间失败
［现象］ 没有开发者愿意修复失败的构建，持续集成工具上的构建已经持续失败很长时间。
［影响］ 开发者忽视持续集成服务器发布的结果，修复构建的成本和难度升高，开发团队，管理团队无法得到快速反馈，丧失安全感
[原因] 长时间不进行代码更新并一次提交太多代码，构建时间太长导致开发者缺乏耐心运行本地构建、任务过于复杂
[解决方案] 简单设计，小步前进，缩短构建时间
－ 过多失败构建
［现象］持续集成服务器上有很多失败的构建、开发者常常在持续集成服务器上强制运行构建
［影响］团队其它成员无法提交代码，开发效率下降。
[原因] 通常这是项目中存在随机失败测试的信号，譬如，某些测试存在顺序依赖，时间敏感或者没有在测试结束时正确回收资源。这样，虽然开发者本地构建通过，却无法保证在持续集成服务器上成功构建，开发者会不断的尝试在服务器端重新运行构建试图得到一个成功的构建
［解决方案］ 简单设计，编写正确的单元测试
－ 构建时间过长
［现象］本地构建时间超过10分钟
［影响］生产率严重下降
[原因] 可能是由于重复测试引起，由于测试之间没有很好的隔离，导致同一逻辑在对不同对象进行测试时被重复测试、或者是软件规模大，测试多引起
[解决方案] 分布式构建
－ 构建结果不醒目
［现象］ 没有开发者意识到持续集成服务器上的构建已经失败了
［影响］ 构建长时间失败，修复难度变大
[原因] 没有将构建结果明显的发布出来
[解决方案] 安装构建指示灯，或者在构建失败的时候播放音乐。
拥抱持续集成：
为了享受持续集成带来的诸多好处，开发者需要做到：
－ 小步前进，频繁提交
－ 不要提交本地测试失败的代码
－ 编写可以自动进行的测试
－ 编写可以快速运行的测试
－ 如果构建失败，第一时间进行修复
－ 如果构建失败，拒绝更新代码