因此当你在开发每个小功能时, 你会不断进行以下事情:
1. 从主干 check out 程序代码到分支
2. 开发团队在分支进行开发
3. 小功能开发完后, 将分支程序, merge 回主干
可是通常这样在第四步时, 就会遇到一堆错误. 这是因为小功能还没确认是否正确, 就和整个系统和起来测试, 将导致问题多多. 如果有很多小功能要放进来时, 这种情况就会更恶化.
因此有些团队可能会这样做:
3. 开发完毕在分支进行测试
4. 在分支测试通过, 将分支程序, merge 回主干
5. 在主干再进行测试
所以下一步你会在这样改进:
4. 把主干的程序 merge 到分支
5. 把 merge 完后的分支程序进行测试
6. 将 merge 完后的分支程序, 再 merge 回主干
7. 在主干再进行测试
因此你先确认小功能是否运作正常; 然后将主干的程序合并到分支后, 再确认是否正确; 最后合并到主干后, 在做一次确认是否都正常.
看起来到目前为止, 应该考虑的很周到.
有些人说没问题, 我们会把测试自动化搞好, 这是小事. 于是他们就开始处理测试自动化的问题, 接着你又会发现到:
要能自动产生 build, 否则每次手动要花多时间
测试环境要自动准备好, 没有干净的环境, 测试结果可能会有影响
每个小功能整合到主干后, 有可能之后出问题, 要重新回上个版本, 这个事情若是手动做, 也是件崩溃的事情
……
所以再做下去, 你会发现整件事情没有你想象的单纯, 若是没有落实 continuous integration 或是 continuous delivery, 你永远没有机会达到 agile 所说的, 每个 iteration 持续交付价值给客户. 你所有的, 将会是至少落后一个 iteration 的交付. 因为在 agile 中, 每个 iteration 测试和开发要花的代价不同, 测试的代价是随着 iteration 的进行, 逐渐高升.
david: 老板, agile 不是只是去上上 scrum 课就可以的.
经理: 测试自动化我早就知道了, 所以 agile 根本没有什么好学的啦
david: …
最新内容请见作者的github页：http://qaseven.github.io/