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

1、软件发布管理流程规范编制：审核：日期：版本：编 号：密级：修改历史修改时间修改人修改原因版本1 .目标42 .发布流程41, 1,补丁发布流程42, 2.主版本发布流程62. 3.产品实施流程93. 4. VSS管理流程104. 相关资料111.目标软件的发布过程，需要形成有序的良性循环。否则，各环节流转中容易发生 相互等待、被动接应的局面。无形中，不断增加了沟通成本，扩大了软件的风险。 且对后期造成的影响并不能够完全预知、完全估量。因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计 结果后，特制定本发布过程规范。预期达到如下目的：1、减少交叉沟通。通过将发布过程流程化，使每一

2、个环节的执行者都非常 清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻 找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询 才能掌握的现象。减少交叉沟通成本。2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节 执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”， 主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突， 便能立刻“报警”，报得越早，越能提前应对，减少损失。3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道磔 决于上述“1、减少交叉沟通便能随时掌握路面交通状况，配合可预见的

3、行车计 划（取决于上述“2、提高工作预见性”）,当然更能向车队提供有价值的消息。因此， 车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途 中密切配合的交通电台。与没有固定线路，需要时才去调配车马，电台信息又不 畅的队伍相比，哪一个更能成功到达目的地？2.发布流程本章节的流程图中，将使用下列简称。1、需求组（人）：包括需求总负责人（或PM）、各模块需求负责人。2、开发部（人）：包括技术开发部全体成员。3、配置管理员：或简称SCM,包括技术研发部的配置管理组成员。4、测试组（人）：包括测试组所有固定资源、临时调配

4、资源。5、安装组（人）：包括负责公司内部、客户现场的安装、调试的人员。6、客户：所有使用我司产品的用户。2.1 ,补丁发布流程软件产品的某个主版本向外发布给客户使用后，发现了错误。若这个错误给 客户造成了很大的影响，等不及下一主版本，需要立刻修正，我们就需要发布补 丁（对应VSS上的存放目录：PatchX. Y）（注：所有补丁要求合并入下一主版本）。流程图如下所示。辛卜丁发布流程：下图中每个方柢代我一个进程括号内描述该进程的具体内容每个进程均要求相应职位填写什卜丁解发华？ 郎盒gEP 郎盒£出都盒UK上我需求组开发部配置管理员测试组C 开航D1开发部经理：1 接收任务A （，安排开发

5、_ 人、预计开发完 成时间.3通知SCM）i提出变更请求（1、事先征得能 求澄清会的同意.再填补丁签发' 单.2、通知开 发经理）检查（1,检查前两个环节填写的签发单是否符合填写要求：检号描述是否 清晰.时间要求有无冲突：）7左；g :if3*-一安排补丁号（K安排补丁号、发布日期,通常将完成时间相框不远的安排在同一 补丁号中 2、设置VSS权限,根据开发部经理的安排设置.3.通知相 关人.开始执行施变更-并公布很计发布日期、实诙建议11否,r ,，开发人：执行 变更（按照要求 修改代码.文档, 完成后.按规范存 放）产生alpha版 （开发匐内部可产 4多个alpha板）测试组 定测

6、七 按照签 棒测试人 试完成长：制 甭计划 发单.安 、预计测 时间）安装alpha测试 环境1q部门内部测试 （1. alphas段的 测试.相当于单元 测试,2、通知 SCM）.一 *一混试是否通过?-二 xX1产生Beta版<1，检查相关文档是否已备齐：2.根据签发单.检查当曲补丁号中提 出的变更是否郡己执行：3检查开发人在Checkln/out的过程中,是否 好合VSS管理规范、板本管理规范：4,根据筌发单.制作补丁发行说明 5.关闭VSS权限：6、娘译构建betaffib 7、通知测试组、安装组,向其 提交该补丁的书面签发单）T安装Beta测试环境 （1、编写/更新补丁安 袋手

7、册：2.选择测试环 境安装补丁beta版： 3,划知测试组、相关 人.同时刷新“公司内 螺产品试用环境一览表”白板）L 验收测试 （1、beta阶段的测试. 相当于集成测试2.通知相关人测试结 果，含邮件，签发单电子 格式的回史.若测试通 过.则还包括在书面答 发的上签名）否一土 .3 2、y 二1 -1产生Release版（1.检杳测试结果是否已全部通过：3检套提交文档是否已齐全：3、 标识、番份、记录.4、刘知相关人.等等.详见：工版本发布前的checkList：）分发Release版“、根据安装组的工作计划.根据各客户或行情况,组合出不同的安 袋包：2、分发给当次执行安装任务的人. 3通

8、知安装组. 结束（转入产品实施流程）2. 2.主版本发布流程主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、次数明 显增多，且设置的检查点也随之增多。重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后,才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完成一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境,请客户在线试用并提意见。（此举依赖公司实现远程测试环境）。目的：让客户不仅知道我们在干什么，还知道我们干成什么样，是否满意。尽量让客户的意见在开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁发布频率。流程图如下：主版本发

9、布流程图（下图中每个方框代表一个进程,括号内描述该迸程的具体内容，每个进程均要求有物理产出.需求人开发人配置管理员测试人/安装人客户开始提出变更请求（1、填写自己负责的产品名版本号 开发计划清单/测试清单 /变更清单（以下简称 清单）；2、请求召开需 求澄清会参与澄清会（对清单释疑）宣布变更计划（由需求总负责人/PM 宣布：1、通知SC限入 变更计划；2、通知开 发部经理接收任务； 3、通知客户）（完成 时限：上一主版本正式 对外发行前，）提供发行说明内容 （各需求人提供自己所辖范围内的说明内容.参照样N工填写）需求确认测试（确认功能是否满足需求）参与澄清会（对清单提出质疑，预估开发所需工时）

10、参与春洁会例变更请求提出质颍,预估测试所需工时）开发部经理：接收任务（1、安排开发人、预计开发完成时间。2、通知相关人）开发人：执行变更<1.开发人执行变更；2、 定期向项目管理组汇报开发 进展）f产生alpha版（可产生若干个alpha版，直 至所有变更完成）3安装al pha测试环境部门内部测试（alpha阶段的测试,相当于单元测试，确认功能是否完整、是否正常运行、相关手册是否最新）检入变更计划（1、检查有无通过澄清会；2、将一个产品中，各需求人提出的清单中，已通过澄清会的内容，合并成一份.从此本流程仅使用合并后的清单，3、存入VSS的固定目录、标Labe I；5、通知开发部经理、测

11、试组长为开发部门设置权限收集、审核发行说 明内容测试组长：制定测试计划（按照清单，制定测试大纲、测试计划|更新进入开发阶段制作发行说明网页（根据收集并审核通过的内容,制作成适合客户在线阅读的网页等格式，变更清单除外）版本测试（1、根据测试计划测试；2、写安装手册）.是否参与筌二卫需求确认测试（确认功能是否满足要求，尽可能提出改进意见主版本发布流程图（续）需求人开发人配置管理员测试人/安装人客户病试通过？产，阶段2. 3.产品实施流程为方便大家更加理解软件的整个发布循环过程，在此简单介绍软件通过 Release阶段后的实施流程，它包括安装、培训等内容。具体的规范制度，以实 施部门制定的为准。2