Release模型——一种通用的软件开发模型.pdfVIP

中国计算机报1999.07.12第49 期E9 软件版 Release 模型 ——一种通用的软件开发模型 徐晓春 (江南计算技术研究所) 开发软件产品的方法很多，实际上没有一种绝对正确的方法可以保证软件产品的开发。很多单位在长期的实践中形成了自 己独有的开发组织形式，建立开发模型，创造了许多成功的软件产品。Release模型，作为一种软件开发的通用模型，广泛地应 用于软件开发部门，可以根据各部门的实际条件进行灵活的调整，以满足本单位的需要。本文就Release模型作一介绍。 一、Release模型的基本概念 Release模型的重点在于创建具有版本号、项目名和组织名等单一标识的软件产品，一旦产品推出，即以此为起点，接下来 的开发工作变围绕着下一个版本开始，这个新版本是一个独立的版本，比如SOFT 2.0.1 不同于SOFT 2.1，尽管SOFT2.1是建立在 SOFT2.0.1的基础上，因为它有许多SOFT2.0.1没有的新特征和功能。在此类开发环境中，需要跟踪产品的每一版本，并且要知 道那些文件有更改，和更改的原因。在开发下一个版本软件的同时要维护当前软件的任意一个版本。通过Release模型可以解决 这些问题。 经典的Release模型有三个基本状态：开发、测试和发布（RELEASE）。每个状态中的更改内容相互独立，以保证开发中 的程序修改不影响测试结果，测试内容不影响到已经发布的版本。 Release模型对应的生命周期开始于需要进行一次软件修补，并且已经创建了一个软件包。该软件包与一个更改需求表格相 关联，以详细描述要求进行的更改。任何人可以创建CHANGE包。如果包已经创建完毕，就可以将软件包中的文件检出（CHECK OUT）进行更改。修改完成后，可以将文件检入（CHECK IN）到软件配置管理服务器，该文件版本与该软件包相关联。当所 有的更改完成以后，就可以将软件包推进到测试状态。测试完成后，将该软件包推进到发布状态。 当下一个RELEASE开始或需要进行紧急的修复时，可以创建快照（SNAPSHOT）。快照主要用来创建一个新的环境，以 便于进行另外独立的开发。例如，现在工作在RELEASE 1.0，正在进行它的Beta测试，你想在Release 2.0上进行开发，就要先创 建一个Release 1.0 Beta的快照，并用它创建Release 2.0 的环境。任何在Release 2.0 的环境中修改，在Release 1.0 的环境中都不可 见，但是在一个环境中的修改也可以在另一个环境中实现，只要采用交互合并的技术，而且可以选择所需要合并的内容。例如， 现在有很多错误修复需要集成到Release 1.0 Beta中，在Release 2.0中已有一半更正已经实现，而且需要在Release 1.0中包含它们， 就可以采用交互合并过程将所有Release 2.0中的更改带到Release 1.0中，由于Release 1.0 Beta中的修补将会传播到Release 2.0，当 Release 1.0 Beta中的修正全部完成以后，可以采用交互合并将Release 1.0 Beta中的所有更正带到Release 2.0。 Release模型的生命周期的定义如下图： 提交测试 提交发布 开发 测试 发布 [Development] 打回开发 [Testing] [Release] Release模型有三个状态：开发、测试和发布，而每一个状态有自己的视图，每一状态可进行诸多操作，如检入(CHECK IN)， 检出(CHECK OUT)，合并(MERGE)，提交(PROMOTE)，打回(DEMOTE)、快照(TAKE SNAPSHOT)包的创建(CREATE PACKAGE)等操作。这些操作均基于客户/服务器的基础上