软件发布管理流程规范

1、软件发布管理流程规范编 带0: 审核：日期：版 本：编 号：密级：修改历史修改时间修改人修改原因版本目 录1目标42. 发布流程42.1. 补丁发布流程42.2. 主版本发布流程62.3. 产品实施流程92.4. vss管理流程103. 相关资料111. 目标1、减少交叉沟通。通过将发布过程流程化，使每一个环节的执行者都非常 清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻 找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询 才能掌握的现象。减少交叉沟通成本。2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节 执行人能迅速在早期预算出自

2、己的“参与时间”、“参与内容”、“参与工作量”， 主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突， 便能立刻“报警”，报得越早，越能提前应对，减少损失。3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道决于上述“1、减少交叉沟通”）、便能随时掌握路面交通状况，配合可预见的行车计 划（取决于上述2、提高工作预见性”）、当然更能向车队提供有价值的消息。因此， 车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。2. 发布流程本章节的流程图中，将使用下列简称。1、需求组（人）：包括需求总负责人（或pm）、各模块需求负责人。2、开发部（人）：包括技术

3、开发部全体成员。3、配置管理员：或简称scm,包括技术研发部的配置管理组成员。4、测试组（人）：包括测试组所有固定资源、临时调配资源。5、安装组（人）：包括负责公司内部、客户现场的安装、调试的人员。6、客户：所有使用我司产品的用户。2.1.补丁发布流程软件产品的某个主版本向外发布给客户使用后，发现了错误。若这个错误给 客户造成了很大的影响，等不及下一主版本，需要立刻修正，我们就需要发布补 t （对应vss上的存放目录：patchx.y）（注：所有补丁要求合并入下一主版 本）。流程图如下所示。（k爭先征得需）求澄清介的同总再填补签发单。2、通知开.发经理）开发部经理：接收任务（1、安捋开处 人.

4、预计开发完 成时间。2、通知.捡査是否通过？补丁发布流程:卜妙i嗨个方槛代衷 个进稈括兮内描述该进稈的具体内容.每个进柑均要求相应职位如；#；开始检査（k检含施两个环肓填耳的签发单足否符合填巧冬求：检令描述是否 清瞅时间妥求仃无冲突：）安排补丁号丄 安捋补j 丄布11期通常将完成时间相距不远的安ft在同 补号中 2。设汽vss权限.魁r开发部经理的安排设宜:仁通知相 关人，开始执行施变里.卅公布预计发布h期、买施址议）s1开发人：执彳亍变更按照要求,修改代码.文档，龙成后按規世特放）产生alpha版（开发部内部可产哆个叱）hajq安装“1;爪测试环境部门贏测试（、alphas段的测试，相当于单

5、尤测试。2、通知scm）清试是否通过-测试组长：制定测试计划（按照签发单安 川测试人、预计腐 试完成时间）安装beta测试环境 产生beta版（k编写/更新补丁安u.检査相矣文档崔否c备齐：沢根按签发单.检傅气耐补j w捉fffi： 2、选择测：出的变更於否邯（2执低九 检金开发人任checkln/oim的过:种人足笛境.安毂补j betapife：f合vss管理规瓶 2本理规 iv岂签发单制作补丁发行说吋人通如测试组、相关:伉关闭vss权6.编译构建bold版:7.通如测试乳 安诚组 |可其人同时刷新“公诃内摄 补的巧血笏发单»部产品试用环境一赁*白板）验收测试（k bet段的测试

6、丿郴当于集成测试2、通知相关人测试结：果含邮件、签发单电子格式的凹复。若测试通过,則还包拈在丹血签发单上签名。）产生release版n 检测试结果足否lt全部通过：2.检俺捉交文档足占lt齐全：3j标识、备份记求。4.通勿闭|关人。w-详见：版本发布前的checkljstj :）分发release版（k根据安装组的工作计划根拯备客户现行情况.组合出不同的安装包：2、分发给当次执行女裝任务的人.:人通知女装组.2.2.主版本发布流程主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、次数明 显增多，且设置的检查点也随之增多。重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后

7、， 才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完成 一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境, 请客户在线试用并提意见。（此举依赖公司实现远程测试环境）。目的：让客户不 仅知道我们在干什么，还知道我们干成什么样，是否满意。尽量让客户的意见在 开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁发布频率。流程图如下：主版本发布流程图（下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求有物理产出。开始（1.填写自己负责的产品名版本号 开发计划清单/测试清单 /变更清单（以下简称 清单）；2、请求召开需 求澄清会参与澄清

8、会（对清单释疑）是宣布变更计划（由需求总负责人/pm宣布：1.通知scm检入变更计划；2、通知开发部经理接收任务：3.通知客户）（完成时限：上一主版本正式对外发行前。提供发行说明内容 （各需求人提供自己所 辖范囤内的说明内容， 参照样本填写）参与澄（对淸单提岀质疑，预估开发所需工时）参与澄清会（对变更请求提出质颖.预估测试所需工时）开发部经理：接收任务（1、安排开发人.预计开发完成时间。2、通知相关人）开发人：执行变更（k开发人执行变更：2.定期向项目管理组汇报开发进展）产生alpha版（可产生若干个alpha版，直至所有变更完成）安装alpha测试环境检入变更计划（k检查有无通过澄淸会：2.

9、将一个产品中，各需求人提出的淸单中，已通过澄淸»会的内容，合并成一份。从此本流程仅使用合并后的清单，3.存vss的固定目录、标label:5.通知开发部经理.测试组长为开发部门设置权限收集、审核发行说明内容否测试通过?制作发行说明网页 （根据收集并审核通过 的内容，制作成适合客 户在线阅读的网页等格 式，变更清单除外）需求确认测试（确认功能是否满足 需求）部门内部测试（alpha阶段的测试，相当于单元测试，确认功能是否完整.是否正常运行、相关手册是否餒新）盍新进入开发阶段测试组长：制定测试计划（按照清单.制定测试 大纲、测试计划）版本测试（1.根据测试计划测试：2、写安装手册）需求确

10、认测试（确认功能是否满 足要求，尽可能提出改进意见）主版本发布流程图（续）物理配置审核各类文档有无备齐：2、w无全部测试通过等等.详见（checklistj >产生beta版（1、关闭vss权限：2、标'label 3 编译构sbeta版.备i份、通知相关人：3、制作变更清单网页等等，详见执行列勳）安装beta测试环:境（公司内部用*k根据测试计划安装手册.安装测试环境（可能有多套环境）.验证安装过程是否正确：2.通知scm.测试组、刷新公司内部产品试用.环境一览表”安装beta测试环境客户用1、根攝客户需要选择安装环境，井进行安装：2.通知scm.各需求负责人）c 安装记录验收

11、测试（u对产品进行|测试、试用.包括性能、功能方面的测试.尽可能提出意见）验收测试.k根据测试计划测 试：2、回复测试结果含邮件.上传vssj书面三种方式）否.重新进入开发阶段是:物理配置审核：1、各类文档有无备齐：2、w无全部测试通过：3、检査变更淸单网页4.下一主版本计划已备妥ww.详见 <ch«cklist> ）产生release版标识、备份、记录.2、通知相关人。等等详见：版本发布前的checklistl :分发release版k根据安装组的工作计划.根,据各客户现行悄况.组合出不同的安装包：2、分发给当次执行安装任务的人.3.通知安装组.结束（转入（产品实施流程2.3.产品实施流程为方便大家更加理解软件的整个发布循环过程，在此简单介绍软件通过 release阶段后的实施流程，它包括安装、培训等内容。具体的规范制度，以实 施部门制定的为准。2-4- vss管理流程简单介绍vss的使用流程如下，具体详细的规则另述。新同事一 一老同事一用人部门经理：捉出（1、提出新增用户要求;2、提出权限要求）用户本人:提出（向部门经理提出调榕权限要求）scm：新増用户：（u新增帐号;2、分配权限；3、通知用户木人及部门经理）