发布流程
在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。
一、提交测试
1、开发人员在功能开发完毕后首先配置开发环境，并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码，并开始撰写上线方案（上线方案须包括新增的外部应用程序安装，应用程序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本，制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚步骤。）并提交相关技术负责人审核，在审核过后邮件给相关测试人员。
2、测试人员根据参加的需求评审会和模块功能文档，制定测试方案，输出测试用例，特别注意临界点测试方案。
3、测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署，涉及数据库操作可提请DBA操作。
4、记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试结果报告。
5、内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。
二、预热发布
1、测试人员在测试环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C级bug达到要求）时。开始部署预热环境，测试人员对现有功能在预热环境上进行验收测试（重新执行case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决，确认达到上线标准。
2、如达到上线标准，测试人员发起邮件通知相关开发人员、产品人员，准备正式上线发布流程。
三、正式上线
1、在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部署会议，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮件。
2、确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支号给运维人员及DBA，DBA应提前执行数据库脚本，应用部署须通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续应用回滚使用。在部署中出现错误，及时通知相关开发人员。如若问题不能在计划内时间解决，执行回滚方案。
3、运维，DBA在操作完成时均需要回复邮件，并说明操作步骤结果。
4、发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题，提交至开发人员。如若出现问题不能在计划内时间解决，执行回滚方案，并进行迭代改进。
5、（紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决）。测试通过后测试人员回复邮件，发布结束。
四、应用服务监控
1、运维人员添加新增外部应用服务监控和新增云主机的系统监控。
2、运维人员对相关业务保持上线后正式生产系统进行有计划地监控其服务的性能和可用性，及时发现问题处理及反馈问题。
五、总结报告
1、上线成功后，撰写或总结系统需求、架构以及开发文档进行备案。
附：上线流程图
参考：
- 【荐】项目上线部署发布流程(概括)
- 上线流程（个人总结）
- 达达后端代码上线流程演进
- 版本发布流程与规范
- 汽车之家开发团队使用代码发布系统的经验总结
- 团队项目的Git分支管理规范
- [百度文库] 产品发布测试流程
【工作当中的一个：系统测试.发布流程】
1.git分支并不是跟 服务器环境强制绑定的，但通常情况下，test分支的代码对应 测试环境，预发布分支代码 对应于预发布环境，master分支代码对应于 正式环境
2.针对 紧急的bug修复，需要建立一个类似的 bugfix 分支，然后 测试环境需要 拉取 bugfix分支 代码（这个时候就不是test分支代码了）测试人员 先在测试环境过一下，ok，再走一个测试流程