发布管理流程规范.docxVIP

发布管理流程规范 产品发布管理流程规范 编 制： 审 核： 日 期： 版 本： 编 号： 密 级： 一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途 中密切配合的交通电台。与没有固定线路，需要时才去调配车马，电台信息又不 畅的队伍相比，哪一个更能成功到达目的地？ 1. 发布流程 本章节的流程图中，将使用下列简称。 1、需求组(人)：包括需求总负责人(或 PM)、各模块需求负责人。 2、开发部(人)：包括技术开发部全体成员。 3、配置管理员：或简称 SCM ，包括技术研发部的配置管理组成员。 4、测试组(人)：包括测试组所有固定资源、临时调配资源。 5、安装组(人)：包括负责公司内部、客户现场的安装、调试的人员。 6、客户：所有使用我司产品的用户。 1.1. 补丁发布流程 软件产品的某个主版本向外发布给客户使用后 ，发现了错误。若这个错误给 客户造成了很大的影响 ，等不及下一主版本，需要立刻修正 ，我们就需要发布补 丁（对应 VSS 上的存放目录：Patch[X.Y]）（注：所有补丁要求合并入下一主版 本）。流程图如下所示。 e e 补丁发布流程： 下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求相应职位填写《补丁签发单》。 开发部需求组 开发部 开始 提出变更请求 （1、事先征得需 求澄清会的同意， 再填《补丁签发 单》。2、通知开 发经理） 开发部经理： 接收任务 （1、安排开发 人、预计开发完 成时间。2、通知 SCM） 测试组配置管理员 测试组 检查 （1、检查前两个环节填写的签发单是否符合填写要求；检查描述是否 清晰、时间要求有无冲突；） 否检查是否通过？ 否 是 安排补丁号 （1、安排补丁号、发布日期，通常将完成时间相距不远的安排在同一 补丁号中。2、 设置VSS权限，根据开发部经理的安排设置。3、通知相 关人，开始执行施变更， 并公布预计发布日期、实施建议） 段 阶 开发人：执行 变更 （按照要求 修改代码、文档， 完成后，按规范存 放） 产生alpha版 （开发部内部可产 生多个alpha版） 安装alpha测试 环境 部门内部测试 （1、alpha阶段的 测试，相当于单元 测试。2、通知 SCM） 否 测试是否通过？ 是 测试组长：制 定测试计划 （按照签发单，安 排测试人、预计测 试完成时间） 段 阶 段 阶 产生Beta版 （1、检查相关文档是否已备齐；2、 根据签发单，检查当前补丁号中提 出的变更是否都已执行；3、检查开发人在CheckIn/out的过程中，是否 符合VSS管理规范、版本管理规范；4、 根据签发单， 制作补丁发行说明 5、 关闭VSS权限；6、 编译构建beta版；7、通知测试组、安装组， 向其 提交该补丁的书面签发单） 产生Release版 (1、检查测试结果是否已全部通过；2、检查提交文档是否已齐全；3、 标识、备份、记录。4、通知相关人。 等等... 详见：《版本发布前的checkList》；) 分发Release版 （1、 根据安装组的工作计划、根据各客户现行情况，组合出不同的安 装包；2、 分发给当次执行安装任务的人。3、通知安装组。 结束（转入《产品实施流程》） 安装Beta测试环境 （1、 编写/更新补丁安 装手册；2、 选择测试环 境，安装补丁beta版； 3、通知测试组、相关 人，同时刷新“公司内 部产品试用环境一览表 ”白板） 验收测试 （1、beta阶段的测试， 相当于集成测试 2、通知相关人测试结 果,含邮件、签发单电子 格式的回复。若测试通 过，则还包括在书面签 发单上签名。） 否 测试是否通过？ 是 1.2. 主版本发布流程 主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、次数明 显增多，且设置的检查点也随之增多。 重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后， 才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完成 一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境， 请客户在线试用并提意见。（此举依赖公司实现远程测试环境）。目的：让客户不 仅知道我们在干什么，还知道我们干成什么样，是否满意。尽量让客户的意见在 开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁发布频率。 流程图如下： 段阶求需段阶发开 段阶求需 段阶发开 主版本发布流程图 需求人 开始 提出变更请求 （下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求有物理产出。） 开发人 配置管理员 测试人/安装人 客户 （1、填写自己负责的 《[产品名] [版本号] 开发计划清单/测试清单 /变更清单》（以