软件发布管理流程规范.pdfVIP

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