最新软件发布管理流程规范.docx

软件发布管理流程规范 第 第II页 第 第II页 软件发布管理流程规范 编 制： 审 核： 日 期： 版 本： 编 号： 密 级： 第 第II页 第 第II页 修改历史 修改时间 修改人 修改原因 版本 第 第 IV 页 第 第 IV 页 目录 TOC \o 1-5 \h \z \o Current Document 目标 5. \o Current Document 发布流程 6. \o Current Document 补丁发布流程 6. \o Current Document 主版本发布流程 8. \o Current Document 产品实施流程 1. 1 \o Current Document VSS 管理流程 12 \o Current Document 相关资料 1. 3 软件发布过程规范 文档编号： 秘级： 软件发布过程规范 文档编号： 秘级： 第 第 PAGE # 页 共 13 页 软件发布过程规范 文档编号： 秘级： 软件发布过程规范 文档编号： 秘级： 第 第 PAGE # 页 共 13 页 1. 目标 软件的发布过程， 需要形成有序的良性循环。否则， 各环节流转中容易发生 相互等待、被动接应的局面。 无形中，不断增加了沟通成本， 扩大了软件的风险。 且对后期造成的影响并不能够完全预知、完全估量。 因此，根据公司内部前期已有的习惯， 总结过去产品的发布经验， 分析统计 结果后，特制定本发布过程规范。预期达到如下目的： 1、减少交叉沟通。通过将发布过程流程化，使每一个环节的执行者都非常 清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻 找到关键人物沟通解决。 避免当需要获取一件事情的进展情况时， 需要广泛征询 才能掌握的现象。减少交叉沟通成本。 2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节 执行人能迅速在早期预算出自己的“参与时间” 、“参与内容”、“参与工作量”， 主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突， 便能立刻“报警”，报得越早，越能提前应对，减少损失。 3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道 （取决于上述“ 1、减少交叉沟通 ”），便能随时掌握路面 交通状况，配合可预见的行车计划 （取决于上述“ 2、提高工 作预见性”）， 当然更能向车队提供有价值的消息。因此，车队领导能做 出更有控制力的指令，各车队协调行驶，整个交通自然更受控。 一条早已设计好的行车路线， 加上提前准备就绪的车队人马， 再加上行进途 中密切配合的交通电台。与没有固定线路， 需要时才去调配车马， 电台信息又不 畅的队伍相比，哪一个更能成功到达目的地？ 2. 发布流程 本章节的流程图中，将使用下列简称。 1、需求组（人）：包括需求总负责人 （或 PM） 、各模块需求负责人。 2、开发部 （人）：包括技术开发部全体成员。 3、配置管理员：或简称 SCM ，包括技术研发部的配置管理组成员。 4、测试组 （人）：包括测试组所有固定资源、临时调配资源。 5、安装组 （人 ）：包括负责公司内部、客户现场的安装、调试的人员。 6、客户：所有使用我司产品的用户。 2.1. 补丁发布流程 软件产品的某个主版本向外发布给客户使用后， 发现了错误。 若这个错误给 客户造成了很大的影响，等不及下一主版本， 需要立刻修正， 我们就需要发布补 丁（对应 VSS 上的存放目录： Patch[X.Y] ）（注：所有补丁要求合并入下一主版 本）。流程图如下所示。 软件发布过程规范 文档编号: 秘级:需求组 开发部 配置管理员 测试组 软件发布过程规范 文档编号: 秘级: 需求组 开发部 配置管理员 测试组 第 第 PAGE #页共13页 软件发布过程规范 文档编号: 秘级:需求组 开发部 配置管理员 测试组 软件发布过程规范 文档编号: 秘级: 需求组 开发部 配置管理员 测试组 第 第 PAGE #页共13页 补丁发布流程： 下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求相应职位填写《补丁签发单》 开始 提岀变更请求 （1、事先征得需 求澄清会的同意， 再填《补丁签发 单》。2、通知开 发经理） 开发部经理： 接收任务 （1、安排开发 人、预计开发完 成时间。2、通知 SCM 环境 段 产生alpha版 （开发部内部可产 生多个alpha版） 测试组长：制 定测试计划 （按照签发单，安 排测试人、预计测 试完成时间） 测试是否通过？ 是 部门内部测试 （1、alpha阶段的 测试，相当于单元 测试。2、通知 scm 检查 （1、检查前两个环节填写的签发单是否符合填写要求；检查描