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

集成是软件开发的最后阶段，即将分支合并起来，使软件能够运行起来。而持续集成就指的是在开发过程中随时做集成，小步前进，这样也不会使得集成问题“滚”成大球，难以解决。

实现持续集成

首先，我们得知道怎样去实现持续集成，即了解持续集成的准备工作和要求。
1、版本控制，与上一章中讲述的一样，我们需要把项目的所有内容都纳入到版本控制库中。
2、自动化构建，做到在命令行中实现构建。
3、团队共识。
4、持续集成系统。

持续集成的前提条件

1、频繁提交。要求每天至少提交一次代码，这样小步前进，不会使合并工作量变大，也使得回滚便捷有效。
2、全面的自动化测试套件。包括单元测、组件测试和验收测试，由小到大范围测试，保证引入的代码不会破坏现有功能。
3、保持较短的构建和测试过程。控制编译和测试的时间，让测试执行的更快，减少构建时间。
4、管理开发工作区，这里即上一章中提到的配置管理。

使用持续集成软件

持续集成软件包括两部分，第一是一个一直运行的进程，定期进行简单的工作流程；第二是呈现这个流程运行结果，能了解到测试和构建的状态结果。

实践

这里作者向我们讲述了几种持续集成中应注意的问题：
1、构建失败后不要提交代码，不要让问题“滚雪球”，务必做到及时解决问题。
2、提交前在本地运行提交测试，确保没有问题以及和其他人不冲突。
3、等提交测试成功后再继续工作。
4、回家之前，构建必须处于成功状态。这里有点意思，也与自己的原本想法有出入，书中讲到下班前提交代码构建失败，如果是我，我会选择加班修复，而书中建议为将提交回滚，下次上班再解决。因为修复也可能失败，而且放置不管更是不允许的，最好的方法就是给自己的构建留有足够时间，确保离开前构建处于成功状态。
5、确保随时能回滚到上一个版本，以及对自己导致的问题负责，尤其不要把失败的代码注释掉，注释一时爽，构建葬火场...

推荐的实践

这里作者提出了几个开发中的建议，包括违背架构原则及运行测试运行变慢时，选择让构建失败，虽然过程对团队可能是“摧残”的，但是结果一定是最好的，这也提醒了我们在以后工作中也要严格要求自身。


持续集成对分布式团队所带来的益处也是非常大，同时，通过书中讲述的，还了解到了针对持续集成，我们现在所使用的github中存在的问题，github的分支管理使代码变得灵活，然而也存在问题,这样也会干扰主线模型，导致合并出现问题。

总结

在这一章中，学习到了持续集成的概念及如何去实现持续集成，作者很详细的从多个方面分析并列出合理的解决方案，了解到了使用持续集成的优点，持续集成也应该是我们以后争取尽早达到的目标。