背景
Lotus，译名路特斯，是一家源自英国的跑车、赛车制造商，以设计与制造划时代的赛车与生产极度轻量和拥有传奇性操控特色的汽车而著名。
“世界上最好的跑车品牌有三个，法拉利、保时捷和路特斯。”
10月25日，路特斯旗下首款纯电 Hyper SUV ELETRE 全球上市，正式向电动化、智能化高性能汽车品牌转型。
王宇，公众号：元汽智驾路特斯：一个传奇跑车品牌的涅槃与重生
随着路特斯的飞速发展，公司创造出的软件规模也日益庞大，基于早期架构设计的 CI/CD 流程难以适应快速变化的交付流程以及高速膨胀的软件数量，变革迫在眉睫。
早期 Lotus 的软件交付流程是基于 Jenkins 流水线设计的，Jenkins 的部署与数据中心一一对应。由于 Lotus 使用的是混合云，且数据中心遍布海外，导致运维需要管理的 Jenkins 数量非常多，大量重复的事务性工作使得运维的人力捉襟见肘。以下是早期方案一些缺陷：
-
多个 Jenkins 环境，配置、插件管理复杂
-
跨集群项目难以同步
-
存在单点故障的隐患
-
脚本分散且存在重复功能，难以复用或更新
-
授权难以管理
在此背景下，
我们开始寻求新的技术方案以解决遇到的问题。
初识 Zadig
第一次认识到 Zadig，是出于一个偶然的机会。当时我们的团队正在寻找比较灵活的权限解决方案，无意间在网上发现了 Zadig 基于 OPA 实现 RBAC 和 ABAC 权限管理技术方案详解[1] 这篇文章，拜读后发现不仅权限方案给了我们相当大的启发，Zadig 本身所宣传的"云原生"、"多环境"、"无缝接入"等功能都非常契合 Lotus 当前改进软件交付流程的需求。在经过多轮方案选型和对比后，最终决定选择 Zadig 作为新一代的 CI/CD 工具。
方案落地
方案确定后下一个步骤就是落地了。在摸索落地的过程中，以下经验和功能给了我们相当大的助力：
确认里程碑
方案落地的第一件事是让进度可度量，针对这一点我们按照环境、部门、稳定使用期等维度拆分了落地的里程碑。
如部门 A 的非生产环境接入并测试完毕时，标示着落地进度达到了一个里程碑，并且可以将这部分 CI/CD 流程切换到 Zadig 执行了；当用户的使用时间超过了稳定使用期，并且日均问题不超过一个时，视为达到了另一个里程碑，并可以尝试归档旧的 CI/CD 流程。
确立里程碑后团队可以随时度量当前的进度，并且明确当前的目标是什么。
*建立迁移文档，方便追踪进度
低成本快速切入
当技术方案在 Demo 环境验证通过后，就需接入真实的项目了，但人的精力是有限的，不可能每一个服务都从零开始编写脚本，创建 YAML 文件。
Zadig 的托管类型项目和构建模板在降低接入成本方面起了很大的作用：
-
使用托管项目只需要选择 K8s 集群和命名空间后创建环境，然后将需要托管的服务勾选添加即可，全程不需要写任何 YAML ；
-
构建模板则降低了编写脚本的工作量，同类型的构建只需要选择模板，然后修改变量即可，并且一个服务的构建只需要初始化一次，多个环境下的同名服务会自动绑定。
*接入一个服务只需要勾选一下就可以了
经验传递
Zadig 落地涉及到的影响范围比较大，无论是从权限还是工作量的角度看，我们的团队都无法独立完成这个工作，如果需要借助外部力量的话，势必需要将我们关于 Zadig 的经验传递给合作方。关于这一点，我们和合作方进行了多次深入的交流和培训，并针对不同的角色编写了使用手册。完善的培训视频和手册大幅降低了我们在落地中后期的沟通成本，并且避免了“口口相传”丢失信息的缺点，让大家可以基于同样的认知进行协作。
*完善的培训视频和手册
用户推广
无论何种工具，被用户使用才是最终的目标。相较于 Jenkins 而言，Zadig 简洁易用的界面、灵活强大的权限管理、对常用 K8s 功能的封装等优点都极大的提升了用户体验，很快就凭借自身的素质在业务部门中赢得了口碑。按现状来看， Zadig 在业务方推广后反响不错，一些原本不在短期接入计划内的部门开始主动过来了解 Zadig，并愿意投入人力来接入使用。
*其他部门主动接触 Zadig
现状
截至目前，已经有 54 个环境，近 300 个服务接入了 Zadig，单日构建数可超过 130+ 次。
亮点功能
托管项目
在方案选型阶段， Zadig 的托管接入模式是其脱颖而出的重要因素之一。该项目类型可以实现零侵入快速接入现有 K8s 服务，并且提供了可满足开发人员日常使用的可视化 K8s 管理功能，为希望从现有 CI/CD 流程切换到 Zadig 的用户提供了一条低成本迁移路径。
????
协作模式
基于 ABAC 权限模型设计的协作模式在推广 Zadig 的过程中功不可没。Lotus 管理 Jenkins 权限是通过插件实现的，该插件控制 Job 权限的方式是将用户和角色平铺成一张表格，通过勾选的方式控制用户权限，在用户数量或 Job 数量比较大时表格会变得异常复杂。之前的解决方案是复用用户，通过限制用户数量的方式来控制表格的规模，这样带来的缺点是审计不准确，无法追踪到操作的具体执行人。而 Zadig 的协作模式支持将用户的权限粒度控制到环境和工作流级别，更贴合企业的安全需求。
????
模板库
在我看来，模板功能是 Zadig 进阶功能中最强大的，毫不夸张的说，活用模板可以为运维降低 90%以上的事务性工作！在最新版本中（v1.15.0）K8S YAML模板已经可以解析 go template 语法，支持在模板中使用判断、循环等复杂逻辑，完全足以支持一套模板覆盖绝大多数场景。目前我们已经可以实现只需维护一套 K8S YAML 模板、一套 DOCKERFILE 模板、一套构建模板便可以满足 95% 的后端项目需求，运维接入一个服务只需要 2 分钟。
????
效能洞察
效能洞察弥补了原始方案在数据统计方面的巨大短板，它不仅支持从全局角度查看所有项目的构建、测试、部署情况（适合高级管理者，如 CTO、运维负责人），还支持从单个项目和时间维度进行分析（适合项目责任人，如TL、业务线运维），为研测环节的效率提升程度提供了数据支撑。
????
期待及建议
没有项目是完美的，以下是 Lotus 在落地过程中遇到的一些实际场景以及相关思考，希望可以对 Zadig 的发展带来积极的影响。
托管项目快速切换至其他类型项目
托管类型的项目是新用户快速接入 Zadig 的利器，但是考虑到可扩展性，最终都需要将托管项目切换为其他类型的项目。由于托管项目中已经保存了项目、环境、服务、构建等资源的关联关系，如果可以提供快速迁移的渠道，必然可以大大提高 Zadig 的用户粘性。
k8s yaml 模板指定范围覆盖变量
当前 K8s YAML 模板实现的思路是：创建模板后，在服务中选择 使用模板新建 会将模板中的变量内容拷贝到新建页面，点击新建时将会根据模板和复制过来的变量生成 YAML，与模板中的变量无关。
痛点：
-
大部分变量只需要初始化，不会频繁变更，但新建 YAML 时需要为每个变量设置值，造成大量冗余的维护成本。
-
变量影响的范围是不同的（有的变量可以被全局共用，有的变量在项目范围内是一样的，有的变量在环境范围内是一样的），目前需要针对每个服务修改。
建议将变量按照数据来源划分级别，不同级别的变量在不同的页面配置，按优先级覆盖变量内容。这样可以在保证模板灵活性的同时，能以最小代价修改指定范围内的变量。
结语
在落地的过程中，我们咨询了很多问题（如缓存如何清理、迁移错误如何处理），也提出了不少建议（如 yaml 模板不够灵活、协作模式不支持自定义工作流），Zadig 的大佬们都非常耐心细致的解决了我们的疑惑，并且在很短的时间内将合理的建议采纳并且上线。这些都说明 Zadig 的背后是一支技术过硬、有匠心精神的团队。
*Zadig 大佬对我们的大力支持
感谢 Zadig 工程师在落地过程中给予的支持！非常期待未来继续与 Zadig 一起，让工程师专注企业创新！
Zadig，开放，链接，专业
帮助企业更高效地交付软件产品！