您的位置:  首页 > 技术杂谈 > 正文

时谛放弃 Jenkins 全面拥抱 Zadig

2022-11-23 16:00 https://my.oschina.net/koderover/blog/5596941 Zadig云原生交付 次阅读 条评论

作者:Rio

DevOps 开发工程师

时谛智能是一家致力于透过科技赋能时尚产业创意开发,从虚拟打样、在线设计、仿真渲染、在线协作到打通生产的一站式数字化平台服务公司,产品包括 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 修修补补,使得运维为满足日新月异的需求而疲于奔命,工作业绩也很难体现。因此,我们意识到需要做出转变了,于是便通过面对面沟通的形式,征集不同岗位同事对于系统的期望,在收集完开发、测试、运维、项目经理的声音后,我将期望总结为以下几点:

  1. 支持 Go、Java、Yarn 的构建和部署。

  2. 能有效的管理工作流、人员的权限,实现项目间的权限隔离和共享。

  3. 支持 K8s-Yaml 模板、构建模板、镜像模板等。

  4. 能有效的管理多个版本,支持一键发布、一键回滚。

  5. 服务构建、服务部署、服务管理和运维要在同一个系统中,便于操作和数据统计。

  6. UI 界面尽可能简洁美观。

技术选型

基于以上痛点和期望,我们便开始调研解决方案,从开源系统到商业系统都去接触,经过不断碰撞,我将其总结为三个方向进行对比。

 

1在原有的 Jenkins 基础上开发迭代,以定制化开发为主,结合一些插件使用。 

优势:风险可控,并且属于增量迭代,不影响大家一直以来的使用习惯。

劣势:过多插件和定制化开发使维护越来越难,插件也经常提示存在安全漏洞需要更新。

 

2阿里云效、腾讯 Coding 等商业 DevOps 系统。

优势:经过前沿互联网公司的沉淀,基本能实现所有需求,同时其技术能力、服务水平也值得信赖。

劣势:使公司核心环节过于依赖外部因素,风险高;我司软件为 toB 的软件,后续将会为客户提供部署和运维,无法通过这种方式实现;另一核心问题在于其技术不开源,难以进行有效的定制化。

 

3开源 DevOps 系统。经过多方对比,Zadig 脱颖而出。

优势:Zadig 系统实现了开发部署各环节大部分需求,使用简单、高效,官方技术解答十分专业有耐心,良好的社区生态。

劣势:涉及到近百个服务和整个产研团队的使用,运维实施存在一定的工作量。同时所提供的开放 API 接口偏少,存在一定的定制化开发的难度(但新版的迭代方向不断在扩充 OpenAPI 和接口使用体验)。

 

具体实践

综合以上利弊分析,我发现整体看 Zadig 是非常不错的选择,于是决定在公司内进行推广。在引入一个新的系统时,我始终保持谨慎的原则,首先在公司的创新部进行试点运行,然后根据创新部同事反馈结果,决定下一步的方案。

 

内部试点

通过官方的一键部署脚本,可以很快的拉起 Zadig 系统,然后配置开发、测试、预发布环境,模拟正常开发迭代、部署上线的流程。在公司创新部进行试点 1 个月期间,我们发现了大大小小的 BUG,同时也收集了很多来自同事反馈的需求和建议,这些都反馈给了官方,官方收到我们的请求后也都认真的逐条回复,并对于其中重点问题进行了修改,而对于一些功能上的建议也在后续的版本进行了实现。在此期间,Zadig 社区工程师给我提供了非常重要的帮助,我不得不为他们专业的技术能力和对待问题的认真态度点赞👍👍。

 

试点总结

内部试点结束后,我收集了创新部同事对于 Zadig 的看法,结果收获了一致好评。大家谈论其优点大致为:

  1. 界面美观操作方便

  2. 将开发测试涉及的流程在一个平台上完成,不需要切来切去。

  3. 配置很简单,即使经验少的同事,通过文档也能快速上手。

  4. 项目管理版本管理人员权限管理设计的很巧妙,体现出设计者对痛点把握十分精准。

如此多的好评,再加上 Zadig 团队积极处理问题的态度和专业的技术能力,我们愉快的决定是时候放弃 Jenkins,开始拥抱 Zadig 了。

 

全面推动

第一步:环境配置

  1. 添加各个环境的 Kubernetes 集群到 Zadig 中,配置构建代码源,镜像仓库,构建镜像等。

  2. 创建项目和工作流,接入 AD 域,对每个人员精准授权。

  3. 通过模板创建服务,通过变量控制不同环境不同的设置。

  4. 通过构建模板,定义服务的构建方式,并可以设置不同环境不同的构建方式。

  5. 优化构建缓存、构建顺序提高构建效率。

  6. 将服务部署到环境中,通过工作流进行更新。

 

第二步:理念宣导

因为公司产品研发团队有百来号人,想要将一个大家使用了几年的工具完全替换是一件十分困难的事情,所以为了项目的顺利推进,我们先在公司内举行了一次 DevOps 理念的宣导,对云原生时代所使用的技术做了基本解释,并着重强调了 Zadig 对比于传统的工具其优势所在,以及在不同的解决方案里我们权衡利弊后的选择,会后员工们纷纷表示高度认可此项工作。

 

第三步:操作培训

通过理念宣导作为基础,后续便针对每个小团队进行专题培训,主要是解释 Zadig 的基本操作,注意事项,以及高阶操作等。然后每完成一个小团队的培训,就将其在 Jenkins 上的工作流都纷纷关闭,使其只能在 Zadig 上完成工作,此过程较为漫长,经过 2 个月的不懈努力,最终将原本在 Jenkins 上的工作流完全迁移至 Zadig。

 

总结与期望

目前版本 Zadig 已经能够很好的完成绝大多数需求了,同时配合我司项目管理工具的使用,使得版本迭代相关的工作,形成了一个良好的闭环。产品需要精益求精,当功能完善后更应该进行操作体验上的优化,一个微小的细节可能会成为决定成败的关键。

 

以下是我对 Zadig 的一些期待建议

  1. 允许更改工作流名称,构建名称。

  2.  工作流、环境等命名时支持中文命名。

  3. 支持类似于构建模板、构建等可以通过复制的方式创建。

  4. 查看日志时为黑底白字且字体小,看久了会很累,建议有多种配色方案且能调节字体大小。

 

Zadig,开放,链接,专业。

 

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接