![]()
作者：某车企自动驾驶中心 大数据 SRE 工程师
背景介绍
某头部新能源车企成立于 2014 年，是一家专注研发未来出行的科技公司，用科技创造丰富多彩的出行生活。自动驾驶中心是公司核心中心，致力于构建数据平台全栈自研和数据闭环迭代的能力，为此我们拥有一支多元化创新性人才团队。
作为自动驾驶中心大数据部门 SRE 团队，为自动驾驶大数据业务的高速迭代提供强有力的技术支撑，促进公司的技术创新和产品迭代。
挑战分析和方案思考
从早期的研发到现在的 SRE 工程师，变化的是 从基础设施能力的使用者，转变为基础设施能力的构建者。云原生概念让我感受较深，很多企业各条业务线都选择上云并致力于构建云原生能力，随之业务应用架构也会应变来追求更高的迭代效率，以及更强的稳定性建设。
CI/CD 作为提高软件迭代效率的重要环节之一，起初我们部门使用 GitLab + Jenkins 脚本配置+ 一部分的自动化模式来构建，这个过程中也面临诸多痛点。随着业务的迅猛发展产生越来越多的 Jenkins Job，碎片化脚本导致管理和维护成本过高。
对于交付端混合场景，其部署和运维复杂度都较高，随着项目的增多，以下痛点尤为明显：
基于此，让我们不得不重新思考是否需要迭代一套新的 CI/CD 体系，其中我们调研了 ArgoCD、Tekton 等方案，它们的功能点都较为丰富，并且易于扩展，但是基于它们，我们内部需要花较长时间来构建上层体系，周期较为长。我们亟待建设应用构建与运营一体、权限管控、多环境管理以及效能洞悉等工程能力。
在调研其中，Zadig 开源平台是从朋友处了解到，然后我们就尝试去了解与试用。KodeRover 团队把构建与部署原本繁琐的操作做的简单明了，让使用者或者流程构建者不用太费精力去构建繁琐的步骤， 大部分操作都在一个平台完成，并且丰富的权限管控以及多集群接入等等功能能很好满足我们的需求。在完成调研后，我们选择 Zadig 作为我们下一阶段的 CI/CD 体系建设的重要组件。
落地和实践过程
由于我们大数据部门有大量的采集车，需要对采集车的采集软件平台进行管理以及版本发布，同时内部有很多平台软件，最终我们采用 Zadig 的主机和 Helm 两种方式接入。Zadig 的主机管理方式可以批量管理我们的采集车软件平台，而大数据部门内部的所有平台软件都通过 Helm 方式接入管理，形成了较为统一的 GitLab + Zadig 的管理模式。以下我们对两种接入方式的看法与了解
Zadig 的主机方式：
Helm 场景接入服务 ：
由于我们微服务体量比较可控，根据 Zadig K8s Helm Chart 教程我们很快搭建起来基础的项目环境和工作流，然后采用 K8s 集群拓展不同的测试环境(dev/staging) 来满足不同团队的环境需求。通过 Zadig 环境管理，给研发提供统一协作平台：
![]()
截至目前，Zadig 已经全面推广了，基本上覆盖了 90% 以上业务，研发非常喜欢使用，涵盖了国内和北美团队的工程师日常开发、测试、验证工作。
当前的成果及未来计划
在我们场景下，主要有以下的亮点，让工程师日常工作极其便利：
截至目前，已有 11 个集群，44 个项目、三百多个服务接入 Zadig，满足工程师日常代码验证的需求。
对于未来计划，由于我们有北美的同事，期望 Zadig 可以支持英文版 i18n。我们也会陆续基于 Zadig 构建上层流程体系，也期待 Zadig 能提供更多的扩展能力，让广大的使用者可以较为便捷的将 Zadig 融入公司流程中，并且也希望 Zadig 在扩展能力上发挥更多想象力，集广大的研发能力共同推进 Zadig 的生态建设。
Zadig，开放，链接，专业。
