![]()
时谛智能是一家致力于透过科技赋能时尚产业创意开发，从虚拟打样、在线设计、仿真渲染、在线协作到打通生产的一站式数字化平台服务公司，产品包括 Revofim、Versebook、KicksCAD、Versekit 等。
2020 年荣膺《 2020 中国最佳创新公司 50》，2021 年荣膺 《2021 中国工业软件年度企业百强》，同时入围国家工信安全中心 2022 数字化转型优秀企业案例。
在 2022 年之前，在我们公司采用的 CI/CD 工具一直 Jenkins，它是一款由 Java 编写的开源持续集成工具，在互联网企业的自动化工作中应用十分广泛。通过 Jenkins 我们实现了从手动部署应用到自动部署应用的过渡，在此的基础上我们对 Jenkins 进行了二次开发，配合容器化加上 Kubernetes，使得平均部署时间缩短到了 1min 以内，工作效率得到了明显提升。但随着公司业务发展，越来越多的需求出现，Jenkins 开始变得没那么好了，一些痛点也随之暴露出来。
Jenkins的痛点分析
痛点一：Jenkins 在工作流管理、人员管理和权限分配上存在不足，为了解决这种问题我们安装了如 Active Directory、Authorization Strategy 等插件，但使用复杂且难以做到精细化授权。
痛点二：功能比较单一，它像是一个建筑的核心，可以实现简单的工作，但更多复杂的需求往往需要插件的支持和二次开发，而过多插件会使得 Jenkins 维护难度越来越高，同时也增加了安全隐患。
痛点三：多套环境的管理难以通过 Jenkins 来实现，我们采用的是 Rancher + Jenkins 的方式，但是这无疑增加了整体复杂度，无论是开发还是运维，在两套系统之间来回切换是一件头疼的事情。
痛点四：无法进行版本的管理，通常发布一次版本包含了特定的几个服务，可以将这几个服务看作一组应用，当测试通过后若是能一键发布，则将大大提升发版的效率。
团队的期望
不断的对 Jenkins 修修补补，使得运维为满足日新月异的需求而疲于奔命，工作业绩也很难体现。因此，我们意识到需要做出转变了，于是便通过面对面沟通的形式，征集不同岗位同事对于系统的期望，在收集完开发、测试、运维、项目经理的声音后，我将期望总结为以下几点：
支持 Go、Java、Yarn 的构建和部署。
能有效的管理工作流、人员的权限，实现项目间的权限隔离和共享。
支持 K8s-Yaml 模板、构建模板、镜像模板等。
能有效的管理多个版本，支持一键发布、一键回滚。
服务构建、服务部署、服务管理和运维要在同一个系统中，便于操作和数据统计。
UI 界面尽可能简洁美观。
技术选型
基于以上痛点和期望，我们便开始调研解决方案，从开源系统到商业系统都去接触，经过不断碰撞，我将其总结为三个方向进行对比。
1在原有的 Jenkins 基础上开发迭代，以定制化开发为主，结合一些插件使用。
优势：风险可控，并且属于增量迭代，不影响大家一直以来的使用习惯。
劣势：过多插件和定制化开发使维护越来越难，插件也经常提示存在安全漏洞需要更新。
2阿里云效、腾讯 Coding 等商业 DevOps 系统。
优势：经过前沿互联网公司的沉淀，基本能实现所有需求，同时其技术能力、服务水平也值得信赖。
劣势：使公司核心环节过于依赖外部因素，风险高；我司软件为 toB 的软件，后续将会为客户提供部署和运维，无法通过这种方式实现；另一核心问题在于其技术不开源，难以进行有效的定制化。
3开源 DevOps 系统。经过多方对比，Zadig 脱颖而出。
优势：Zadig 系统实现了开发部署各环节大部分需求，使用简单、高效，官方技术解答十分专业有耐心，良好的社区生态。
劣势：涉及到近百个服务和整个产研团队的使用，运维实施存在一定的工作量。同时所提供的开放 API 接口偏少，存在一定的定制化开发的难度（但新版的迭代方向不断在扩充 OpenAPI 和接口使用体验）。
具体实践
综合以上利弊分析，我发现整体看 Zadig 是非常不错的选择，于是决定在公司内进行推广。在引入一个新的系统时，我始终保持谨慎的原则，首先在公司的创新部进行试点运行，然后根据创新部同事反馈结果，决定下一步的方案。
内部试点
通过官方的一键部署脚本，可以很快的拉起 Zadig 系统，然后配置开发、测试、预发布环境，模拟正常开发迭代、部署上线的流程。在公司创新部进行试点 1 个月期间，我们发现了大大小小的 BUG，同时也收集了很多来自同事反馈的需求和建议，这些都反馈给了官方，官方收到我们的请求后也都认真的逐条回复，并对于其中重点问题进行了修改，而对于一些功能上的建议也在后续的版本进行了实现。在此期间，Zadig 社区工程师给我提供了非常重要的帮助，我不得不为他们专业的技术能力和对待问题的认真态度点赞👍👍。
试点总结
内部试点结束后，我收集了创新部同事对于 Zadig 的看法，结果收获了一致好评。大家谈论其优点大致为：
界面美观、操作方便。
将开发测试涉及的流程在一个平台上完成，不需要切来切去。
配置很简单，即使经验少的同事，通过文档也能快速上手。
项目管理、版本管理、人员权限管理设计的很巧妙，体现出设计者对痛点把握十分精准。
如此多的好评，再加上 Zadig 团队积极处理问题的态度和专业的技术能力，我们愉快的决定是时候放弃 Jenkins，开始拥抱 Zadig 了。
全面推动
第一步：环境配置
添加各个环境的 Kubernetes 集群到 Zadig 中，配置构建代码源，镜像仓库，构建镜像等。
创建项目和工作流，接入 AD 域，对每个人员精准授权。
通过模板创建服务，通过变量控制不同环境不同的设置。
通过构建模板，定义服务的构建方式，并可以设置不同环境不同的构建方式。
优化构建缓存、构建顺序提高构建效率。
将服务部署到环境中，通过工作流进行更新。
第二步：理念宣导
因为公司产品研发团队有百来号人，想要将一个大家使用了几年的工具完全替换是一件十分困难的事情，所以为了项目的顺利推进，我们先在公司内举行了一次 DevOps 理念的宣导，对云原生时代所使用的技术做了基本解释，并着重强调了 Zadig 对比于传统的工具其优势所在，以及在不同的解决方案里我们权衡利弊后的选择，会后员工们纷纷表示高度认可此项工作。
第三步：操作培训
通过理念宣导作为基础，后续便针对每个小团队进行专题培训，主要是解释 Zadig 的基本操作，注意事项，以及高阶操作等。然后每完成一个小团队的培训，就将其在 Jenkins 上的工作流都纷纷关闭，使其只能在 Zadig 上完成工作，此过程较为漫长，经过 2 个月的不懈努力，最终将原本在 Jenkins 上的工作流完全迁移至 Zadig。
总结与期望
目前版本 Zadig 已经能够很好的完成绝大多数需求了，同时配合我司项目管理工具的使用，使得版本迭代相关的工作，形成了一个良好的闭环。产品需要精益求精，当功能完善后更应该进行操作体验上的优化，一个微小的细节可能会成为决定成败的关键。
以下是我对 Zadig 的一些期待和建议：
允许更改工作流名称，构建名称。
工作流、环境等命名时支持中文命名。
支持类似于构建模板、构建等可以通过复制的方式创建。
查看日志时为黑底白字且字体小，看久了会很累，建议有多种配色方案且能调节字体大小。
Zadig，开放，链接，专业。
