Zadig 将研发复杂性下沉到平台，让开发更聚焦创新

妙盈科技(MioTech) 是一家 ESG 领域的金融科技企业，服务国内外众多大型金融机构。妙盈的基础架构团队一直致力于在持续交付领域通过技术更迭，为开发者提供更便捷和高效的基础平台，提升研发效率，支撑业务的高速发展。

痛点分析

在引入 Zadig 项目之前，我们采用的是 GitLab 的 CI 加上自研的 CD 系统来实现整个部署流程。虽说也能正常工作，但使用和维护起来还是有诸多不便：

1. 需要开发和运维人员熟悉 GitLab CI 的 YAML 配置语言，有一定的学习成本。
2. 修改 .gitlab-ci.yml 需要穿梭于多个项目仓库，不便于统一维护。
3. Runner 在 GitLab 之外，需要单独配置管理。
4. CI 和 CD 的流程不在一个系统里，体验感割裂。
5. 与 GitLab 紧耦合，不能支持其他代码托管平台。

选型之路

带着以上的痛点，并且站在云原生领域蓬勃发展的今天，重新寻找一个体验更好的解决方案的意念越发强烈。

由于我们已经采用了 KubeSphere 作为 Kubernetes 的管理方案，所以对集群管理方面要求并不高，侧重点是在于研发侧的流程打通和易用好用的上手体验。

有两条路径可选择：

1. 使用 DevOps 的一站式解决服务。目前在该领域，国内已有多家公司入场。其中不乏互联网巨头的产品，例如阿里云云效、腾讯云 CODING，以及专业做 DevOps 的公司，例如 JFrog 等。
2. 寻找一个全面拥抱 Kubernetes 和云原生的开源项目。

考虑到团队的规模、技术储备以及公司开放创新的发展理念，我们还是选择了第二条寻找开源的路径。

即便将目光放到开源领域，DevOps 发展至今，开源的 CI/CD 产品品类也已经相当之多。其中不乏有CI 老牌劲旅 Jenkins、CD 强敌 Spinnaker。CNCF 孵化项目 Argo，Flux；以及诸如 Jenkins X，Tekton 之类的产品。

以上这些开源项目各有优势和缺点，有的功能强大但设置复杂，上手难度高。有的易用性还可以但调研下来功能又不太满足需求。机缘巧合，在去年的优秀中国开源原生创企中发现了 KodeRover 创企以及其主推的 Zadig 项目，在官网的横评对比中展现出"过人”的能力，便决定先尝试一下，看看是否名副其实。

简单试用之后的第一印象是：比想象中的还好。部署简单，使用方便，并且一个平台解决了构建、部署、测试、制品管理、定时调度、webhook、通知等方面功能都具备，确实能满足我们的需求。

进一步了解之后，发现 Zadig 的侧重点更加偏向于研发侧的流程打通，面向的重点人群是业务开发和测试工程师，非常符合我们对该平台的定位。并且Zadig 基于云原生的理念开发，以及对 Kubernetes 的全面支持，也与妙盈的全面容器化基础架构建设理念高度吻合。基于以上种种，便与Zadig 结了缘。

落地方案

由于 Zadig 支持 EKS/ACK/GKE 等容器云平台，部署轻松无障碍，所以落地部分其实很顺利。我们采用的部署方式是基于 Kubernetes，采用 Helm 一键在 EKS 上部署。最终使用单独集群部署的方式，并同时管理开发/生产两套 K8s 集群。需考虑预留资源以执行构建任务。同时可配合 autoscaler 使用，增加集群灵活性也可最大限度节省成本。

Zadig 还支持多种统一认证方式，方便对接企业SSO。我们也成功对接了 OAuth 统一认证，用户管理更方便。

成果初现

短暂的尝试之后，我们便开始了线上开发、生产环境的迁移改造工作。截至目前，已将 80% 的部署项目、50% 的构建项目迁移到 Zadig 平台，测试项目也逐步测试和上线的过程中。

整体感受如下：

1. 构建易用：在 Dockerfile 构建完备的情况下，只需编写简单的构建脚本即可使用，使用难度低。亦可对接 GitLab webhook，实现自动触发。

2. 部署易用：通过交付物部署的手段，仅需从镜像 Tag 列表中选取版本即可进行手动部署，或者通过自动同步 Chart 仓库的功能，实现GitOps场景。

3. 测试易用：独立的测试中心设计，屏蔽了 Kubernetes 概念，测试工程师无需关心 Kubernetes 的底层逻辑，只需编写自己熟悉的测试脚本即可方便地利用集群容器资源运行测试 Case，降低了测试人员的心智负担。调试完毕后还可对接到工作流中实现测试自动化。

一句话总结：Zadig 把复杂性下沉到工具端，方便了业务开发和测试的使用，让不同专业的人将能力聚焦在自己的专业领域中。