利用 Zadig 多云周部署千次，持续交付全球业务

iMile 是一家跨境电商物流初创公司，提供中东和拉美等新兴市场的物流服务，通过自建快递团队、精细化运营和互联网技术手段，致力于完善跨境物流的末端一公里。iMile 已成长为中东 Top 3 的跨境电商物流服务公司，同时也是当地行业内发展速度 Top 2 的技术效益丰硕的物流公司。

痛点分析

在以往的业务研发过程，我们遇到如下的痛点：

1. 环境治理复杂：dev、fat、lpt、uat、prod 等多套环境分布在不同地区的数据中心，使用 Jenkins 流水线部署交付需要大量人工干预。
2. 研发效率低：研发团队程序调试、联调测试环境不够友好，经常需要在多个环境的不同版本里来回切换协助测试、前后端排查问题，研发时间被占用。
3. 测试资源不足：排期项目与日常迭代经常混合在同一套测试环境里测试，大量代码变动时部署并行效率不高，影响测试进度。
4. 维护成本高：服务部署使用 Jenkinsfile + YAML 的方式，每个工程需要维护一套配置和脚本，当工程越来越多时，维护成本会越来越重。

Zadig 之旅

在选型 Zadig 之前，我们有多套 K8s 集群，分别部署在了多个不同的数据中心，使用 Kubeboard 进行多集群统一管控，对集群统管暂无其他特殊需求。

偶遇 Zadig

无意中在 B 站看到了 KodeRover Workathon 的线上分享（如下图），就开始同团队成员一起研究KodeRover（Zadig）这个产品。发现它与云原生能够非常完美的结合，多集群服务可统一纳管，多流水线并发构建，容器服务可视化交付，面向研发交互友好。

恰巧当时我们研发团队立项一个重构的项目，需要一套独立的测试环境来满足联调测试任务。我们抱着新鲜的态度就部署了一套 Zadig 集群，计划通过它来解决这个项目重构的测试环境需求。通过 3 天时间的摸索沟通交流，我们很快在 Zadig 上部署了前后端工程服务到 K8s 集群。

 网络改造

我们当时网络状况是这样的：办公内网与云端的开发、测试环境内网是连通的，但到 K8s 的 Service 和容器网络层并未打通。

重构项目小组开始使用 Zadig 进行项目测试了，但后端研发同学找到我们提了一个需求“我想 debug 这个服务打断点”。若要实现，则必须将 K8s 内网与办公网全面打通，我们着手对网络进行改造，这样很快研发即可在自己的 IDEA IDE 随时调用、debug 自己的某一个服务。

全面拥抱 Zadig

全面拥抱云原生属于运维体系的进化，那么全面拥抱 Zadig 则是研发体系的进化。

一个月后重构项目顺利上线，整个项目测试未与原有测试环境使用 NS 隔离，未对日常迭代和其他需求的测试环境造成任何干扰，项目部署变得非常容易，可以边调试边查看某个容器日志，对研发同学的操作体验有了质的提升，已经完全抛弃了原先使用 Kubelet 进入容器的种种麻烦。

有了这个正向的反馈，我们随即做了一个决定，将开发环境、测试环境等全面接入 Zadig。

经过 4 个月的磨合，我们将所有开发和测试环境的 K8s 集群接入了 Zadig。代码工程通过 YAML 标准模板导入即可创建部署自己需要的服务。

经过近半年的努力，我们的研发、测试、运维团队已经将所有服务全面接入 Zadig。接入 Zadig 的服务近 400个，一周部署平均近千次，较大的提升了研发效率，让研发专注代码业务实现，测试团队专注质量提升。测试或者验证过程可以在几分钟内随时拉起一套环境，供研发和测试使用，减轻了运维工作量和成本。

简单回顾了一下几个非常重要的需求细节，我们在这几个功能完善之后，将所有集群全部接入了 Zadig。

1. 因我们属于多地域跨云部署，Zadig 默认只有一个镜像仓库，我们如果使用同一个仓库的话，不同集群的镜像拉取和推送都是通过公网进行，拉取速度受到带宽制约，且消耗流量非常多。
2. IM 工具消息提示推送文案优化。
3. 项目权限管理的颗粒化控制。

整体收益

Zadig 通过“工作流”整体串联了 K8s 的各个组件，也串联起了我们整个研发团队，极大的减轻了脚本的维护、环境治理，同时上手也非常简单高效。在项目迭代和交付中起到了极大的帮助，节约了大量的时间成本，让专业的人做“专业”的事儿，让项目研发高效并行，减少团队间的沟通 Gap，给我们的研发交付帮助极大。

总结就是简单，高效！