用 Zadig 实现万次构建部署,聪明运维,释放开发生产力

利用 Zadig 的环境管理和 Serverless 构建,降低运维成本,面向开发团队提供价值,运维可以有更多的时间做更有益的事

易快报是一家从事费控报销 toB 的 SaaS 企业,致力于企业财务数字化领域云产品及服务的创新,运用前沿的数字技术和先进的创想理念,构建财务数智化中台赋能未来财务人成长。通过敏捷连接的模式创新和自主研发的“无需报销”解决方案为企业提供聚合消费、报销费控、企业支付、发票及电子档案管理等一站式服务,为企业业财融合提供数据决策分析与支持,助力企业实现降本增效与合规经营,易快报从早期版本就开始关注 Zadig。

# 背景

随着研发团队不断扩张,产研团队已达到 200 多人,GitLab CI/CD 已经无法满足研发们日益增加的需求, 环境管理,权限划分,构建优化等大大的增加了运维的成本,因此我们急需要新的方案来改善我们的现状,Zadig 成了我们的 首选方案

# 选型

构建部署流程图

痛点

  • 多组协作共同维护一套代码,交付镜像难以把控
  • 每个组需要一套全量环境以供研发测试,缺乏统一管理平台
  • 编译时拉取全量代码,打包构建极其耗时

期望

  • 研发需要时快速拉起一套环境
  • 资源紧张时可以释放环境
  • 降低打包时长,提高代码交付效率
  • 权限控制,项目独立

类比

  • Choerodon
  • Argo/Tekton
  • Zadig

在调研选型对比的过程中,我们发现 Zadig 最符合我们当前现状的,也是现阶段我们最合适的选择。使用 Zadig 的 Helm 部署模式可以 有效的解决多个服务之间共用一个镜像的部署问题。在环境管理方面, 研发可以自己去维护环境,修改配置,大大降低了运维的维护成本,让 运维有更多的时间做更有益的事

更多选择 Zadig 的理由:

  • 支持 Serverless 资源:将构建过程放在 Serverless 上,极大提高了构建效率,同时节约了不少成本
  • 支持数据概览、效能洞察: 聪明的团队会观测,该部分是运维团队构建可观测性的重要一环
  • 交付中心:个人理解为服务快照,可以帮助研发团队 快速切换版本,确实好用

# 落地

在测试 Zadig 的过程中,不断地尝试使用 Zadig 的功能各个功能,并希望可以将其使用到极致。在Zadig 初期的版本并非完全适用易快报当前的使用场景,也存在一些无法逾越的障碍。然而 Zadig 拥有一个包容的团队,在不断地沟通的过程中,我们也了解了某些功能的设计理念,同时也不断提出自己的痛点和诉求。在 Zadig 团队的协助下,我们的困扰在后面的几个迭代中得到了解决,这极大地鼓励我们落地 Zadig 的信心,最终在 Q1 推广至产研团队,并得到一致好评。

目前我们有两种主要使用场景,简举一种:

部署流程图

构建流程图

短短几个月,易快报产研团队已经使用 Zadig 完成近万次构建部署。

# 目标

目前我们对 Zadig 的使用还在早期阶段,还需要设定更高的目标。比如测试人员的介入,如何对接Sonar 扫描,如何制定个性化的工作流,协作模式的使用等,相信这些不止是我们一个团队所面临的问题,未来我们期望可以将 Zadig 和现有的各个系统打通,使其作为 DevOps 的重要一环,为团队提供充足的保障。

同时再为 Zadig 献上一些槽点:

  • 接入过程中发现 Zadig 工作流能力还是比较弱的,构建的镜像版本没有办法个性化
  • Helm 中把多个服务做成一个 Helm 包,如果存在多个服务公用一个镜像的时候,无法独立更新单个服务版本。
  • 构建的日志不支持搜索功能等一些优化的小问题
  • 版本升级麻烦,我们集群较多,每次部署的时候 Agent 都要挨个去升级,不够方便

# 结语

正如 Zadig 所愿, "工程师 + Zadig = 商业上的成功",作为 Zadig 的使用者,从初识到落地,有 Zadig 的付出也有自己的心血。可以看到 Zadig 在不断地走向成熟,我也在不断的进步。后续易快报会不断的尝试 Zadig,并给出一些落地的意见和理解,后续也会考虑为开源社区贡献代码。最后祝我们和 Zadig 都有一个美好的未来 ~

Background Image

作为一名软件工程师,我们一直给各行各业写软件提升效率,但是软件工程本身却是非常低效,为什么市面上没有一个工具可以让研发团队不这么累,还能更好、更快地满足大客户的交付需求?我们是否能够打造一个面向开发者的交付平台呢?我们开源打造 Zadig 正是去满足这个愿望。

—— Zadig 创始人 Landy