潜鱼在渊

Concentrating on Architectures.

posts - 77, comments - 309, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

软件发行管理(下)

Posted on 2005-12-16 21:31 非鱼 阅读(2306) 评论(2)  编辑  收藏 所属分类: 管理
    软件发行管理(上)
   
    上一篇讲了发行管理的一些基本理论,最主要最根本的一点就是不要对发行的内容失去控制。在这个基础上逐步加强对发行节奏的协调,可以形成良好的软件发行管理制度,提高软件发行能力。下面要说的是发行中的一些细节。

    在一个软件的生命周期中,一般会有多次发行,尤其对于迭代开发的软件更是这样。每隔一段时间,生产商就会发行一个主要版本,其中包含大量功能改进或新增功 能。同时,在每个主要版本发行的间隔中,也会发行一些对当前用户使用版本的补丁。这种情况是由软件本身的性质决定的。对于实体的产品(如汽车),当发现设 计缺陷时必须要“召回”;而对于非实体的、形式的软件产品,当发现缺陷时,就需要发行一个更正的补丁。实际上,软件的主要版本和补丁版本往往是同时开发/ 修改的。版本管理和发行管理使用这种并行的开发活动互不干扰并且互相协作。下图是软件发行和版本管理的总图:

      release1.bmp

    在上图中,ADCTR分别代表分析、设计、编码实现、测试和发行。红线表示主要版本,所有新增功能和重大改进功能都在这个分支上进行,它代表软件内容的增 加。几个与Time轴平行的线表示补丁版本,对于重要缺陷的修正是在这个分支上进行,它也表示了补丁版本不增加新的内容(功能)。同时,主要版本上开发的 内容很多,涉及的文件修改也是数量巨大的。而补丁版本也称为Minor版本,这个分支上没有大量的修改,涉及的文件也很少。另外,我们也可以看到,每次的 发行都需要一定的时间,而在主要版本发行期间,主要版本分支理论上是没有新的开发内容的,这种情况一直维持到新的版本计划确定为止(实际上,新版本计划通 常在版本发行之前就开始制定了)。

    在补丁分支上修改的文件,必须在测试通过后合并到其上面最近的分支中。这样就保证了次要分支上的修 改不丢失,这些修改同样也反映在后续的发行中。向最近的分支合并的文件,最终会被逐级合并到主要版本中。曾经有某国际大型知名软件开发商,其安装程序的一 个小缺陷在一个次要版本中更正了,但后来其发行的一个主要版本中并没有修正这个缺陷。出现这种情况一般是因为没有合并或没有逐级合并。目前基本上所有的版本管理软件都支持版本的分支和合并操作。

    也存在多分支(多于两个)开发的情况,不过这种情况并不常见,因为控制上的难度很大,也容易出错。实际上,当主要版本发行间隔过于密集时,也容易出现控制上的漏洞。

    在实际操作中,通常有两个问题比较典型,也应该引起大家的注意。

    1. 版本主次不分

    在主要版本分支上开发的内容不是远远多于补丁版本分支上修改的内容,甚至在补丁分支上开发新增功能。这个问题的严重性超出想象。这直接导致版本的合并操作艰难,甚至完全不可能。注意:补丁版本上永远只能做紧急、小量修改,稍大的缺陷修改都不应该在其上进行。

    2. 文件合并问题

    修改后测试通过的文件合并不及时、合并不正确也是常见的一个问题。合并不及时,就象不进行日构建一样,具有同样的危害。合并不正确会导致后续的发行版本包 含已确认解决的问题。这是应该在管理上加强控制的。另外,也不要太过于依赖自动的文件合并。

评论

# re: 软件发行管理(下)  回复  更多评论   

2005-12-16 23:14 by weide
1. 版本主次不分

通常我们描述为标准版本、定制版本。标准版本是符合大多数企业的通用版--标准版。为具体企业定制的版本,不是所有功能都适合放到标准版中,这样定制的版本多了的时候,管理起来也很麻烦。定制的多个分支交叉开发的时候,有些是共性的能够合并且应该合并到主分支,有些则不然

# re: 软件发行管理(下)  回复  更多评论   

2006-03-11 13:58 by blueski
我是sawin.cn的blueski,冒昧转摘了此文,并表示一下感谢。

只有注册用户登录后才能发表评论。


网站导航: