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