软件版本发布是一件很重要的事，作为客户不知道也无需关心具体发布过程，然而在内部并未准备充分时，面临客户催促发布，压力则随之而来，若一味按客户意愿进行发布，可能将产生无法预计的后果，团队士气降低，客户也会投诉。
针对这点，我积累的一些心得分享，要点就是：建立上线发布流程，发布评审实事求是，通过沟通协调与客户共同面对压力。
1、风险点分析
运维执行命令——分别做哪些，哪些会有风险？如：执行数据库配置文件修改，可能导致一定时间内数据库无法访问，期间统计数据会暂停更新
停服业务影响——根据本次发布的版本，确定业务影响范围，是否能接受最大风险？如：发布期间，域名禁止访问，网站无法打开，用户可能会投诉；业务交叉点多，某个地方异常可能引起其他模块多个bug
冒烟测试问题修改——运维执行发布后，测试进行冒烟测试，若重要业务功能出现bug异常，短时间内无法修复如何处理？
2、维护时间
开始发布时间——早上、下午还是晚上？发布是否会影响用户正常使用，哪些时段是用户使用高峰期
运维发布时间——不同项目发布难度、工作量不等，运维执行本身时长需要考虑在总体维护时间内
冒烟测试时间——每次发布评估冒烟测试时间，并预留一部分问题修改时间
3、值守人员
包含运维、开发、测试、产品以及客户，若是紧急发布，这些岗位人员缺一不可，毕竟发布过程是一个团队协作事情，没人能确保上线一个问题不出，若不满足，则不建议发布。
综上可以通过内部评审把几个要点都梳理一下，最好能把客户拉进来评审，时间久了对方也能了解发布过程的难度及风险。最后把相关风险整理发送客户，若客户执意要发布，则正式邮件告知风险，执行发布。
这个过程中，对于负责人沟通协调能力有一定要求，需要坚持原则，尽可能与客户沟通谈判达成自己的目的。
