文档介绍：软件发布管理流程规范编制: 审核: 日期: 版本: 编号: 密级: 修改历史修改时间修改人修改原因版本目录 1. 目标...................................................................................................................................... 4 2. 发布流程.............................................................................................................................. 4 . 补丁发布流程.............................................................................................................. 4 . 主版本发布流程.......................................................................................................... 6 . 产品实施流程.............................................................................................................. 9 . VSS 管理流程............................................................................................................. 10 3. 相关资料............................................................................................................................ 11 1. 目标 1 、减少交叉沟通。通过将发布过程流程化,使每一个环节的执行者都非常清楚自己的产入产出,受谁的影响,将影响谁。当遇到困难时,能明确的定位寻找到关键人物沟通解决。避免当需要获取一件事情的进展情况时,需要广泛征询才能掌握的现象。减少交叉沟通成本。 2 、提高工作预见性。流程一旦启动,流程中的所有人员便被触动。各环节执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”, 主动提前做出安排、准备,避开人力、时间等资源上的冲突。且一旦发现冲突, 便能立刻“报警”,报得越早,越能提前应对,减少损失。 3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道(取决于上述“1、减少交叉沟通”),便能随时掌握路面交通状况,配合可预见的行车计划( 取决于上述“2、提高工作预见性”),当然更能向车队提供有价值的消息。因此, 车队领导能做出更有控制力的指令,各车队协调行驶,整个交通自然更受控。 2. 发布流程本章节的流程图中,将使用下列简称。 1、需求组(人):包括需求总负责人(或 PM) 、各模块需求负责人。 2、开发部(人):包括技术开发部全体成员。 3、配置管理员:或简称 SCM ,包括技术研发部的配置管理组成员。 4、测试组(人):包括测试组所有固定资源、临时调配资源。 5、安装组(人):包括负责公司内部、客户现场的安装、调试的人员。 6、客户:所有使用我司产品的用户。 . 补丁发布流程软件产品的某个主版本向外发布给客户使用后,发现了错误。若这个错误给客户造成了很大的影响,等不及下一主版本,需要立刻修正,我们就需要发布补丁(对应 VSS 上的存放目录: Patch[] )( 注:所有补丁要求合并入下一主版本)。流程图如下所示。 . 主版本发布流程主版本的发布流程,与补丁的发布流程相比,参与的职能部门个数、次数明显增多,且设置的检查点也随之增多。重要的一点,引入客户监督。改变目前的“直到整个版本完全下流水线后, 才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法, 每完成一个变更,不一定要待版本中的所有变更完成,立刻放上客户使用的测试环境, 请客户在线试用并提意见。(此举依赖公司实现远程测试环境)。目的: 让客户不仅知道我们在干什么, 还知道我们干成什么样, 是否满意。尽量让客户的意见在开发早期提出,越早提出,变更成本越小,且能直接减少后续的补丁发布频率。流程图如下: . 产品实施流