为什么要做持续集成
在软件开发过程中， 由于各个模块之间的联系，开发的单个模块不能在试运行环境中运行，所以在验收阶段可能会出现各种错误，集成效率就会因此降低。有了持续集成，每次的修改都可以运行，保证了程序的可执行性，能够及时发现错误。
持续集成需要注意的
- 在持续集成服务器上提交自己新的代码之前，要确保自己的环境运行正常
- 一旦构建失败要及时修复问题
持续集成需要使用的测试
- 单元测试：一般是对一些小单元的行为测试，比如方法，函数等，不需要连接数据库，系统文件，或网络，也不需要部署应用程序，所以一般运行速度非常快。
- 组件测试：用于测试程序中几个组件的行为，同样不需要启动整个程序，但可能需要连接数据库，访问文件系统等，运行时间较长。
- 验收测试：验证应用程序是否满足业务需求所定义的验收条件。一般推荐将整个程序运行于类生产环境中，运行时间长。
测试的作用：确认所做的修改不会破坏现有的功能。
构建可视化
可以使用外部设备将构建信号显示出来，比如灯管信号，语音信号等。
我们在把代码提交到共享的代码库之前一定要在本地的版本库运行所有的提交测试，确认新增代码的正确性。
持续集成需要团队严格遵循纪律，在提交代码后构建失败要及时修复，或者让回滚到上一个可用版本，保证构建能够持续正常运行，在构建失败时，要停止提交代码，解决问题后再开始提交新的代码。
小步频繁提交需要快速运行提交测试，一般我们对提交测试的运行时间加以限制，如果超时就让构建失败，为可频繁提交作出保障。这种实践需要强壮的测试。
本地化版本控制系统
在实际情况中，我们可能会遇到因为网络或者其他问题无法连接到版本控制服务的情况，这个时候就有必要在本地建立一套持续集成系统了。
解决本地化版本控制系统的存取问题：
- 将应用程序分为多个组件
- 使用分布式或者支持多主库拓扑结构的版本控制系统
分布式版本控制系统（Distributed Version Control System）
目前常用的有Git，Mercurial
DVCS可以本地提交，不受网络的影响
其核心特性是，每个仓库都包括项目的完整历史，方便代码共享
小结
在写代码时要注意代码的规范性，养成良好的习惯。比如命名习惯（目前采用驼峰命名法），代码的格式等。
在使用持续集成实践时，团队的每个人都要严格遵循提交的原则，这样才能保证构建能够保持运行状态。这对于每个成员来说，高度的责任感是合作的基础。
分布式版本控制系统，在不连接主服务器的情况下，也可以提交代码，适合通信状态不佳的情况。实际上在做持续集成时如果能够改善通信状况的话，一般不建议换到分布式版本控制系统（备选方案）。
在使用DVCS比如我们常用的GitHub时，要尽量避免使用分支。
疑问
- 什么时候有必要进行测试驱动开发？
- DVCS的使用中为每个代码库都在持续集成服务器上建立一个构建，分支代码库数量很多时对于服务器有什么影响？
