对于持续交付的考虑

from: http://qing.weibo.com/1407988324/53ec3264330007e6.html

无论发布按照小时、天还是周计数,只要每个sprint产出都有release也是持续交付。mainline里面的代码随时可发布,是指随时可以进入发布流程,这个流程包含自动化测试(单元测试、模块测试、继承测试)和手动测试以及部署。

追求mainline里面的代码可随时发布,要求有充分的自动话测试流程。根据项目大小、复杂程度以及自动化测试的情况,这一发布流程耗时可能是小时、天或者周计。

基于branch的开发是一种正常的开发活动,无论是feature branch还是hot fix。只是要注意merge的评率,避免等待merge的代码过多。因此要注意任务、user story的拆分。 

缩短发布时间要求缩短开发测试时间。小的项目或者已经比较成熟的项目(比如只是维护小升级),可以缩短sprint。有些项目则不能缩短sprint,毕竟sprint里面包含了分析设计和测试的时间。这里拆分user story是关键。在具体到一个sprint的时候要拆分任务,小幅修改或者先设计框框再逐渐填内容以实现小步release。

总之,两次发布之间的间隔越短,changes对系统的影响就越小,测试的压力就越小。拆分user story可以缩短sprint,拆分任务和好的设计可以缩短release时间,减少测试压力。自动化测试很重要。

对于refactor,也可以采用拆分任务的方法,refactor也是有步骤的,可逐步实现。每次refator一部分。

最后,持续交付的目的是能够快速更新,响应用户,并不是将发布权交给business决定,那只是看上去的效果,代码如果有问题,business再怎么样也发布不出去。

 
原文地址:https://www.cnblogs.com/franklin/p/2280750.html