试管移植 猕猴桃发布管理流程规范

2021年1月22日发(作者：试管移植第三天出血)
共享知识



分享快乐



产品发布管理流程规范






编



制：


审



核：


日



期：


版



本：


编



号：


密



级：







卑微如蝼蚁、坚强似大象

共享知识



分享快乐

目




录

1.
目标
................................ .................................................. ..................................................
3

2.
发布流程
.................... .................................................. .................................................. ....
3

2.1.

补丁发布流程
....... .................................................. .................................................. ..
3

2.2.

主版本发布流程
........ .................................................. ...............................................
5

2.3.

产品实施流程
............ .................................................. ...............................................
8

2.4.

VSS
管理流程

................................................. .................................................. ...........
9

3.
相关资料
........ .................................................. .................................................. ..............
1
0

卑微如蝼蚁、坚强似大象

共享知识



分享快乐

1.
目标

软件产品的发布过程，
需要形成有序的良性循环。
否则，各环节流转中容易
发生相互等待、被动接应的局面。无形中，不断增加了沟通成本，扩大了软件的< br>风险。且对后期造成的影响并不能够完全预知、完全估量。

因此，
根据公司内 部前期已有的习惯，
总结过去产品的发布经验，
分析统计
结果后，特制定本发布过程规 范。预期达到如下目的：

1
、减少交叉沟通。通过将发布过程流程化，使每一个环节 的执行者都非常
清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻
找到关键人物沟通解决。
避免当需要获取一件事情的进展情况时，
需要广泛征询
才能掌 握的现象。减少交叉沟通成本。

2
、提高工作预见性。流程一旦启动，流程中的所有 人员便被触动。各环节
执行人能迅速在早期预算出自己的“参与时间”
、
“参与内容”
、
“参与工作量”
，
主动提前做出安排、准备，避开人力、时间等资源上的冲 突。且一旦发现冲突，
便能立刻“报警”
，报得越早，越能提前应对，减少损失。
< br>3
、
提高可控性。
产品发布就像道路交通。
交通电台有了可靠的消息渠 道
（取
决于上述“
1
、减少交叉沟通”
）
，便能随时掌握路 面交通状况，配合可预见的行车计
划
（取决于上述
“
2
、
提 高工作预见性”
）
，
当然更能向车队提供有价值的消息。
因此，
车队 领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。

一条早已设计好的行 车路线，
加上提前准备就绪的车队人马，
再加上行进途
中密切配合的交通电台。与没有 固定线路，
需要时才去调配车马，
电台信息又不
畅的队伍相比，哪一个更能成功到达目 的地？

2.
发布流程

本章节的流程图中，将使用下列简称。

1
、需求组
(
人< br>)
：包括需求总负责人
(
或
PM)
、各模块需求负责人。
2
、开发部
(
人
)
：包括技术开发部全体成员。

3
、配置管理员：或简称
SCM
，包括技术研发部的配置管理组成员。

4
、测试组
(
人
)
：包括测试组所有固定资源、临时调 配资源。

5
、安装组
(
人
)
：包括负责公司内部 、客户现场的安装、调试的人员。

6
、客户：所有使用我司产品的用户。

2.1.
补丁发布流程

软件产品的某个主版本向外发布给客户使用后，< br>发现了错误。
若这个错误给
客户造成了很大的影响，等不及下一主版本，
需要立 刻修正，
我们就需要发布补
丁（对应
VSS
上的存放目录：
Patc h[X.Y]
）
（
注：所有补丁要求合并入下一主版
本
）
。 流程图如下所示。

卑微如蝼蚁、坚强似大象

共享知识



分享快乐

补丁发布流程：
下图中每个方框代表一个进程，括号内 描述该进程的具体内容。每个进程均要求相应职位填写《补丁签发单》。
需求组
开始
开 发部
开发部经理：
接收任务
（1、安排开发
人、预计开发完
成时间。 2、通知
SCM）
配置管理员
测试组
提出变更请求
（1、事先征得需
求澄清会的同意，
再填《补丁签发
单》。2、通知开
发经理）
检查< br>（1、检查前两个环节填写的签发单是否符合填写要求；检查描述是否
清晰、时间要求有无冲突； ）
否
检查是否通过？
是
安排补丁号
（1、安排补丁号、发布日期，通 常将完成时间相距不远的安排在同一
补丁号中。2、设置VSS权限，根据开发部经理的安排设置。3、 通知相
关人，开始执行施变更，并公布预计发布日期、实施建议）
开发人：执行
变更< br>（按照要求
修改代码、文档，
完成后，按规范存
放）
测试组长：制定测试计划
（按照签发单，安
排测试人、预计测
试完成时间）
产生alp ha版
（开发部内部可产
生多个alpha版）
安装alpha测试
环境部门内部测试
（1、alpha阶段的
测试，相当于单元
测试。2、通知
SCM）
否
测试是否通过？
是
a
l
p
h
a
阶
段
产生Beta版
（1、检查相关文档是否已备齐；2、根据签发单，检查 当前补丁号中提
出的变更是否都已执行；3、检查开发人在CheckIn/out的过程中，是否符合VSS管理规范、版本管理规范；4、根据签发单，制作补丁发行说明
5、关闭VSS权限；6 、编译构建beta版；7、通知测试组、安装组，向其
提交该补丁的书面签发单）
安装Bet a测试环境
（1、编写/更新补丁安
装手册；2、选择测试环
境，安装补丁beta版 ；
3、通知测试组、相关
人，同时刷新“公司内
部产品试用环境一览表
”白板 ）
验收测试
（1、beta阶段的测试，
相当于集成测试
2、通知相关人测试 结
果,含邮件、签发单电子
格式的回复。若测试通
过，则还包括在书面签
发单 上签名。）
否
测试是否通过？
是
B
e
t
a
阶
段
产生Release版
R
e
l
e
a
s
e
阶
段
(1、检查测试结果是否已全部通过；2、检查提交文档是否已齐全； 3、
标识、备份、记录。4、通知相关人。等等...
详见：《版本发布前的checkLis t》；)
分发Release版
（1、根据安装组的工作计划、根据各客户现行情况，组合出不 同的安
装包；2、分发给当次执行安装任务的人。3、通知安装组。
结束（转入《产品实施流程 》）

卑微如蝼蚁、坚强似大象

共享知识



分享快乐

2.2.
主版本发布流程

主版本的发布流程 ，
与补丁的发布流程相比，参与的职能部门个数、
次数明
显增多，且设置的检查点也随 之增多。

重要的一点，
引入客户监督。
改变目前的
“直到整个版本 完全下流水线后，
才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法，每完
成一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环
境，请客户在线试用并提意 见。
（此举依赖公司实现远程测试环境）
。目的：让
客户不仅知道我们在干什么，还知 道我们干成什么样，是否满意。尽量让客户
的意见在开发早期提出，越早提出，变更成本越小，且能直接 减少后续的补丁
发布频率。

流程图如下：

卑微如蝼蚁、坚强似大象