0 别把问题想得太复杂

  • 如果有灰度发布的能力,最好白天发布;
  • 如果没有灰度发布,只能在半夜发布。

即使有灰度发布能力,也不要沾沾自喜,好好反思一下你们的灰度发布是否真的经得起考验,还是仅仅是装装样子。

回滚方案最好在上级环境中使用生产数据演练,避免在0.1%的情况下需要回滚时,发现无法简单地通过发布上一版本服务来回滚,届时会非常尴尬。

同时,服务类型也需要考虑,比如大型网络游戏(如《王者荣耀》),都是在午夜时间停服维护,这其实说明了问题。

1 形式上,必须凌晨!

必须得在凌晨上线。程序员的工作有一个“原罪”,就是别人很难看出来你有多努力,尤其是管理层。如果你不上班搞凌晨发布,管理层看不到你的努力,尤其是部门的整体表现。既然能选择凌晨上线,那就凌晨上线!

如果有加班费或者调休补偿,凌晨上线大家嗑着瓜子儿,吃着零食,公司提供的外卖和饮料,像开派对一样,和乐融融地等待凌晨。如果有领导或者HR路过,大家一个个愁眉苦脸,盯着屏幕苦苦思索,心里想,怎么还不结束呢。

即使上线跟你没关系,也要来,大家要在一起,部门派对。技术上早就不需要这么干了,但我们这里就是喜欢看苦情戏,必须得凌晨,只是这种凌晨非彼凌晨,一起开party~

2 说点实际的

外企的发布流程

对于外企来说,发布流程相对规范:

  1. 项目规模小,客户不多:
    这种情况下,随时可以上线,比如一些管理系统或新项目的上线。
  2. 项目规模大,用户量大:
    这种情况下,通常选择访问量较少的时间上线,一般是凌晨,有时甚至是周末的凌晨。
  • 年底会确定下一年的上线日期(release day),每个上线日之间会间隔一个半月,这个周期相当于敏捷开发中的迭代周期。如果业务组有需要,可以通过流程,在规定的上线日之外进行发布。
  • 每年都有代码冻结期(code freeze period),通常是12月冻结一个月,因为圣诞假期维护人员放假,处理问题不方便,所以这个月不允许发布。如果需要发布,需要高级别领导批准。
  • 发布环境分为测试、集成测试和生产环境。测试环境每个组可以自由发布,集成测试环境需要邮件通知支持组进行发布,生产环境只能在发布日发布。发布通常是一键部署(one click deployment),开发组提前在Jenkins或Udeploy等部署工具中写好脚本,经过支持组审核后,由支持组在发布日进行实际操作。
  • 发布日前一周的周五会封闭集成测试环境,各开发组应该提前一周将代码部署到集成测试环境并通过测试,确保发布时风险最小。如果在发布周内发现问题,需要重新部署测试,需要部门领导审批。
  • 发布日一般在美国时间周五下午9点(中国时间周六上午9点),各组提前填写发布申请报告,通过审批后通知支持组进行发布。发布完成后,各组需要在生产环境上确认,没有问题则表示发布成功。

小公司的发布流程

一些小公司的发布流程类似于上述流程,都是敏捷开发流程,发布前在测试环境上测试代码,发布前代码会封版,确保代码质量。

互联网公司发布流程

对于包含高并发组件(如Redis集群、Kafka等)的互联网公司,发布过程更加复杂,不仅需要管理代码,还需要重启中间件,或使用中间件清洗或导入数据。如果能在面试中证明自己参与过发布,并解决过发布中的问题,那么一定能有效证明自己的商业项目经验。

结论

无论是大公司还是小公司,凌晨发布都是为了确保用户影响最小化,同时也是为了在特殊情况下能快速响应并回滚。理解并掌握发布流程,能够帮助开发人员更好地应对上线过程中的各种问题。

关注我,紧跟本系列专栏文章,咱们下篇再续!

作者简介:魔都技术专家,多家大厂后端一线研发经验,在分布式系统、和大数据系统等方面有多年的研究和实践经验,拥有从零到一的大数据平台和基础架构研发经验,对分布式存储、数据平台架构、数据仓库等领域都有丰富实践经验。

各大技术社区头部专家博主。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。

负责:

  • 中央/分销预订系统性能优化
  • 活动&优惠券等营销中台建设
  • 交易平台及数据中台等架构和开发设计
  • 车联网核心平台-物联网连接平台、大数据平台架构设计及优化

    目前主攻降低软件复杂性设计、构建高可用系统方向。

参考:


JavaEdge
346 声望410 粉丝