传统意义上,软件发布被认为是工程和商业之间沟通的一种方式。 工程把经过测试的代码交给商业,后者继而把它向市场发布,然后一个周期就完成了。然而,在敏捷中软件发布可以分成内部发布和对外发布两大类。这有助于在工 程和商业之间创建松散的耦合关系。工程创建内部发布,商业可以选择其中之一用于对外发布。
在最近Cutter Consortium 上的一篇文章中(下载代码是RELEASEMYTH),来自BMC 公司的 Israel 就在软件世界中如何区分这“两”种发布的问题,引发了一场有趣的争论。他认为,内部发布和对外发布应该是同一个硬币的两面,
> 提供特定特性和功能的一套代码是一样东西,市场和销售使用这套代码以达到经营目标完全是另外一样东西。这两个活动不仅不同,也没有必要通过 1 比 1 的关系绑定在一起。
他用一个有趣的例子来形象比喻, 一个水池有两个水管,一个是进水管,另外一个是出水管。他把工程比作进水管,商业比作出水管。
> 把这个例子中的进水管想像成工程,出水管想像成商业。工程可以按照自己的步调发布版本,商业可以从发布的版本中自由选择。在此范例中,市场没必要某个版本完成后立刻对外发布,它可能 3 个月后再发布;也可能时间更晚,与另外一个版本同时发布;可能基于一定的根据,使用某个版本;或者也有可能让某个版本永远不发 布。
Israel 提到,由于现在工程和商业松散耦合,他们可以达到流畅发布的概念,让软件变得持续有活力。工程按照自己合适的步调发布内部版本,商业可以决定什么时候哪个版本作为外部发布,让客户使用。
对这篇文章评论时, Ryan 提供了一些额外的启示,Israel 的团队每对外发布1 次,内部发布3 次。他提出其好处是能得到有价值的反馈,商业继而可以使外部发布效果更好。Ryan 认为,
> 这样好极了!结果是,我指导大多数敏捷团队时让他们这样开始,保证他们“内部发布”的频率是销售、运营、以及市场上习惯的频率的 2 倍。用这种方式你能有一个版本用于得到反馈,并把给市场的“对外发布”做的更好。
Israel 认为,采用敏捷方法,内部发布更多更快,使得软件更流畅、更有活力。这让传统的发布流程过时了。把发布区分开可以帮助工程和商业按照自己的发布模式工作,而不会互相打乱发布频率。
评论