非码用 Zadig 实现15 万家门店周发布 7 次
我们需要非常快速的迭代节奏，客户爸爸说明天上，通宵熬夜也要完成目标，一周 7 次迭代也是常有的事：没有 Zadig, 我们的自动化测试不可能做起来，更不可能满足客户的需求。有了 Zadig 的环境治理能力，自此我们的开发专心做 coding，环境构建部署交给 Zadig；测试专心写用例，环境资源交给 Zadig；运维专心做维护，服务管理交给 Zadig；不仅大大缩减了我们在上线前的迭代效率，稳定的环境也提供了大家对上线质量信心在使用 Zadig 的 2 年中，我切身感受到这个产品的前瞻性，是非常具有创新性的产品，可以说给整个行业带来了新的 软件交付 3.0 时代。Zadig 已经开源，相信会有更多企业感受到其魅力！
非码科技质量部技术负责人：钱娟娟
写在前面
非码是为新零售行业的每一个商家提供解决方案，面对的客户是每一个开门做生意的门店。
你可能没听说过非码，但你一定听说过：
对！从蜜雪冰城到麦当劳，从老乡鸡到星巴克，他们都是非码的客户！
你也看到了，非码服务的客户大多是一线标杆商户，为了吸引消费者，每季更新新品菜单、每个节日花样大促、会员节优惠狂欢、紧跟热点的游戏上线等等都是非常经典的营销。为了帮助客户达成市场营销策略，我们需要非常快速的迭代节奏，客户爸爸说明天上，通宵熬夜也要完成目标，一周 7 次迭代也是常有的事。
同时，因为常常有火爆的活动引流，高并发是我们经常面临的真实场景。所以在上线之前，除了保障功能可用性，系统稳定性也是我们非常重要的指标，在大型的活动，如为了保障我们其中一个大客户的 88 会员节活动，我们甚至会提前三个月做准备，包含功能迭代封版、系统调优、高可用测试、全链路性能测试，使得服务单接口的性能指标要达到过万的并发能力。
非码业务架构概图：
要知道非码面对的商家，在系统中可能是一串代码一条数据，但门店店员直面消费者，系统出了任何问题都会被当面质问。我们自己在生活中也是一个个消费者，试问你开开心心去门店消费，打开手机下单却提示你「系统异常」、明明有优惠券却使用不了、付了钱店家却说没收到订单......，想想都觉得美好的心情被破坏。可想而知，门店的压力非常之大，我们也必须要具备高效故障定位能力、并能迅速测试后 Hotfix，第一时间解决客诉。
初遇
我们拥有着复杂的业务系统，面临着新零售行业高频迭代、高并发场景，产品质量和稳定性是最根本目标。为了达成这个目标，我们一步步摸索着，逐渐开始了技术转型和测试转型。
首先是技术转型。 非码前期服务为了更快迭代功能，选择以项目制开发，服务端有各自的实践方式，在系统技术架构上缺少设计。随着业务发展，服务端选择不再项目制的重复造轮子，使用微服务最佳实践作为核心，减轻之前积累的技术包袱。
接着我重点谈下测试转型。 刚开始和很多创业公司一样，测试的作用集中在黑盒测试，瀑布式的按部就班作业，等待运维维护环境、等待开发提测(开发晚提测也只能催)、手工点点、上线回归，顺便疑惑怎么测试环境没有这个问题？
随着非码的业务发展和技术转型，从1条业务线扩展为 2 条、到后面的 5 条业务线，业务线之间也并不完全独立，有定制化有产品化，有基础服务也有聚合服务，微服务数量呈几何增长速度。测试的工作量和复杂度有了非常大的挑战，我们开始思考，开始了测试的转型之路。
首先是拒绝被动，测试人员要「走」出去，质量保障是一个过程，不是一个结果。走到开发的前面和产品沟通用户需求，利用自身的优势--比产品懂技术、比开发懂业务，需求阶段和开发设计阶段就可以排雷。另外一点是走到上线的后面，关注用户反馈和影响范围，分析系统稳定性和测试质量的薄弱之处。
其次是自动化测试，（一般提到测试进阶第一个想到的就是自动化测试，我们认为自动化测试是测试转型的一种途径，不是目标，先摆正思路更重要），在团队只有业务测试人员的背景下，我们第一选择是通过开源测试工具实现自动化，但多数偏向于个人不便于团队协作。秉承着发挥自动化最大价值的初心，我们慢慢通过开发一些提高效率的小工具，最终选择以接口测试为切入点自己写代码实现自动化（UI 自动化试点后，发现我们业务特性不适合）。我们多线业务，且业务灵活度较高，服务接口变化也很快，通过学习和逐步尝试，针对我们业务特性，设计了接口结构灵活变更的自动化方式（Python+unittest 后改版为 Python+pytest），结构概要如下：
最后是环境管理，自动化完成后也遇到了诸多落地困难，我们之前的环境都是虚机，环境部署无法自动化，也就无法保障自动化测试的代码最新版本，想要实现自动化能同步测试不同版本的、不同分支的代码更是困难。除此之外，虚机环境的成本和管理也很难控制，我们推动设立了「测试环境管理员」一职，轮班管理测试环境，缓解了一部分混乱现象，但自动化测试的效益仍被限制。并且开发除去代码开发的时间投入，也花费了大量时间在环境部署、服务联调上。
之后我们又迎来了 Docker K8s 的转型，服务管理有了新的方式，也逐步学习 CI/CD 的高效迭代方式，我们开始摸索自动化和其产生的火花。也在一次技术峰会上，我们 CEO 和 CTO 结识了李倩，邀请李倩给我们做了多次技术分享，李倩对软件微服务快速交付的理念，与当下正在寻求快速迭代解决方案的我们，不谋而合。进而知道了 KodeRover 的产品 Zadig（开源之后的名字，下文统一用 Zadig 这一名称），立刻被这个产品所吸引。
一拍即合
Zadig 最吸引我们的地方便是：
- 快速创建环境。Zadig 基于 K8s NS 支持一键拉起一套新环境，是当下解决我们环境管理痛点的最优解决方案。
- 工作流管理微服务启动顺序。解决了我们技术转型后，服务数量猛增后引发的依赖管理问题。
- 优秀的 k8s 服务编排机制。Zadig 的单个应用可维护 N 个资源控制器，极大降低了维护、排错成本。
我们迅速在团队内部试点 Zadig，选定了我们点餐业务线进行了服务迁移。在之前我们的环境无法严格控制权限管理，测试和运维同学依赖手工构建、部署、服务启动等，有了 Zadig 的快速创建环境，我们对环境进行了重新管理，大致如下：
有了 Zadig 的环境治理能力，自此我们的开发专心做 coding，环境构建部署交给 Zadig；测试专心写用例，环境资源交给 Zadig；运维专心做维护，服务管理交给Zadig；不仅大大缩减了我们在上线前的迭代效率，稳定的环境也提供了大家对上线质量信心。
如虎添翼
同时，因为有了稳定的环境，自动化测试终于真正意义的「自动化」了。 此前，我们自动化测试虽一直都在执行，但其实收益较低且相对滞后，因为无法完全保障测试环境和自动化环境的一致性，也难以做到测试左移。Zadig 便提供了这样的功能，且对接方式十分简单，除了定时任务、测试执行、报告展示常见功能之外，还具有强大的统计分析功能，多维度直观的展示测试自动化的过程、收益。
至此，我们的自动化测试实现了测试左移，使得开发在发版后，立刻知晓自己本次发版质量，在测试人员无需介入的情况下，实时跟进发版的质量问题，并以此结果作为自测的验收标准。
能更早的发现问题、解决问题，使得测试收益最大化，自动化测试执行结果成为质量验收标准的一项重要指标。现在业务线仍在增加、生态也在向支付宝、抖音发力，对此我们有信心做的更好。
