技术选型
基于以上痛点和期望，我们便开始调研解决方案，从开源系统到商业系统都去接触，经过不断碰撞，我将其总结为三个方向进行对比。
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，开放，链接，专业。
