9、如何避免新增story影响已有功能造成质量问题？

　　challenge：没有全面回归，如何保证质量？

　　基于Story的敏捷，要求每个story测试完成都可直接上线，也就是说story从测试中移动到QA sign off后，质量达到上线标准，且须保证不破坏已有功能。

　　如果QA在sign off每个story之前，都对前面的story和已有的功能做全面回归的话，估计很快就会被累死。

　　怎么解决此问题呢？

　　临时解决方案：

　　（1）code frees环节

　　RD在主干上开发（减小大量merge产生的风险），在上线之前，会有一个code frees环节，从主干上拉出一个release branch（简称RB），用于本迭代的上线。

　　根据敏捷的经验，在所有story都移到QA sign off区后，再拉RB，因为RB拉得太早，QA的工作量会double，敏捷周期本不太长，测试和开发在stroy间也是并行的，因此 开发完所有story的时间点和QA测试完所有stroy之间的时间不会很长，因此原则上在所有story都移到QA sign off区后，再拉RB，如果情况特殊，也要等QA大致过一遍stroy后，QA点头后再拉RB。否则RB上提交次数太多，工作量和风险都相对较大，拉RB的意义就不明显了。

　　（2）迭代回归

　　RD继续在主干上开发下一迭代的story，QA在此RB中回归本迭代的内容及可能影响到的原有功能，并测试上线步骤。

　　用迭代回归，而不是每个story完成之后都回归，减少回归工作量，作为临时方案。

　　长远目标：

　　推动RD完成UT、IT，QA完成ST，使自动化测试覆盖已有功能，最终将QA从回归中解放出来。

　　10、上线频繁，如何降低上线的成本？

　　challenge：每次上线都会花时间去测上线步骤，上线频繁，如何降低成本？

　　答案当然是自动化上线。

　　将web和server这种每次上线除配置文件修改，其余操作都一样的上线做成自动化上线。

　　将文件替换这样的上线步骤做成脚本，QA测试脚本，上线执行脚本即可。