《发布管理流程规范》.docxVIP

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