软件发布管理流程规范11范文

软件发布管理流程规范软件发布管理流程规范 编编制制 审审核核 日日期期 版版本本 编编号号 密密级级 第一部分 系统分析广东省社会保险管理局计算机系统总体扩充项目投标方案书 修改历史 修改时间修改人修改原因版本 第 II 页 共 12 页 中望商业机器有限公司 目目录录 1. 1. 目标目标 . .错误未定义书签。 2. 2. 发布流程发布流程 . .错误未定义书签。 2.1.2.1. 补丁发布流程补丁发布流程 错误未定义书签。 2.2.2.2. 主版本发布流程主版本发布流程 错误未定义书签。 2.3.2.3. 产品实施流程产品实施流程 错误未定义书签。 2.4.2.4.VSSVSS管理流程管理流程. .错误未定义书签。 3. 3. 相关资料相关资料 . .错误未定义书签。 第 III 页 1.1. 目标目标 软件的发布过程，需要形成有序的良性循环。否则， 各环节流转中容易发生 相互等待、 被动接应的局面。 无形中， 不断增加了沟通成本， 扩大了软件的风险。 且对后期造成的影响并不能够完全预知、完全估量。 因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计 结果后，特制定本发布过程规范。预期达到如下目的 1、减少交叉沟通。通过将发布过程流程化，使每一个环节的执行者都非常 清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻 找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询 才能掌握的现象。减少交叉沟通成本。 2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节 执行人能迅速在早期预算出自己的“参与时间” 、 “参与内容” 、 “参与工作量” ， 主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突， 便能立刻“报警” ，报得越早，越能提前应对，减少损失。 3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道（取 决于上述“1、减少交叉沟通”），便能随时掌握路面交通状况，配合可预见的行车计 划（取决于上述“ 2、提高工作预见性”） ，当然更能向车队提供有价值的消息。因此， 车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。 一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途 中密切配合的交通电台。与没有固定线路， 需要时才去调配车马，电台信息又不 畅的队伍相比，哪一个更能成功到达目的地 第 4 页 共 12 页 中望商业机器有限公司 软件发布过程规范文档编号秘级 2.2. 发布流程发布流程 本章节的流程图中，将使用下列简称。 1、需求组人包括需求总负责人或 PM、各模块需求负责人。 2、开发部人包括技术开发部全体成员。 3、配置管理员或简称 SCM，包括技术研发部的配置管理组成员。 4、测试组人包括测试组所有固定资源、临时调配资源。 5、安装组人包括负责公司内部、客户现场的安装、调试的人员。 6、客户所有使用我司产品的用户。 2.1.2.1. 补丁发布流程补丁发布流程 软件产品的某个主版本向外发布给客户使用后，发现了错误。若这个错误给 客户造成了很大的影响，等不及下一主版本， 需要立刻修正，我们就需要发布补 丁（对应 VSS 上的存放目录Patch[X.Y]） （注所有补丁要求合并入下一主版注所有补丁要求合并入下一主版 本本） 。流程图如下所示。 第 5 5 页共 1212 页 补丁发布流程补丁发布流程 下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求相应职位填写补丁签发单。 需求组 开始 开发部 开发部经理开发部经理 接收任务接收任务 （1、安排开发 人、预计开发完 成时间。2、通知 SCM） 配置管理员测试组 提出变更请求提出变更请求 （1、事先征得需 求澄清会的同意， 再填补丁签发 单。2、通知开 发经理） 检查检查 （1、检查前两个环节填写的签发单是否符合填写要求；检查描述是否 清晰、时间要求有无冲突；） 否 检查是否通过 是 安排补丁号安排补丁号 （1、安排补丁号、发布日期，通常将完成时间相距不远的安排在同一 补丁号中。2、设置VSS权限，根据开发部经理的安排设置。3、通知相 关人，开始执行施变更，并公布预计发布日期、实施建议） 开发人执行开发人执行 变更变更（按照要求 修改代码、文档， 完成后，按规范存 放） 测试组长制测试组长制 定测试计划定测试计划 （按照签发单，安 排测试人、预计测 试完成时间） 产生alpha版产生alpha版 （开发部内部可产 生多个alpha版） 安装alpha测试安装alpha测试 环境环境 部门内部测试部门内部测试 （1、alpha阶段的 测试，相当于单元 测试。2、通知 SCM） 否 测试是否通过测试是否通过 是 a l p h a 阶 段 产生Beta版产生Beta版 （1、检查相关文档是否已备齐；2、根据签发单，检查当前补丁号中提 出的变更是否都已执行；3、检查开发人在CheckIn/out的过程中，是否 符合VSS管理规范、版本管理规范；4、根据签发单，制作补丁发行说明 5、关闭VSS权限；6、编译构建beta版；7、通知测试组、安装组，向其 提交该补丁的书面签发单） 安装Beta测试环境安装Beta测试环境 （1、编写/更新补丁安 装手册；2、选择测试环 境，安装补丁beta版； 3、通知测试组、相关 人，同时刷新“公司内 部产品试用环境一览表 ”白板） 验收测试验收测试 （1、beta阶段的测试， 相当于集成测试 2、通知相关人测试结 果,含邮件、签发单电子 格式的回复。若测试通 过，则还包括在书面签 发单上签名。） 否 测试是否通过测试是否通过 是 B e t a 阶 段 产生Release版产生Release版 R e l e a s e 阶 段 1、检查测试结果是否已全部通过；2、检查提交文档是否已齐全；3、 标识、备份、记录。4、通知相关人。等等. 详见版本发布前的checkList； 分发Release版分发Release版 （1、根据安装组的工作计划、根据各客户现行情况，组合出不同的安 装包；2、分发给当次执行安装任务的人。3、通知安装组。 结束（转入产品实施流程）结束（转入产品实施流程） 中望商业机器有限公司 第 6 页 共 12 页 软件发布过程规范文档编号秘级 2.2.2.2. 主版本发布流程主版本发布流程 主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、 次数明 显增多，且设置的检查点也随之增多。 重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后，重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后， 才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完成才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完成 一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境，一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境， 请客户