文档介绍：.
发布管理流程规范
产品发布管理流程规范
编
制：
审
核：
日
期：
版
本：
编
号：
密
级：
1. 目标
2. 发布流程
目录
.4.
4.
. 补丁发布流程 .
. 试，相当于单元
测试。2、通知
SCMI
¥
--测试是否通过？- J-
产生Beta版
（1、检查相关文档是否已备齐；2、根据签发单，检查当前补丁号中提 出的变更是否都已执行；3、检查开发人在Checkin/out的过程中，是否 符合VSST理规范、版本管理规范；4、根据签发单，制作补丁发行说明 5、关闭VS教限；6、编译构建beta版；7、通知测试组、安装组，向其 提交该补丁的书面签发单）
产生 Release版
（1、检查测试结果是否已全部通过；2、检查提交文档是否已齐全；3、
标识、备份、记录。4、通知相关人。等等...
详见：《版本发布前的checkList》；）
* 1
分发Release版
结束（转入《产品实施流程》）
（1、根据安装组的工作计划、根据各客户现行情况，组合出不同的安
装包；2、分发给当次执行安装任务的人。3、通知安装组。
. 主版本发布流程
主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、次数 明显增多，且设置的检查点也随之增多。
重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后， 才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完 成一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环 境，请客户在线试用并提意见。 （此举依赖公司实现远程测试环境） 。目的：让 客户不仅知道我们在干什么，还知道我们干成什么样，是否满意。尽量让客户 的意见在开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁 发布频率。
流程图如下：
需求人 开发人 配置管理员 测试人/安装人 客户
主版本发布流程图 （下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求有物理产出。）
开始
rB
（1、填写自己负责的
《［产品名］［版本号］
开发计划清单/测试清单
/变更清单》（以下简称
清单）；2、请求召开需
求澄清会
参与澄清会
（对清单释疑）
参与澄清会— （对清单提出质疑，预估 开发所需工时）
（对变更请求提出质颖, 预估测试所需工时）
-一评审逋过?-一
宣布变更计划
（由需求总负责人/PM 宣布：1、通知SC检入 变更计划；2、通知开 发部经理接收任务； 3、通知客户）（完成 时限：上一主版本正式 对外发行前。）
（1、检查有无通过澄清会；
2、将一个产品中，各需求人
提出的清单中，已通过澄清
会的内容，合并成一份。从
此本流程仅使用合并后的清
单。3、存入VSS勺固定目
录、标 Label ；
5、通知开发部经理、测试组 长
重新进入开发阶段
（各需求人提供自己所 辖范围内的说明内容， 参照样本填写）
开发部经理：接收任务 （1、安排开发人、预计开发 完成时间。2、通知相关人）
为开发部门设置权
限
试计划
（按照清单，制定测试
大纲、测试计划）
段阶发开〉
需求确认测试
（确认功能是否满足
需求）
开发人：执行变更
（1、开发人执行变更；2、
定期向项目管理组汇报开发
进展）
产生alpha版
（可产生若干个alpha版，直
至所有变更完成）
安装alpha测试环境
部门内部测试
（alpha阶段的测试，
相当于单元测试，确认
功能是否完整、是否正
常运行、相关手册是否
最新）
收集、审核发行说
明内容
制作发行说明网页
（根据收集并审核通过
的内容，制作成适合客
户在线阅读的网页等格
式，变更清单除外）
版本测试
（1、根据测试计划测 试；2、写安装手册）
T 否
•--i是否参与?： ■一否
「是
需求确认测试 （确认功能是否满 足要求，尽可能提 出改进意见）
二"测试通过?
是
需求人 开发人 配置管理员 测试人/安装人 客户
主版本发布流程图（续）
物理配置审核 （1、各类文档有无备齐；2、有 无全部测试通过…等等，详见
《Checklist »）
产生 Beta版
（1、关闭VS教限；2、标
Label;3、编译构建beta版、备 份、