版本管理软件产品发布流程-2 种说法的分析

liuxue.gu@hotmail.com · 2011年11月25日 · 33 次阅读

作者： jasmine http://www.blogjava.net/jasmine214--love/archive/2011/11/24/364733.html

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制，保证软件产品质量的关键过程之一。参与软件产品发布的人员主要是测试负责人和 BM（Build Master）。

公司软件产品发布的规程如下：

1、发布准备。发布之前，所有程序 freezed 由测试人员进行确认测试；检查 qcs 系统内登记的所有 bug 都已经被 fixed，或者遗留的 bug 不影响系统的使用，如果有严重 bug 未解决（级别为 must fixed）不能发布；程序打包前做冒烟测试。

2、测试负责人编写 release 产品质量报告进行质量分析和总结。

3、源码、文档入库。源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有源代码；文档包括需求、设计、测试文档，安装手册、使用手册、二次开发手册、产品介绍（ppt）、使用 demo 等。

4、BM 进行程序打包；标记源码、文档版本 tag。

5、 BM 填写发布基线通知并通知相关人员；BM 经理对发布基线进行审计。

6、在 qcs 系统上新建产品发布计划，填写配置项，执行发布计划（发布产品）。

7、上传程序包、使用文档至 download 站点。

9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。

10、后续工作。产品发布后，在使用过程中可能还会发现一些 bug。在不影响正常使用的情况下，这些 bug 将在下一版本发布时解决；如果 bug 严重影响使用，必须打 patch 或者按照流程重新发布。

11、临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；BM 需要为源码、文档打 tag 标记。

12、软件产品发布后，即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行，开发人员不能直接从 cvs 或 vss 上 check 代码编译交付用户使用或者进行二次开发。

另一种说法：

公司软件产品发布的规程如下： 1.FAE 首先向版本管理员提交需求; 2.版本管理员将需求提交给项目经理,由经理确认需求以及发布基线; 3.发布准备:发布之前，先将当前主干中的所有程序 freezed,并从主干中拉出一条发布分支 branch,由开发人员对其进行功能测试:检查所有 bug 是否都已经被 fixed，或者遗留的 bug 不影响软件的使用，如果有严重 bug 未解决暂时不能发布。 4.如果测试通过,则由相关开发人员进行程序打包；标记源码、文档版本 tag。 5.开发人员将标记的源码和文档地址交予版本管理员,由版本管理员编写发布说明 release list.release list 内容应包括本次发布包含的文件包、文档说明;各类文件的存放路径,提供者及 tag 信息;本次发布包含或者新增的功能特性说明；遗留问题及影响说明；版权声明以及其他需要说明的事项。 6.管理员在 jira 上建立测试任务并邮件通知相关测试人员。 7.FAE 测试,测试完成后，FAE 向版本管理员反馈测试结果（确认所提需求是否全部实现，不然则列出哪些功能还存在不足或 BUG）:如果测试没有通过，将由版本管理员向开发组请求重新 release 内部版本，再交 FAE 重新测试;如果测试通过，则由版本管理员为当前的版本进行标记和命名,同时提交到发布库中. 8.正式发布通知。邮件通知各相关部门并附上产品发布说明和产品介绍。 9.由 FAE 将发布后的版本打包 release 给客户; 10.后续工作。产品发布后，在使用过程中可能还会发现一些 bug。在不影响正常使用的情况下，这些 bug 将在下一版本发布时解决；如果 bug 严重影响使用，必须打 patch 或者按照流程重新发布。

临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；管理员需要为源码、文档打 tag 标记。
软件产品发布后，即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行，开发人员不能直接从 svn 上 check 代码编译交付用户使用或者进行二次开发。