软件发布之怪现状

虽然有点乱，不做修改，当年的思考就是这样，对错之间正看得出对问题思考的角度和深度的变化。

每次发布在即，总是会测出这样或是那样的问题。
开发人员一声长叹，为什么不早点测出来呢，改的太没底。
测试人员一脸无耐，这个测试过，没问题的，为什么会出问题。。。。。。
什么时候才能稳稳当当的按计划发布，放下心来睡个好觉。。。。。。
-----------------------------------------------------------------------------------------------------------
为什么每次到了软件发布的Release测试中，总是会发现一些新的问题，有些问题往往会是一些非常重要的，修改起来非常困难的问题。
 
是什么原因造成了如此的怪现状。
 
软件发布后，特别是软件项目发布后，一系列的问题层出不穷，原本好好的功能却在发布后失效了。
功能失效、数据库连接失败、服务器异常、服务调用异常。。。。。。
 
开发胆战心惊，测试提心吊胆，发布后从梦中惊醒。
 
马放南山，刀枪入库，虽然很理想，但也期望发布后问题在自己所控之内，睡个安稳觉。

 

我们到底需要一个什么样的版本发布流程？

什么样的版本发布流程会才能保证我们发布的正确？

 

1.系统发布的版本

2.系统发布版本的测试报告

3.系统版本发布的流程：应用服务器、数据库服务器。。。。。。停服务、部署、开服务。。。。。。

4.服务发布成功检验方式：服务器检查、接口检查。。。。。。

5.发布版本最新功能验证（如果可以，使用工具脚本对不涉及数据库信息修改的业务进行自动化验证）

--------------------------------------------------------------------------------

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制，保证软件产品质量的关键过程之一。
参与软件产品发布的人员主要是测试负责人和BM（Build Master）。----这里我们曾称之为Release Manager，负责版本正式发布前的文件组织、过程审查和人员分配。其实是把QA、SCM、测试的活综合了，因此这个角色一般都是由测试人员来担当。
 
公司软件产品发布的规程如下：
1.发布准备。发布之前，所有程序freezed由测试人员进行确认测试；检查BUG追踪系统内登记的所有bug都已经被fixed，或者遗留的bug不影响系统的使用，如果有严重bug未解决（级别为must fixed）不能发布；----所有的问题都必须确认，针对系统有最终的结论，有效的风险评估。
　 程序打包前做冒烟测试。---如果是经过测试严格测试过的、并最终验证过的版本，可以将最终测试做为冒烟测试，并最终打基线发布版本。
2.测试负责人编写release产品质量报告进行质量分析和总结。
3.源码、文档入库。源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有源代码；文档包括需求、设计、测试文档，安装手册、使用手册、二次开发手册、产品介绍（ppt）、使用demo等。
4.BM进行程序打包；标记源码、文档版本tag。 -- BM, Build Manager
5.BM填写发布基线通知并通知相关人员

　 BM经理对发布基线进行审计。
6.在BUG追踪系统上新建产品发布计划，填写配置项，执行发布计划（发布产品）。
7.上传程序包、使用文档至download站点。
8.编写发布说明readme.txt（或者release note）。

• Readme的内容应该包括产品版本说明
• 产品概要介绍
• 本次发布包含的文件包、文档说明
• 本次发布包含或者新增的功能特性说明
• 遗留问题及影响说明
• 版权声明以及其他需要说明的事项。

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

　　产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch或者按照流程重新发布。
11、临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员,BM需要为源码、文档打tag标记。