1、软件发布流程1、目的规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。2、范围适用于公司所有电商项目和产品3、发布人员Dev 环境由开发人员内部负责（开发分支）Alpha 环境由测试负责人负责Beta 环境由运维负责正式环境由运维负责*数据库操作均由 dba 统一负责4、发布流程1、提交测试开发人员经过自测（单元测试） ，在 handoff 通过后提交测试代码测试人员通过自动发布工具部署测试环境（alpha）2、预发布（beta）测试人员在 alpha 环境测试并跟踪修改 bug 达到上线标准（没有 A、B 级 bug，C级 bug 少于 20%）时。开始部署 beta
2、 环境，有测试发起走邮件发布流程。3、验收测试测试人员对现有功能在 beta 上进行验收测试（重新执行 case） 。紧急 Bug 修改走补 丁/merge 流程。不影响功能的 bug 留到下次版本解决。确认达到上线标准。4、正式上线测试人员发起，通知相关部门人员配合发起上线操作（具体走发布流程邮件） 。测试人员在线上进行冒烟测试， （紧急 Bug 修改走补丁 /merge 流程。不影响功能的 bug 留到下次版本解决。 ） 。通过后回复邮件，发布结束。5、总结报告测试负责人编写测试总结报告。5、邮件格式1、稳定版：a)提前一天通知邮件：QA 部门将于*月*日*时（周几）锁定代码，进行稳定版制
3、作，需要某某，某某某。 。 。提供支持。稳定版制作完成后再提交代码需要走 merge 流程。本次修改内容：1、登陆样式调整2、第三方登陆3、登陆按钮位置调整b)正式开始时，请直接回复此邮件稳定版制作开始，代码权限开放，请某某开始操作c)运维， DBA 在进行操作时均需要回复次邮件，并说明操作步骤。发布完成后运维回复邮件通知 QA 进行测试*上线流程同上，均需要通过邮件进行步骤流转。最后测试人员在线上冒烟测试结束，回复邮件，发布结束。2、merge/补丁：a）邮件内容：Bug 号+简单描述修改文件名Review 人Review 人员帮助审核并回复邮件b）运维人员发布回复补丁邮件提醒 QA 进行验证，QA 验证通过并结束此邮件。 （如不通过继续流转此邮件）
