品牌名称
非码
所在行业
互联网
企业规模
201-500人

非码用 Zadig 实现15 万家门店周发布 7 次

215次阅读

我们需要非常快速的迭代节奏,客户爸爸说明天上,通宵熬夜也要完成目标,一周 7 次迭代也是常有的事:没有 Zadig, 我们的自动化测试不可能做起来,更不可能满足客户的需求。有了 Zadig 的环境治理能力,自此我们的开发专心做 coding,环境构建部署交给 Zadig;测试专心写用例,环境资源交给 Zadig;运维专心做维护,服务管理交给 Zadig;不仅大大缩减了我们在上线前的迭代效率,稳定的环境也提供了大家对上线质量信心在使用 Zadig 的 2 年中,我切身感受到这个产品的前瞻性,是非常具有创新性的产品,可以说给整个行业带来了新的 软件交付 3.0 时代。Zadig 已经开源,相信会有更多企业感受到其魅力!

非码科技质量部技术负责人:钱娟娟

写在前面

非码是为新零售行业的每一个商家提供解决方案,面对的客户是每一个开门做生意的门店。

你可能没听说过非码,但你一定听说过:

undefined

对!从蜜雪冰城到麦当劳,从老乡鸡到星巴克,他们都是非码的客户!

你也看到了,非码服务的客户大多是一线标杆商户,为了吸引消费者,每季更新新品菜单、每个节日花样大促、会员节优惠狂欢、紧跟热点的游戏上线等等都是非常经典的营销。为了帮助客户达成市场营销策略,我们需要非常快速的迭代节奏,客户爸爸说明天上,通宵熬夜也要完成目标,一周 7 次迭代也是常有的事。

同时,因为常常有火爆的活动引流,高并发是我们经常面临的真实场景。所以在上线之前,除了保障功能可用性,系统稳定性也是我们非常重要的指标,在大型的活动,如为了保障我们其中一个大客户的 88 会员节活动,我们甚至会提前三个月做准备,包含功能迭代封版、系统调优、高可用测试、全链路性能测试,使得服务单接口的性能指标要达到过万的并发能力。

非码业务架构概图:

undefined

要知道非码面对的商家,在系统中可能是一串代码一条数据,但门店店员直面消费者,系统出了任何问题都会被当面质问。我们自己在生活中也是一个个消费者,试问你开开心心去门店消费,打开手机下单却提示你「系统异常」、明明有优惠券却使用不了、付了钱店家却说没收到订单......,想想都觉得美好的心情被破坏。可想而知,门店的压力非常之大,我们也必须要具备高效故障定位能力、并能迅速测试后 Hotfix,第一时间解决客诉。

初遇

我们拥有着复杂的业务系统,面临着新零售行业高频迭代、高并发场景,产品质量和稳定性是最根本目标。为了达成这个目标,我们一步步摸索着,逐渐开始了技术转型和测试转型。

首先是技术转型。 非码前期服务为了更快迭代功能,选择以项目制开发,服务端有各自的实践方式,在系统技术架构上缺少设计。随着业务发展,服务端选择不再项目制的重复造轮子,使用微服务最佳实践作为核心,减轻之前积累的技术包袱。

接着我重点谈下测试转型。 刚开始和很多创业公司一样,测试的作用集中在黑盒测试,瀑布式的按部就班作业,等待运维维护环境、等待开发提测(开发晚提测也只能催)、手工点点、上线回归,顺便疑惑怎么测试环境没有这个问题?

随着非码的业务发展和技术转型,从1条业务线扩展为 2 条、到后面的 5 条业务线,业务线之间也并不完全独立,有定制化有产品化,有基础服务也有聚合服务,微服务数量呈几何增长速度。测试的工作量和复杂度有了非常大的挑战,我们开始思考,开始了测试的转型之路。

首先是拒绝被动,测试人员要「走」出去,质量保障是一个过程,不是一个结果。走到开发的前面和产品沟通用户需求,利用自身的优势--比产品懂技术、比开发懂业务,需求阶段和开发设计阶段就可以排雷。另外一点是走到上线的后面,关注用户反馈和影响范围,分析系统稳定性和测试质量的薄弱之处。

其次是自动化测试,(一般提到测试进阶第一个想到的就是自动化测试,我们认为自动化测试是测试转型的一种途径,不是目标,先摆正思路更重要),在团队只有业务测试人员的背景下,我们第一选择是通过开源测试工具实现自动化,但多数偏向于个人不便于团队协作。秉承着发挥自动化最大价值的初心,我们慢慢通过开发一些提高效率的小工具,最终选择以接口测试为切入点自己写代码实现自动化(UI 自动化试点后,发现我们业务特性不适合)。我们多线业务,且业务灵活度较高,服务接口变化也很快,通过学习和逐步尝试,针对我们业务特性,设计了接口结构灵活变更的自动化方式(Python+unittest 后改版为 Python+pytest),结构概要如下:

undefined

 

最后是环境管理,自动化完成后也遇到了诸多落地困难,我们之前的环境都是虚机,环境部署无法自动化,也就无法保障自动化测试的代码最新版本,想要实现自动化能同步测试不同版本的、不同分支的代码更是困难。除此之外,虚机环境的成本和管理也很难控制,我们推动设立了「测试环境管理员」一职,轮班管理测试环境,缓解了一部分混乱现象,但自动化测试的效益仍被限制。并且开发除去代码开发的时间投入,也花费了大量时间在环境部署、服务联调上。

之后我们又迎来了 Docker K8s 的转型,服务管理有了新的方式,也逐步学习 CI/CD 的高效迭代方式,我们开始摸索自动化和其产生的火花。也在一次技术峰会上,我们 CEO 和 CTO 结识了李倩,邀请李倩给我们做了多次技术分享,李倩对软件微服务快速交付的理念,与当下正在寻求快速迭代解决方案的我们,不谋而合。进而知道了 KodeRover 的产品 Zadig(开源之后的名字,下文统一用 Zadig 这一名称),立刻被这个产品所吸引。

 一拍即合

Zadig 最吸引我们的地方便是:

  • 快速创建环境。Zadig 基于 K8s NS 支持一键拉起一套新环境,是当下解决我们环境管理痛点的最优解决方案。
  • 工作流管理微服务启动顺序。解决了我们技术转型后,服务数量猛增后引发的依赖管理问题。
  • 优秀的 k8s 服务编排机制。Zadig 的单个应用可维护 N 个资源控制器,极大降低了维护、排错成本。

我们迅速在团队内部试点 Zadig,选定了我们点餐业务线进行了服务迁移。在之前我们的环境无法严格控制权限管理,测试和运维同学依赖手工构建、部署、服务启动等,有了 Zadig 的快速创建环境,我们对环境进行了重新管理,大致如下:

undefined

有了 Zadig 的环境治理能力,自此我们的开发专心做 coding,环境构建部署交给 Zadig;测试专心写用例,环境资源交给 Zadig;运维专心做维护,服务管理交给Zadig;不仅大大缩减了我们在上线前的迭代效率,稳定的环境也提供了大家对上线质量信心。

如虎添翼

同时,因为有了稳定的环境,自动化测试终于真正意义的「自动化」了。 此前,我们自动化测试虽一直都在执行,但其实收益较低且相对滞后,因为无法完全保障测试环境和自动化环境的一致性,也难以做到测试左移。Zadig 便提供了这样的功能,且对接方式十分简单,除了定时任务、测试执行、报告展示常见功能之外,还具有强大的统计分析功能,多维度直观的展示测试自动化的过程、收益。

至此,我们的自动化测试实现了测试左移,使得开发在发版后,立刻知晓自己本次发版质量,在测试人员无需介入的情况下,实时跟进发版的质量问题,并以此结果作为自测的验收标准。

能更早的发现问题、解决问题,使得测试收益最大化,自动化测试执行结果成为质量验收标准的一项重要指标。现在业务线仍在增加、生态也在向支付宝、抖音发力,对此我们有信心做的更好。

undefined