软件发布管理流程规范11.docx

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