下面是小编为大家整理的发布管理流程规范【精选推荐】,供大家参考。
产品发布管理流程规范
编 制：
审 核：
日 期：
版 本：
编 号：
密 级：
TOC \o "1-5" \h \z 目标 3
发布流程 3
补丁发布流程 3
主版本发布流程 5
产品实施流程 8
VSS管理流程 9
相关资料 9
目标
软件产品的发布过程，需要形成有序的良性循环。
否则，各环节流转中容易 发生相互等待、被动接应的局面。无形中，不断增加了沟通成本，扩大了软件的 风险。且对后期造成的影响并不能够完全预知、完全估量。
因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计 结果后，特制定本发布过程规范。预期达到如下目的：
1、减少交义沟通。通过将发布过程流程化，使每一个环节的执行者都非常 活楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻 找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询 才能掌握的现象。减少交义沟通成本。
2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节 执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”， 主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突，
便能立刻“报警”，报得越早，越能提前应对，减少损失。
3、提高可控性。产品发布就像道路交通。交通电台有了可靠的消息渠道（取 决于上述“1、减少交叉沟通”），便能随时掌握路面交通状况，配合可预见的行车计
划（取决于上述“2、提高工作预见性”），当然更能向车队提供有价值的消息。因此， 车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。
一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途 中密切配合的交通电台。与没有固定线路，需要时才去调配车马，电台信息乂不 畅的队伍相比，哪一个更能成功到达目的地？
发布流程
本章节的流程图中，将使用下列简称。
1、需求组（人）：包括需求总负责人（或PM＞各模块需求负责人。
2、开发部（人）：包括技术开发部全体成员。
3、配置管理员：或简称SCM包括技术研发部的配置管理组成员。
4、测试组（人）：包括测试组所有固定资源、临时调配资源。
5、安装组（人）：包括负责公司内部、客户现场的安装、调试的人员。
6、客户：所有使用我司产品的用户。
补丁发布流程
软件产品的某个主版本向外发布给客户使用后， 发现了错误。若这个错误给 客户造成了很大的影响，等不及下一主版本， 需要立刻修正，我们就需要发布补 丁（对应VSS上的存放目录：Patch[X.Y]）（注：所有补丁要求合并入下一主版 本）。流程图如下所示。
彳卜丁发布流程：下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求相应职位填写《补丁签发单〉〉
需求组开发部配置管理员测试组
需求组开发部配置管理员
测试组
提出变更请求
（1
提出变更请求
（1、事先征得需
求澄清会的同意，
再填《补丁签发
单》。2、通知开
发经理）
开发部经理.
接收任务
（1、安排开发
人、预计开发完
成时间。2、通知
scm
检查
（1、检查前两个环节填写的签发单是否符合填写要求；
检查描述是否
清晰、时间要求有无冲突；
）
检查是否通过？（1、安排补丁号、发布日期，通常将完成时间相距不远的安排在同一
补丁号中。2、设置VS敬限，根据开发部经理的安排设置。3、通知相关人，开始执行施变更，并公布预计发布日期、实施建议）^^anDla开发人:执行
变更（按照要求
修改代码、文档，
完成后，按规范存
放）'产''生
检查是否通过？
（1、安排补丁号、发布日期，通常将完成时间相距不远的安排在同一
补丁号中。2、设置VS敬限，根据开发部经理的安排设置。3、通知相
关人，开始执行施变更，并公布预计发布日期、实施建议）
^^anDla
开发人:执行
变更（按照要求
修改代码、文档，
完成后，按规范存
放）
'产''生 alpha/{jz'
（开发部内部可产
生多个alpha版）
upha
环境
…W,一一
部门内部测试
（1、alpha阶段的
测试，相当于单元
测试。2、通知
scm
测试是否通过？
是
产生Beta版
（1、检查相关文档是否已备齐；
2、根据签发单，检查当前补丁号中提
出的变更是否都已执行；
3、检查开发人在CheckIn/out的过程中，是否
符合VS磨理规范、版本管理规范；
4、根据签发单，制作补丁发行说明
5、关闭VS淑限；
6、编译构建beta版；
7、通知测试组、安装组，向其
提交该补丁的书面签发单）
产生Release版
（1、检查测试结果是否已全部通过；
2、检查提交文档是否已齐全;
标识、备份、记录。4、通知相关人。等等...
详见：《版本发布前的checkList〉〉；
）
分发Release版
（1、根据安装组的工作计划、根据各客户现行情况，组合出不同的安
装包；
2、分发给当次执行安装任务的人。3、通知安装组。
结束（转入《产品实施流程》）
3、
测试组长：制
定测试计划
（按照签发单，安
排测试人、预计测
试完成时间）
安装Beta测试环境
（1、编写/更新补丁安
装手册；
2、选择测试环
境，安装补丁 beta版；
3、通知测试组、相关
人，同时刷新“公司内
部产品试用环境一览表
"白板）
验收测试
（1、beta阶段的测试，
相当于集成测试
2、通知相关人测试结
果,含邮件、签发单电子
格式的回复。若测试通
过，则还包括在书面签
发单上签名。）
否
测试是否通过？
.是
主版本发布流程
主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、次数明 显增多，且设置的检查点也随之增多。
重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后， 才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完成 一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境， 请客户在线试用并提意见。（此举依赖公司实现远程测试环境）。目的：让客户不 仅知道我们在干什么，还知道我们干成什么样，是否满意。尽量让客户的意见在 开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁发布频率。
流程图如下：
需求人开发人配置管理员测试人/安装人客户
提出变更请求
（1、填写自己负责的?［产品名］［版本号］
开发计划清单/测试清单
/变更清单》（以下简称
清单）；
2、请求召开需
求澄清会
宣布变更计划
（由需求总负责人/PM 宣布：1、通知SC雌入 变更计划;2、通知开 发部经理接收任务；
3、通知客户）（完成 时限：上一主版本正式
对外发行前。）
（1、检查有无通过澄清会；
2、将一个产品中，各需求人
提出的清单中，已通过澄清
会的内容，合并成一份。从
此本流程仅使用合并后的清
单。3、存入VSS勺固定目
录、标 Label；
5、通知开发部经理、测试组
长
段阶发开
需求确认测试
（确认功能是否满足
需求）
部门内部测试
（alpha阶段的测试， 相当于单元测试，确认 功能是否完整、是否正 常运行、相关手册是否 最新）
重新进入开发阶段
为开发部门设置权
限
收集、审核发行说
明内容
制作发行说明网页 （根据收集并审核通过 的内容，制作成适合客 户在线阅读的网页等格
式，变更清单除外）
一 , 否
是否参与？—
是
版本测试
（1、根据测试计划测
试；
2、写安装手册）
需求确认测试
（确认功能是否满
足要求，尽可能提
出改进意见）
主版本发布流程图（续）
需求人 开发人配置管理员测试人/安装人客户
物理配置审核
（1、各类文档有无备齐；
2、有 无全部测试通过…等等，详见
《Checklist ? ）
（1、关闭VS淑限；
2、标
Label;3、编译构建beta版、备 份、通知相关人；
3、制作变更清 单网页..?等等，详见《执行列 表〉〉）
安装Beta测试环
安装Beta测试环
境（公司内部用）
（1、根据测试计划、
安装手册，安装测试
环境（可能有多套环
境），验证安装过程是
否正确；
2、通知
SCM测试组、刷新
“公司内部产品试用
环境一览表”）
客户￡否否
参与测试？
是
境（客户用）
（1、根据客户需要，
选择安装环境，并进
行安装；
2、通知
SCIM各需求负责人）
验收测试（1、根据测试计划测
验收测试
（1、根据测试计划测
试；
2、回复测试结果
（含邮件、上传VSS
书面三种方式））
安装记录
验收测试
（1、对产品进行 测试、试用，包 括性能、功能方 面的测试，尽可
能提出意见）
^^esaeLQR
^^esaeLQR
结束（转入《产品实施流程》）
产品实施流程
为方便大家更加理解软件的整个发布循环过程，在此简单介绍软件通过 Release阶段后的实施流程，它包括安装、培训等内容。具体的规范制度，以实 施部门制定的为准。
2.4. VSS管理流程
3.相关资料
3.1软件版本号的命名约定、分支约定
