持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天，点击查看活动详情
持续集成前的产品迭代过程
举个例子，当前的研发team中有这样几个人，Alice，Bob，Charlie都是开发的同学，David同学负责测试工作。
通常的产品的迭代会是如下的步骤，如下图所示：
- 开发工程师们在各自的feature分支上开发新的功能代码。
- 在feature开发完成之后，开发Leader协调合入计划，大家将自己的feature分支合入到Release分支。Release分支是当前迭代的主分支，最后的版本会在此分支上产生。
- Feature合入到Release完成之后，测试工程师开始确定测试计划，规划并执行测试。
- 通过测试的Release最终发布。
以上是一个普通的产品迭代过程，现在我们来看这里面有哪些问题：
- 开发的同学很苦逼，在紧张的开发过程过后，在合入Release阶段开始遭受新的摧残，各种意料之外的编译问题，功能问题，合入冲突轮番上阵，解决完头发已经掉了一半。
- 产品的Leader很不开心，Release Deadline近在眼前，各种意料之外的问题使得这个release目标几乎不可能达到，临近发布了问题还这么多，产品质量堪忧。
- 测试的同学鸭梨很大。 产品开发完成之后合并分支就搞了好几天，问题暴雷不断，转测日期一再推后，测试时间不断被压缩，如果在短时间内完成测试是个很大问题。而且鸭梨不均的情况很明显，在开发阶段只能进行用例设计和需求沟通，一直在等着可测版本进入测试。
所以，基于以上的问题，我们再看持续集成是怎样的，是不是解决了这些问题：
包含持续集成的产品迭代过程
当产品迭代引入持续集成后，有几个重点需要关注：
关注点
- 持续和集成。尽早并持续地完成“集成（intergration）”的动作，而不是使用合入计划。
- 尽早发现产品的严重问题，避免到后期给产品发布带来压力。
如下图所示：
-
开发人员在完成一个feature开发过程中的milestone时，即可开始将feature分支合入到release分支。
-
测试的环节，可以包含多种过程：
- 产品的回归功能自动化测试（ptest）
- 开发自测，对功能的实现验证
- 测试开始提测（提前测试），完善用例和开始自动化测试工作。
此时再看引入持续集成后，是否解决了我们上面提到的问题：
1、合入release的冲突和重大缺陷可以避免，功能开发完成后即可进入到测试阶段。
2、产品的质量情况在开发过程中即一目了然，转测和发布日期更可控。
3、测试人员的工作更加均衡有效，测试工作不再紧靠在release deadline之前。
