《持续交付》——第三章--持续集成

在软件开发过程中，由于各个模块之间的联系，开发的单个模块不能在试运行环境中运行，所以在验收阶段可能会出现各种错误，集成效率就会因此降低。有了持续集成，每次的修改都可以运行，保证了程序的可执行性，能够及时发现错误。

测试的作用：确认所做的修改不会破坏现有的功能。

可以使用外部设备将构建信号显示出来，比如灯管信号，语音信号等。

我们在把代码提交到共享的代码库之前一定要在本地的版本库运行所有的提交测试，确认新增代码的正确性。

持续集成需要团队严格遵循纪律，在提交代码后构建失败要及时修复，或者让回滚到上一个可用版本，保证构建能够持续正常运行，在构建失败时，要停止提交代码，解决问题后再开始提交新的代码。

小步频繁提交需要快速运行提交测试，一般我们对提交测试的运行时间加以限制，如果超时就让构建失败，为可频繁提交作出保障。这种实践需要强壮的测试。

在实际情况中，我们可能会遇到因为网络或者其他问题无法连接到版本控制服务的情况，这个时候就有必要在本地建立一套持续集成系统了。
解决本地化版本控制系统的存取问题：

目前常用的有Git，Mercurial
DVCS可以本地提交，不受网络的影响
其核心特性是，每个仓库都包括项目的完整历史，方便代码共享

在写代码时要注意代码的规范性，养成良好的习惯。比如命名习惯（目前采用驼峰命名法），代码的格式等。
在使用持续集成实践时，团队的每个人都要严格遵循提交的原则，这样才能保证构建能够保持运行状态。这对于每个成员来说，高度的责任感是合作的基础。
分布式版本控制系统，在不连接主服务器的情况下，也可以提交代码，适合通信状态不佳的情况。实际上在做持续集成时如果能够改善通信状况的话，一般不建议换到分布式版本控制系统（备选方案）。
在使用DVCS比如我们常用的GitHub时，要尽量避免使用分支。