敏捷软件开发实践-ReleaseProcess/ReleasePlan

介绍：

创新互联主营张店网站建设的网络公司,主营网站建设方案,app开发定制,张店h5成都小程序开发搭建,张店网站营销推广欢迎张店等地区企业咨询

因为我们的开发周期是迭代进行的，以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"中：

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

现在我们用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天才拿出一个合理的方案，这里毫无保留的共享下，具体结构如下：

这张图中，×××的状态条代表了开发团队，绿色的状态条代表了测试团队，在每个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会让项目弄的一团糟。