1.目的
为了规范软件产品的版本发布流程，提高团队发布的可控性。 2.范围 适用于*******所有软件产品的发布。 3.涉及人员 产品经理、研发工程师、运营工程师、测试工程师。 4.软件发布流程 正式环境发布流程如下： 4.1 发布准备 软件开发完成，研发人员完成自测，并确定发布日期 自测应当完成对以下内容的确认： 1) 原有的 BUG 是否彻底解决 2) 增加的功能，修改的功能 3) 新增功能是否能达到需求及设计要求 4) 所做的改变带来的影响 4.2 提交测试 项目组长提出测试申请，并明确以下内容： 1) 软件版本号 2) 新增修改了那些功能 3) 修复了那些 BUG 4) 更改后的影响分析及测试建议 4 4.3 执行测试 测试负责人接手到测试申请后，启动软件测试，完成后反馈测试结果。 测试结果应该包含以下内容： 1) 原有的 BUG 的解决情况 2) BUG 的新增情况 3) 测试用例执行情况 4.4 发布评审 软件经过全面测试后，由项目组全员负责审核并判断软件是否达到发布要求。 发布评审中对软件缺陷的要求是：致命，严重，级别缺陷为 0，一般级别缺 陷解决率 95%，轻微级别缺陷解决率 90%。 说明：缺陷级别划分为四级：致命，严重，一般，轻微。 4.5 程序打包 项目组长安排人员将程序打包，标记源码，文档版本 tag 等。 4.6 编写发布说明 项目组长/产品经理编写产品发布说明 readme.doc(或者 relesse note)。 readme 的内容应该包含： 1）产品版本说明 2）产品概要介绍 3）本次发布包含的文件包，文档说明 4）本次发布包或者新增的功能特性说明 5）遗留的问题及影响说明 6）版权声明以及其它需要说明事项 5 4.7 正式发布通知 进行发布前，需知会发布人。 项目组长以邮件通知领导、运维、开发、产品、测试等人，并附带上本 次发布说明。 邮件内容可主要包含： 1.上线功能的内容描述 2.上线的 Git 项目名和分支 3.今日同项目如果有其他人的分支需要上线提醒他尽快将内容合并到统 一的发布分支上； 4.7 发布验证 项目发布后，产品、研发、运营、测试需验证本次发布的可用性，有无出现 不可用等问题。
