软件发布管理流程规范.doc

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