软件低风险发布

软件低风险发布

高频发布

互联网企业的高频发布是一种趋势

收益

  • 有更多的机会与真实用户互动,从而快速决定或调整自己产品前进的方向
  • 由于每次变更规模较小,软件系统没有剧烈的变化,从而降低部署风险
  • 单次部署成本降低,且趋于恒定
  • 出现问题易定位、易修复,且能快速更正

降低发布风险的方法

蓝绿部署(blue-green deployment)
  • 是指准备两套完全一致的运行环境,其中一套环境作为正式生产环境,对外提供软件服务。另一套环境作为新版本的预生产环境,部署软件的新版本,并对其进行验收测试
  • 当确认预生产环境没有问题后,将访问流量引流到这个新版本的环境中,作为正式的生产环境,同时保持旧版本所在环境不变
  • 直至确定新版本没有问题后,再将旧版本所运行的环境作为下一个新版本的预生产环境,部署未来的新版本
  • “蓝”和“绿”仅代表两个互相独立的部署环境
滚动部署(rolling deployment)
  • 是指从服务器集群中选择一个或多个服务单元,停止服务后执行版本更新,再重新将其投入使用。循环往复,直至集群中所有的服务实例都更新到新版本
金丝雀发布(canary release)
  • 是泛指通过让一小部分用户先行使用新版本,以便提前发现软件存在的问题,从而避免让更多用户受到伤害的发布方式
灰度发布
  • 是指将发布分成不同的阶段,每个阶段的用户数量逐级增加。如果新版本在当前阶段没有发现问题,就再拓展用户数量进入下一个阶段,直至拓展到全部用户。例如1%、5%、10%、50%、100%等多个阶段
暗部署(dark launch)
  • 是指功能或特性在正式发布之前,将其第一个版本部署到生产环境,以便在向最终用户提供该功能之前,团队可以对其进行测试,并发现可能的错误
  • “暗部署”中的“暗”字是针对“用户无感知”这一点而言,这可以通过开关技术来实现

高频发布支撑技术

功能开关技术

  • 什么是“功能开关技术”?
    • 从代码的角度来讲,每个开关的本质是一个“if…else…”条件语句块
  • 开关技术在高频部署中赋予了两种新的用途
    • 隔离。即将未完成功能的代码隔离在执行路径之外,使之对用户不产生影响
    • 快速止血。一旦生产环境出了问题,直接找到对应的开关选型,将其设置为“关闭”
  • 开关技术遵循的原则
    • 在满足业务需求的前提下,尽肯能少用开关技术
    • 如果在“分支”和“开关”之间选择,尽可能选择开关技术。可以在主干上与他人代码频繁集成,尽早发现设计冲突问题;创建分支会带来后期的分支合入以及多次测试成本
    • 软件团队应对开关配置项进行统一管理,方便查找和查看状态
    • 尽可能使用统一的开关框架和开关策略
    • 定期检查和清理不必要的开关项

数据迁移技术

  • 只增不删。“字段尽可能只增不删”,即对数据库表中的原有字段不再进行修改和删除操作
  • 数据迁移5个步骤
    • 为数据库结构增加一个新版本
    • 修改应用程序,同时向两个版本的结构中写入数据
    • 编写脚本程序,以后台服务的方式将原来的历史数据回填到新版本结构中
    • 修改应用程序,从新旧两个版本中读取数据,并进行比较,确保一致
    • 当确认无误后,修改应用程序,只向新版本结构写入数据。可以将原来的旧版本数据保留一段时间,以防止未预料的问题出现
  • 数据库中两表合并的流程
    • 修改数据库结构。编写对应的SQL脚本并执行
    • 修改应用程序,同时向两个版本的结构中写入数据。在应用程序中,修改代码,支持项两个结构中写入数据
    • 编写一个可离线执行的后台脚本,批量将原来的历史数据回填到新版本的结构中
    • 从新旧两个版本中读取数据,并进行比较,确保一致
    • 当确认无误后(稳定后),修改应用程序,只向新版本结构写入数据
    • 放弃旧版本(这是一个可选步骤)

抽象分支方法

“抽象分支方法”是在不创建真实分支的情况下,通过设计手段,将大的重构项目分解成很多个小的代码变更步骤,逐步完成重大的代码架构调整

优点
  • 重构的同时也能交付业务功能需求
  • 可以逐步验证框架调整的方向和正确性
  • 如果遇到紧急的情况,很容易暂停,而且不浪费之前的工作量
  • 能够强化团队的合作性
  • 可以使软件架构更模块化,变得更容易维护

升级替代回滚

  • 回滚操作通常是将与待修复的问题相关的某次提交以及与之相关的任何提交一同从代码仓库中直接剔除,然后再次提交,等待下一次发布即可
  • 尽可能以代码升级的方式代替二进制回滚

影响发布频率的因素

  • 增量发布带来的收益和可能性
  • 每次发布或部署的操作执行成本有多高
  • 出现问题的概率与这些问题带来的成本有多少
  • 维护同一软件的众多不同版本带来的成本
  • 高频发布模式对工程师的技能要求
  • 支撑这种高频发布所需要的基础工具设施与流程完善性
  • 组织对这种高频发布的态度与文化取向
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Z先生09

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值