软件发布管理系统流程要求要求规范.doc

实用文档

软件发布管理流程规范

编制：

审核：

日期：

版本：

编号：

密级：

实用文档

修改历史

修改时间修改人修改原因版本

目录

1. 目标. (4)

2. 发布流程 . (4)

2.1. 补丁发布流程 (4)

2.2. 主版本发布流程 (6)

2.3. 产品实施流程 (9)

2.4.

VSS管理流

程 (10)

3. 相关资料 . (11)

1.目标

软件的发布过程，需要形成有序的良性循环。否则，各环节流转中容易发生相互等待、被动接应的局面。无形中，不断增加了沟通成本，扩大了软件的风险。且对后期造成的影响并不能够完全预知、完全估量。

因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计结果后，特制定本发布过程规范。预期达到如下目的：

1、减少交叉沟通。通过将发布过程流程化，使每一个环节的执行者都非常

清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻

找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询才能掌握的现象。减少交叉沟通成本。

2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节

执行人能迅速在早期预算出自己的“参与时间” 、“参与内容”、“参与工作量”，主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突，便能立刻“报警”，报得越早，越能提前应对，减少损失。

3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道（取决于上述“ 1、减少交叉沟通”），便能随时掌握路面交通状况，配合可预见的行车计划（取决于上述“ 2、提高工作预见性”），当然更能向车队提供有价值的消息。因此，车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。

一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途中密切配合的交通电台。与没有固定线路，需要时才去调配车马，电台信息又不畅的队伍相比，哪一个更能成功到达目的地？

2.发布流程

本章节的流程图中，将使用下列简称。

1、需求组 ( 人) ：包括需求总负责人 ( 或 PM)、各模块需求负责人。

2、开发部 ( 人) ：包括技术开发部全体成员。

3、配置管理员：或简称SCM，包括技术研发部的配置管理组成员。

4、测试组 ( 人) ：包括测试组所有固定资源、临时调配资源。

5、安装组 ( 人) ：包括负责公司内部、客户现场的安装、调试的人员。

6、客户：所有使用我司产品的用户。

2.1.补丁发布流程

软件产品的某个主版本向外发布给客户使用后，发现了错误。若这个错误给客户造成了很大的影响，等不及下一主版本，需要立刻修正，我们就需要发布补丁（对应 VSS上的存放目录： Patch[X.Y] ）（注：所有补丁要求合并入下一主版本）。流程图如下所示。

补丁发布流程：下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求相应职位填写《补丁签发单》。

需求组开发部配置管理员测试组开始

提出变更请求开发部经理：

（1、事先征得需接收任务检查

求澄清会的同意，（1、安排开发

（1、检查前两个环节填写的签发单是否符合填写要求；检查描述是否

再填《补丁签发人、预计开发完

清晰、时间要求有无冲突；）

单》。 2、通知开成时间。 2、通知

发经理）SCM）

否

检查是否通过？

是

安排补丁号

（1、安排补丁号、发布日期，通常将完成时间相距不远的安排在同一

补丁号中。 2、设置 VSS权限，根据开发部经理的安排设置。3、通知相

关人，开始执行施变更，并公布预计发布日期、实施建议）

段阶a h pl a

段阶a t

e B

段阶e s a el e R

开发人：执行测试组长：制变更（按照要求定测试计划修改代码、文档，（按照签发单，安完成后，按规范存排测试人、预计测放）试完成时间）

产生alpha 版

（开发部内部可产

生多个 alpha 版）

安装alpha 测试

环境

部门内部测试

（1、alpha 阶段的

测试，相当于单元

测试。 2、通知

SCM）

否

测试是否通过？

是

产生Beta版

安装Beta测试环境

（1、编写 / 更新补丁安（1、检查相关文档是否已备齐； 2、根据签发单，检查当前补丁号中提装手册； 2、选择测试环

出的变更是否都已执行； 3、检查开发人在 CheckIn/out 的过程中，是否境，安装补丁 beta 版；

符合VSS管理规范、版本管理规范； 4、根据签发单，制作补丁发行说明3、通知测试组、相关

5、关闭 VSS权限；

6、编译构建 beta 版；

7、通知测试组、安装组，向其人，同时刷新“公司内

提交该补丁的书面签发单）部产品试用环境一览表

”白板）

验收测试（1、beta 阶段的测试，

相当于集成测试

2、通知相关人测试结

果, 含邮件、签发单电子

格式的回复。若测试通

过，则还包括在书面签

发单上签名。）

否

测试是否通过？

是

产生Release版

(1 、检查测试结果是否已全部通过；2、检查提交文档是否已齐全；3、

标识、备份、记录。 4、通知相关人。等等 ...

详见：《版本发布前的 checkList 》；)

分发Release版

（1、根据安装组的工作计划、根据各客户现行情况，组合出不同的安

装包； 2、分发给当次执行安装任务的人。3、通知安装组。

结束（转入《产品实施流程》）