敏捷软件开发实践-ReleaseProcess/ReleasePlan-创新互联

介绍:

成都创新互联公司专注于做网站、成都网站建设、网页设计、网站制作、网站开发。公司秉持“客户至上,用心服务”的宗旨,从客户的利益和观点出发,让客户在网络营销中找到自己的驻足之地。尊重和关怀每一位客户,用严谨的态度对待客户,用专业的服务创造价值,成为客户值得信赖的朋友,为客户解除后顾之忧。

因为我们的开发周期是迭代进行的,以Sprint为单位,我们每个Sprint如何去和客户说我们的成果呢,那么我就需要Demo和release一些新功能,或者一些bug fixing。Demo我这里不讨论了, 大体上就是部署都服务器上然后运行下给meeting的所有人看下,我们这里主要讨论和发布(release)有关的话题。

实现方式:

话题1:我们如何让发布者知道我们这个Sprint做的功能?因为就像jdk一样,它的每次大的release和小的release都有一些评注来说明他们这次发布有哪些功能,或者哪些修正,我们一样,我们的做法是:

在每个Sprint的结束日,如果对项目有任何变更(功能改变/修正) ,都会在项目中加一个release note.

具体的做法是:我们采用了maven-site-plugin,然后每次我们都会更新site folder,在site.xml中加一个条目到"Release Notes"中:

敏捷软件开发实践-Release Process/Release Plan

然后我们加一个apt文件,并且在其中加上release notes

敏捷软件开发实践-Release Process/Release Plan

现在我们用mvn site,就可以显示这些我们写入的release notes 了。

话题2:选择合理的release plan

我们何时去release artifact,这是一个很困难的问题。也许有人想简单了,这不就是把版本号升级下,然后build一下不就完事了么?你差的远呢。 因为你要发布一个项目,不是操作那么简单,你必须对于这个项目的质量有很严格的把关,也就是说你要确保它的正确性,所以我们必须先把产品在某些环境上做Regression ,如果Regression没问题,我们还要往更高层的环境上做Regression ,直到几个环境的Regression 都没问题了,我们才可以放心大胆的去Release. 具体说,我们有4套环境,分别是Dev,  DevInt,QA ,Production,我们必须一层层往上走,都没问题了,我们才可以最后的Release并且发布都Production环境中。那么问题来了,因为Release要动代码仓库,而我们的开发是迭代进行的并且是时刻不停的,如果Release团队发布项目时候开发人员又对同一个仓库提交了代码,就会导致代码的不一致性导致发布失败。我们现在也没有严格的code freeze制度,因为这种制度多半是在瀑布模型中的,我们的开发不能停,那么如何选择恰当的Release时间点呢?这就是Release Plan要解决的问题。

这个问题很复杂,当时我应邀去设计Release Plan时候,我足足想了2天才拿出一个合理的方案,这里毫无保留的共享下,具体结构如下:

敏捷软件开发实践-Release Process/Release Plan

这张图中,×××的状态条代表了开发团队,绿色的状态条代表了测试团队,在每个Sprint中,我吧10天分成了N+1到N+10,其中N代表在第N个Sprint,蓝色文字代表开发团队的动作,紫色文字代表测试团队的动作,红色文字代表release的人的动作。

所以从上图不难发现,对于开发团队来说,他们的主要开发日期是从(N+3)到(N+9),一共7天,这七天他们做开发,所以会去碰代码仓库,而对于前2天(N+1),(N+2)和最后一天(N+10),他们都是做一些和代码无关的事情,所以不会去影响到代码仓库。所以我的建议是,让release的人在Dev和DevInt上做release和Regression的时间控制在(N+1)和(N+2),因为这两天代码仓库的稳定性是可以保证的,然后当开发人员从N+3开始提交代码后,releaser做QA和Production环境的release和regression,这样不会影响开发团队提交代码。

风险和经验分享:

其实大的风险是对于开发团队,万一API或者UX Spec不是很明确,或者不稳定,这样他们的开发时间就会推迟,也许不一定从(N+3)开始了,对于这些情况,我的建议是,如果在(N+1)天遇到了这些各种开发的不利因素,那么尽可能在(N+3)之前全部解决,如果能解决,那么最好,如果不能解决,那么scrum master可以砍掉一些story,这样至少可以保证开发团队的按时交付。

还有,就是万一release失败了怎么处理?我的建议是:如果release或者regression失败了,那么代码会返回到开发团队的手里,然后变成一个urgent fix 的活动。如果开发团队足够给力,他们可以在N+1就解决了,那么万事大吉,如果到N+2才解决,那么开发团队就要推迟一天开发,从N+4到N+9,这就需要他们适当提高效率,事实上我们在工作量预估时候也都加了很多buffer时间。如果到N+3了还没解决,那么releaser就停止release,并且宣告N-1迭代的release 失败,然后等2星期再进行新一轮的release. 只有这样,才能保证整个流程的顺畅。

总结:

Release是一个非常重要的步骤,我们必须把好这一关。

(1)Release的过程我们可以用release插件并且加好足够详细的notes方便以后去追踪项目的演化。

(2)设计一个非常行之有效的release plan非常重要,关键立足点是各种角色之间要不交叉,不相互block,没有plan的release会让项目弄的一团糟。


名称栏目:敏捷软件开发实践-ReleaseProcess/ReleasePlan-创新互联
浏览地址:http://scyanting.com/article/djhsed.html