持续交付三——持续集成

持续集成要求每当有人提交代码时，就对整个应用进行构建并对其执行全面的自动化测试集合。并且假如构建或者测试失败，开发团队就要立刻停下手中的工作去修复。
持续集成的目标是让正在开发的软件一直处于可使用状态。

实现持续集成

• 准备工作——包括版本控制，自动化构建，团队共识
  大家以同一个准则使用版本控制与自动化构建快速发现问题并且在出现问题之后立即修复，缩短解决问题的时间。
• 一个基本的持续集成系统
  使用持续集成的工具并进行配置而且所有人都去使用。在准备提交新代码之前 ，要保证目前是否有构建在运行，并且加入自己更新的代码是否能够构建成功，如果能成功，在把自己本地的代码提交到版本控制工具中。
  这个过程应该就是一直保持当前的软件可用，让版本控制工具上的代码移植处于正确状态。

持续集成的前提条件

• 频繁提交
• 创建全面的自动化测试套件
• 保持较短的测试和构建过程
• 管理开发工作区
  前三点都在之前的章节里面介绍过，对于管理开发工作区，要管理开发环境，第三方依赖的配置管理，里面提到的冒烟测试昨天看书的时候还不知道是什么，胡老师的讲解——冒烟测试来源于硬件测试，就跟买电器先试试插上会不会冒烟。用最少和最有效的方法验证系统是工作正常的。仅仅是为了测试冒不冒烟烟，用某种方法证明主要路径能够跑通。

使用持续集成软件

• 基本操作
• 铃声和口哨
  使用持续集成软件进行直运行并将运行结果反馈给我们，也可以通过设置一些提醒的方式来告诉我们构建的状态是否成功。

实践

• 构建失败后不要提交新的代码
• 提交前在本地运行所有的提交测试，或者让持续集成服务器完成
• 提交测试之后再继续工作
• 回家之前，构建状态必须是成功
• 时刻准备着回滚到前一个版本
• 在回滚之前规定一个修复时间
• 不要将失败的测试注释掉
• 为自己导致的问题负责
• 测试驱动开发
  既然我们要确保正在开发的软件一直处于一个可用的状态，那么我们就要保证每一次变更后的代码都要能够通过构建测试，不提交错误的代码，并且在提交之前保证提交上去的代码能够与上一个版本的代码能够构建成功，这种情况下才可以提交代码。如果构建的状态不成功，最好在一定时间内修复好，时刻准备着回滚到上一个正确的版本，也不要把错误的代码留给其他人。通过测试驱动开发，在开发新的功能或者修复缺陷时，先写测试，该测试是该功能的可执行规范。这些测试不仅驱动了应用程序的设计，而且能够作为回归测试调用（回归测试：引入了变化之后，测试是否会导致已有功能异常。胡老师举得例子：比如不小心摔了一跤，总要爬起来看看自己是否完好无损）。
  对于极限编程以及什么情况下应该让构建失败也是为了能够让每一个版本的代码都能够构建成功。

分布式团队

使用版本控制工具并且大家按照一定的规则持续集成对分布式团队开发项目是很有利的，但是由于一些技术问题，使用替代方法也是可以解决的，但是解决方案也不是特别理想。

分布式版本控制系统

使用分布式版本控制系统的团队应该按照持续集成的实践里面讲到的提交代码的方式来提交，保证每一个版本的代码都是正确的再进行开发。使用分支的话如果忘记合并到主分支或者一段时间后再去合并，到时候就更容易产生构建失败或者错误，要修复的代价也会比当时直接提交到主分支上的代价高。对于这一部分还不是特别了解。

存在的问题

明白冒烟测试和回归测试的一些概念，但是还是不清楚应该怎么用。
对于组件的测试和验收的测试，之前也没有写过，接下来再去查一些相关的知识。
对于书中讲到的持续集成的工具也没有使用过。
还有分布式管理系统的分支应该怎么用。