在生产中使用金丝雀部署来进行测试

根据Nolio发布的DevOps最佳实践系列中的第一个demo,很多公司通过路由策略选择性地对部分用户发布新功能从而使用 “金丝雀部署(Canary Deployments)”来测试生产中的软件,并将这一方式作为其可持续交付的一部分。“金丝雀部署”是增量发布的一种类型,它的执行方式是在原有软件生产版本可用的情况下,同时部署一个新的版本。同时运行同一个软件产品的多个版本需要软件针对配置和完美自动化部署进行特别设计。

考虑到A/B测试和预防性(pre-emptive)性能测试,一旦克服了“金丝雀部署”所涉及的技术挑战将可以减少部署流程中的风险。A/B 测试允许在不改变大多数用户的用户体验的情况下进行对新功能的测试。而性能测试对于整个用户群体来说同样只会产生微不足道的影响。

根据Nolio的“金丝雀部署”,该方式由以下几个步骤组成:

  1. 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。
  2. 从负载均衡列表中移除掉“金丝雀”服务器。
  3. 升级“金丝雀”应用(排掉原有流量并进行部署)。
  4. 对应用进行自动化测试。
  5. 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
  6. 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)

Nolio在他们的相关介绍中针对如何使用他们的产品对“金丝雀部署”进行高层次软件编配做了概览。他们使用了一个可在多个流程中复用的应用模型,并通过数据来驱动该模型的用途。管理和报表都将随着“金丝雀部署”而被完成。

注释:矿井中的金丝雀(canary in a coal mine) 17世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;而当瓦斯含量超过一定限度时,虽然鲁钝的人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”,以便在危险状况下紧急撤离。

所以,在BOSH部署CF某个版本release的过程中,对于部署了多个节点的组件,首先会经过离线、构建、配置和自动化测试之后才会重新通过NATS与现有系统相连,并更新其他节点。否则,这个版本的release将不会部署到其他节点上,Canary节点也会被回滚。

查看英文原文

视频地址

浙江大学SEL实验室是本网站上所有页面设计、页面内容的著作权人,对该网站所载的作品,包括但不限于网站所载的文字、数据、图形、照片、有声文件、动画文件、音视频资料等拥有完整的版权,受著作权法保护。严禁任何媒体、网站、个人或组织以任何形式或出于任何目的在未经本实验室书面授权的情況下抄袭、转载、摘编、修改本网站內容,或链接、转帖或以其他方式复制用于商业目的或发行,或稍作修改后在其它网站上使用,前述行为均将构成对本网站版权之侵犯,本网站將依法追究其法律责任。
本网站与他人另有协议授权下载的或法律另有规定的,在下载使用时必须注明“稿件来源:浙江大学SEL实验室”。

Leave a Reply

Your email address will not be published. Required fields are marked *