0 别把问题想得太复杂
- 如果有灰度发布的能力，最好白天发布；
- 如果没有灰度发布，只能在半夜发布。
即使有灰度发布能力，也不要沾沾自喜，好好反思一下你们的灰度发布是否真的经得起考验，还是仅仅是装装样子。
回滚方案最好在上级环境中使用生产数据演练，避免在0.1%的情况下需要回滚时，发现无法简单地通过发布上一版本服务来回滚，届时会非常尴尬。
同时，服务类型也需要考虑，比如大型网络游戏（如《王者荣耀》），都是在午夜时间停服维护，这其实说明了问题。
1 形式上，必须凌晨！
必须得在凌晨上线。程序员的工作有一个“原罪”，就是别人很难看出来你有多努力，尤其是管理层。如果你不上班搞凌晨发布，管理层看不到你的努力，尤其是部门的整体表现。既然能选择凌晨上线，那就凌晨上线！
如果有加班费或者调休补偿，凌晨上线大家嗑着瓜子儿，吃着零食，公司提供的外卖和饮料，像开派对一样，和乐融融地等待凌晨。如果有领导或者HR路过，大家一个个愁眉苦脸，盯着屏幕苦苦思索，心里想，怎么还不结束呢。
即使上线跟你没关系，也要来，大家要在一起，部门派对。技术上早就不需要这么干了，但我们这里就是喜欢看苦情戏，必须得凌晨，只是这种凌晨非彼凌晨，一起开party~
2 说点实际的
外企的发布流程
对于外企来说，发布流程相对规范：
-
项目规模小，客户不多：
这种情况下，随时可以上线，比如一些管理系统或新项目的上线。 -
项目规模大，用户量大：
这种情况下，通常选择访问量较少的时间上线，一般是凌晨，有时甚至是周末的凌晨。
- 年底会确定下一年的上线日期（release day），每个上线日之间会间隔一个半月，这个周期相当于敏捷开发中的迭代周期。如果业务组有需要，可以通过流程，在规定的上线日之外进行发布。
- 每年都有代码冻结期（code freeze period），通常是12月冻结一个月，因为圣诞假期维护人员放假，处理问题不方便，所以这个月不允许发布。如果需要发布，需要高级别领导批准。
- 发布环境分为测试、集成测试和生产环境。测试环境每个组可以自由发布，集成测试环境需要邮件通知支持组进行发布，生产环境只能在发布日发布。发布通常是一键部署（one click deployment），开发组提前在Jenkins或Udeploy等部署工具中写好脚本，经过支持组审核后，由支持组在发布日进行实际操作。
- 发布日前一周的周五会封闭集成测试环境，各开发组应该提前一周将代码部署到集成测试环境并通过测试，确保发布时风险最小。如果在发布周内发现问题，需要重新部署测试，需要部门领导审批。
- 发布日一般在美国时间周五下午9点（中国时间周六上午9点），各组提前填写发布申请报告，通过审批后通知支持组进行发布。发布完成后，各组需要在生产环境上确认，没有问题则表示发布成功。
小公司的发布流程
一些小公司的发布流程类似于上述流程，都是敏捷开发流程，发布前在测试环境上测试代码，发布前代码会封版，确保代码质量。
互联网公司发布流程
对于包含高并发组件（如Redis集群、Kafka等）的互联网公司，发布过程更加复杂，不仅需要管理代码，还需要重启中间件，或使用中间件清洗或导入数据。如果能在面试中证明自己参与过发布，并解决过发布中的问题，那么一定能有效证明自己的商业项目经验。
结论
无论是大公司还是小公司，凌晨发布都是为了确保用户影响最小化，同时也是为了在特殊情况下能快速响应并回滚。理解并掌握发布流程，能够帮助开发人员更好地应对上线过程中的各种问题。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都技术专家，多家大厂后端一线研发经验，在分布式系统、和大数据系统等方面有多年的研究和实践经验，拥有从零到一的大数据平台和基础架构研发经验，对分布式存储、数据平台架构、数据仓库等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考：