软件发行管理

发行是产品开发完成并交付客户安装、配置、使用的过程。软件发行做为生产完成或阶段性完成时刻的活动，不仅是一个短时期的任务，它和开发过程中的其他活动密切相关。

    在整个软件的生命周期中，开发活动总是迭代进行的。即使对于传统的软件开发方法（结构化设计），在维护阶段一个用户的需求变更，将导致软件的新版本发行，这时候不得不进行被动的迭代——在原软件的基础上改进并发行改进的补丁或者完整版本。但人们在面向对象的开发方法中，更加倾向于主动的迭代过程，以提高软件产品的质量。

    我们也用更现代的视角来观察整个过程和软件发行这个活动。开发计划在最初时刻定义了发行版本的内容，正常情况下，未来的发行将包含计划中的所有开发内容。开发过程中的各种活动如评审、测试等保证了发行的质量。版本管理是一个好的发行成功的根本保证。发行活动记录软件版本和发行的目标客户，以进行后期的维护如补丁发行、版本更新。

    软件的发行是有节奏、有内容、有质量的。节奏保证了开发人员和最终客户的一致，所有人都知道版本将在何时发行。内容满足最终客户的期望。质量保证产品即满足用户的需求，又能够提高后续版本发行能力。



    软件发行中主要存在的问题有三种：短路的发行、内容膨胀和缺陷积累。

    短路的发行

    短路的发行是指为了保证发行的节奏，或者因为设定了DEADLINE而导致在开发过程中缩减活动，如不经评审、粗略测试等。这导致了发行质量的下降，并影响到后续的发行版本。这在国内的软件企业中非常严重，我们常常看到连续的加班和最终的低质量的产品并存。

    解决这个问题的方法是使用严密可行的、可变更的版本计划。严密可行的计划可以直接保证版本及时发行；当发现不能及时发行版本时缩减版本计划中的内容可以在保证及时发行的基础上同时保证版本的质量，毕竟质量才是最重要的。

    内容的膨胀

    内容的膨胀是指在版本开发过程中，不断的增加计划外的内容。这必然导致两个结果之一：要么降低版本质量，要么拖延版本发行时间。任何一项都不是我们想看到的。这和项目经理/需求人员的控制能力有关，很多时候，顶住客户的压力不是一件容易的事情。

    所以这个问题的最终解决方案是提高项目经理/需求人员的能力，提高客户对软件开发的理解。除此之外，我们能够做的就是在增加内容的同时缩减低优先等级的内容，来保证发行的质量和节奏。

    缺陷的积累

    这个问题大家都已经注意到了，在发行前期，匆忙的构建过程中发现大量的缺陷，最终导致发行的拖延。

    解决这个问题的手段也比较简单，就是进行有效的日构建，尽早发现并解决缺陷，争取在发行时刻的主动权。

    我们来看一个例子：

    我本来想在今晚12：00以前写完整个发行管理的，但现在看来我是不能完成了。我不想拖到12：00以后再发这篇文章，也不能敷衍的随便写写了事。所以我砍掉后面的发行管理的细节内容，这些内容将在后续版本中发行。这样我即保证了本篇的质量，也赶上了我给自己定义的时间线。

 以上讲了发行管理的一些基本理论，最主要最根本的一点就是不要对发行的内容失去控制。在这个基础上逐步加强对发行节奏的协调，可以形成良好的软件发行管理制度，提高软件发行能力。下面要说的是发行中的一些细节。

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

     

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

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

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

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

    1. 版本主次不分

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

    2. 文件合并问题

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

原文转自：http://www.ltesting.net