资源预览内容
第1页 / 共11页
第2页 / 共11页
第3页 / 共11页
第4页 / 共11页
第5页 / 共11页
第6页 / 共11页
第7页 / 共11页
第8页 / 共11页
第9页 / 共11页
第10页 / 共11页
亲,该文档总共11页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
软件发布管理流程规范软件发布管理流程规范 编编 制:制: 审审 核:核: 日日 期:期: 版版 本:本: 编编 号:号: 密密 级:级: 修改历史 修改时间修改人修改原因版本 目目 录录 1. 目目标标 4 2. 发布发布流流程程 .4 2.1. 补丁发布流程补丁发布流程4 2.2. 主版本发布流程主版本发布流程6 2.3. 产品实施流程产品实施流程9 2.4. VSS 管理流程管理流程.10 3. 相关资料相关资料 .11 1. 目标目标 软件的发布过程,需要形成有序的良性循环。否则,各环节流转中容易发 生相互等待、被动接应的局面。无形中,不断增加了沟通成本,扩大了软件的 风险。且对后期造成的影响并不能够完全预知、完全估量。 因此,根据公司内部前期已有的习惯,总结过去产品的发布经验,分析统 计结果后,特制定本发布过程规范。预期达到如下目的: 1、减少交叉沟通。通过将发布过程流程化,使每一个环节的执行者都非常 清楚自己的产入产出,受谁的影响,将影响谁。当遇到困难时,能明确的定位 寻找到关键人物沟通解决。避免当需要获取一件事情的进展情况时,需要广泛 征询才能掌握的现象。减少交叉沟通成本。 2、提高工作预见性。流程一旦启动,流程中的所有人员便被触动。各环节 执行人能迅速在早期预算出自己的“参与时间” 、 “参与内容” 、 “参与工作量” , 主动提前做出安排、准备,避开人力、时间等资源上的冲突。且一旦发现冲突, 便能立刻“报警” ,报得越早,越能提前应对,减少损失。 3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道 (取决于上述“1、减少交叉沟通” ),便能随时掌握路面交通状况,配合可预见的行 车计划(取决于上述“2、提高工作预见性” ),当然更能向车队提供有价值的消息。 因此,车队领导能做出更有控制力的指令,各车队协调行驶,整个交通自然更 受控。 一条早已设计好的行车路线,加上提前准备就绪的车队人马,再加上行进 途中密切配合的交通电台。与没有固定线路,需要时才去调配车马,电台信息 又不畅的队伍相比,哪一个更能成功到达目的地? 2. 发布流程发布流程 本章节的流程图中,将使用下列简称。 1、需求组(人):包括需求总负责人(或 PM)、各模块需求负责人。 2、开发部(人):包括技术开发部全体成员。 3、配置管理员:或简称 SCM,包括技术研发部的配置管理组成员。 4、测试组(人):包括测试组所有固定资源、临时调配资源。 5、安装组(人):包括负责公司内部、客户现场的安装、调试的人员。 6、客户:所有使用我司产品的用户。 2.1. 补丁发布流程补丁发布流程 软件产品的某个主版本向外发布给客户使用后,发现了错误。若这个错误 给客户造成了很大的影响,等不及下一主版本,需要立刻修正,我们就需要发 布补丁(对应 VSS 上的存放目录:PatchX.Y) (注:所有补丁要求合并入下一注:所有补丁要求合并入下一 主版本主版本) 。流程图如下所示。 补补丁丁发发布布流流程程:下图中每个方框代表一个进程,括号内描述该进程的具体内容。每个进程均要求相应职位填写补丁签发单。 Beta阶段Release阶段alpha阶段 需求组开发部配置管理员测试组 提提出出变变更更请请求求 (1、事先征得需 求澄清会的同意, 再填补丁签发 单。2、通知开 发经理) 开开发发部部经经理理: 接接收收任任务务 (1、安排开发 人、预计开发完 成时间。2、通知 SCM) 检检查查 (1、检查前两个环节填写的签发单是否符合填写要求;检查描述是否 清晰、时间要求有无冲突;) 开始 开开发发人人:执执行行 变变更更(按照要求 修改代码、文档, 完成后,按规范存 放) 部部门门内内部部测测试试 (1、alpha阶段的 测试,相当于单元 测试。2、通知 SCM) 产产生生B Be et ta a版版 (1、检查相关文档是否已备齐;2、根据签发单,检查当前补丁号中提 出的变更是否都已执行;3、检查开发人在CheckIn/out的过程中,是否 符合VSS管理规范、版本管理规范;4、根据签发单,制作补丁发行说明 5、关闭VSS权限;6、编译构建beta版;7、通知测试组、安装组,向其 提交该补丁的书面签发单) 安安装装B Be et ta a测测试试环环境境 (1、编写/更新补丁安 装手册;2、选择测试环 境,安装补丁beta版; 3、通知测试组、相关 人,同时刷新“公司内 部产品试用环境一览表 ”白板) 验验收收测测试试 (1、beta阶段的测试, 相当于集成测试 2、通知相关人测试结 果,含邮件、签发单电子 格式的回复。若测试通 过,则还包括在书面签 发单上签名。) 产产生生R Re el le ea as se e版版 (1、检查测试结果是否已全部通过;2、检查提交文档是否已齐全;3、 标识、备份、记录。4、通知相关人。等等. 详见:版本发布前的checkList;) 分分发发R Re el le ea as se e版版 (1、根据安装组的工作计划、根据各客户现行情况,组合出不同的安 装包;2、分发给当次执行安装任务的人。3、通知安装组。 安安排排补补丁丁号号 (1、安排补丁号、发布日期,通常将完成时间相距不远的安排在同一 补丁号中。2、设置VSS权限,根据开发部经理的安排设置。3、通知相 关人,开始执行施变更,并公布预计发布日期、实施建议) 检查是否通过? 测测试试是是否否通通过过? 测测试试是是否否通通过过? 是 否 是 否 是 否 测测试试组组长长:制制 定定测测试试计计划划 (按照签发单,安 排测试人、预计测 试完成时间) 产产生生a al lp ph ha a版版 (开发部内部可产 生多个alpha版) 结结束束(转转入入产产品品实实施施流流程程) 安安装装a al lp ph ha a测测试试 环环境境 2.2. 主版本发布流程主版本发布流程 主版本的发布流程,与补丁的发布流程相比,参与的职能部门个数、次数 明显增多,且设置的检查点也随之增多。 重要的一点,引入客户监督。改变目前的重要的一点,引入客户监督。改变目前的“直到整个版本完全下流水线后,直到整个版本完全下流水线后, 才提交客户试用才提交客户试用”的方法。采取的方法。采取“我们主动争取客户全程参与我们主动争取客户全程参与”的方法,每完的方法,每完 成一个变更,不一定要待版本中的所有变更完成,立刻放上客户使用的测试环成一个变更,不一定要待版本中的所有变更完成,立刻放上客户使用的测试环 境,请客户在线试用并提意见。境,请客户在线试用并提意见。 (此举依赖公司实现远程测试环境)(此举依赖公司实现远程测试环境) 。目的:让。目的:让 客户不仅知道我们在干什么,还知道我们干成什么样,是否满意。尽量让客户客户不仅知道我们在干什么,还知道我们干成什么样,是否满意。尽量让客户 的意见在开发早期提出,越早提出,变更成本越小,且能直接减少后续的补丁的意见在开发早期提出,越早提出,变更成本越小,且能直接减少后续的补丁 发布频率。发布频率。 流程图如下: 主版本发布流程图(下图中每个方框代表一个进程,括号内描述该进程的具体内容。每个进程均要求有物理产出。) 需求阶段alpha阶段 开发阶段 开发人配置管理员测试人/安装人客户需求人 提供发行说明内容 (各需求人提供自己所 辖范围内的说明内容, 参照样本填写) 提出变更请求 (1、填写自己负责的 产品名 版本号 开发计划清单/测试清单 /变更清单(以下简称 清单);2、请求召开需 求澄清会 开始 检入变更计划 (1、检查有无通过澄清会; 2、将一个产品中,各需求人 提出的清单中,已通过澄清 会的内容,合并成一份。从 此本流程仅使用合并后的清 单。3、存入VSS的固定目 录、标Label; 5、通知开发部经理、测试组 长 开发人:执行变更 (1、开发人执行变更;2、 定期向项目管理组汇报开发 进展) 收集、审核发行说 明内容 测试组长:制定测 试计划 (按照清单,制定测试 大纲、测试计划) 安装alpha测试环境 需求确认测试 (确认功能是否满足 需求) 部门内部测试 (alpha阶段的测试, 相当于单元测试,确认 功能是否完整、是否正 常运行、相关手册是否 最新) 制作发行说明网页 (根据收集并审核通过 的内容,制作成适合客 户在线阅读的网页等格 式,变更清单除外) 版本测试 (1、根据测试计划测 试;2、写安装手册) 需求确认测试 (确认功能是否满 足要求,尽可能提 出改进意见) 测试通过? 是否参与? 否 产生alpha版 (可产生若干个alpha版,直 至所有变更完成) 参与澄清会 (对清单提出质疑,预估 开发所需工时) 参与澄清会 (对变更请求提出质颖, 预估测试所需工时) 评审通过? 参与澄清会 (对清单释疑) 宣布变更计划 (由需求总负责人/PM 宣布:1、通知SCM检入 变更计划;2、通知开 发部经理接收任务; 3、通知客户)(完成 时限:上一主版本正式 对外发行前。) 否 为开发部门设置权 限 开开发发部部经经理理:接接收收任任务务 (1、安排开发人、预计开发 完成时间。2、通知相关人) 重新进入开发阶段 是 是 是 否 主主版版本本发发布布流流程程图图( (续续) ) Beta阶段Release阶段 开发人客户测试人/安装人配置管理员需求人 物理配置审核 (1、各类文档有无备齐;2、有 无全部测试通过等等,详见 CheckList) 产生Beta版 (1、关闭VSS权限;2、标 Label;3、编译构建beta版、备 份、通知相关人;3、制作变更清 单网页.等等,详见执行列 表) 客户是否 参与测试? 验收测试 (1、根据测试计划测 试;2、回复测试结果 (含邮件、上传VSS、 书面三种方式) 安装记录 安装Beta测试环 境(公司内部用) (1、根据测试计划、 安装手册,安装测试 环境(可能有多套环 境),验证安装过程是 否正确;2、通知 SCM、测试组、刷新 “公司内部产品试用 环境一览表”) 安装Beta测试环 境(客户用) (1、根据客户需要, 选择安装环境,并进 行安装;2、通知 SCM、各需求负责人) 验收测试 (1、对产品进行 测试、试用,包 括性能、功能方 面的测试,尽可 能提出意见) 测试通过? 产生Release版 (1、标识、备份、记录。2、通知 相关人。等等. 详见:版本发布前的 checkList;) 分发Release版 (1、根据安装组的工作计划、根 据各客户现行情况,组合出不同 的安装包;2、分发给当次执行安 装任务的人。3、通知安装组。 物理配置审核 (1、各类文档有无备齐;2、有 无全部测试通过;3、检查变更清 单网页。4、下一主版本计划已备 妥等等,详见CheckList) 否 是 结束(转入产品实施流程) 是 否,重新进入开发阶段 2.3. 产品实施流程产品实施流程 为方便大家更加理解软件的整个发布循环过程,在此简单介绍软件通过 Release 阶段后的实施流程,它包括安装、培训等内容。具体的规范制度,以实 施部门制定的为准。 产品实施流程(为方便理解,下图作出简单介绍。具体详细的流程以实施部门制定的为准。 配配置置管管理理员员客客户户支支持持部部 实实施施经经理理:制制定定实实施施计计划划 (制定具体的实施计划,含:时间、地点、人 物、实施内容、实施策略。) 分分发发R Re el le ea as se e版版 (根据实施计划,分发出当次实施所 需产品、相关文档) 实实施施人人:准准备备 (指前期准备工作,包括:与客户约定时间、 安装包整理、任务书编写、提交说明文档给客 户.等等一切能提前在公司完成的工作) 实实施施人人:执执行行计计划划 实实施施人人:反反馈馈执执行行结结果果 (1、通知相关人。2、返回相关文档。例如:特 定用途备份文件、客户签字后的任务书等。3、记 录结果。其中,安装记
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号