Jenkins 任务如何迁移到 Zadig 工作流

详解迁移至 Zadig 的操作步骤,轻松解决 Jenkins 的维护难题

我们在「不想放弃 Jenkins?这么做也能云原生 (opens new window)」一文中详细描述了如何在保留 Jenkins 的前提下,通过 Zadig 快速提升效率和工程师幸福度。然而,尽管这样做可以取得一些显著的成果,却未能实质解决运维人员对系统维护的繁重负担。实际情况中,Jenkins 的管理和维护存在诸如插件兼容性、内存泄漏、用户权限管理、脚本维护等多方面的问题,导致运维人员仍需花费大量时间进行系统维护。因此,是否可以完全弃用 Jenkins,并将现有任务全部迁移到 Zadig 上执行呢?答案是肯定的。Zadig 不仅具备 Jenkins 的全部功能,而且能够实现软件开发过程中复杂流程的自动化。

# Zadig 工作流到底有何独特之处?

Zadig 工作流引擎起初基于 Kubernetes 原生能力搭建,借助 Kubernertes 的资源动态分配能力,实现多任务的并发执行,相比 Jenkins 至少可以节省 50% 的资源,并可以提高至少 40% 的任务执行效率。

Zadig 工作流的设计更贴合实际业务场景,支持编排产品交付过程中涉及到的任何系统和工具,如:项目管理系统、代码托管平台、测试平台、部署工具、配置管理工具、数据管理工具、审批系统、企业自建系统等等。Zadig 工作流除了具备 CI 工作流的基本能力(比如克隆代码、执行 shell 脚本、触发器、通知、缓存等等)外,支持以下更多能力:

  • 支持多服务共享构建、构建模板、利用 Serverless 资源构建
  • 支持多服务的并发构建、并发部署、并发测试
  • 支持项目管理中的任务状态变更、配置变更、数据变更
  • 支持蓝绿发布、金丝雀发布、分批次灰度发布、MSE 全链路和 Istio 全链路发布
  • 支持发布过程审批
  • 在执行时支持根据实际的分支策略,自由选择 BranchPR/MRBranch+PR/MRTagCommit 方式进行构建
  • ……

# 工作流实现方式的细节差异

工作流关键环节 Jenkins Zadig
执行环境 手工制作环境 可扩展云原生环境及依赖包
代码信息 分散配置代码源 统一管理多种代码来源
执行脚本与变量 分散编写脚本 统一配置脚本规范
定时触发 定时触发 多种可定制触发策略
代码变更触发 插件代码触发 海量多种触发策略
工作流间的串接 根据工作流状态触发 服务化灵活编排调度
多任务并发执行 编写脚本控制并发 云原生任务 GUI 配置并发
任务并发数量控制 资源节点控制并发 统一管理并发调度策略

# 如何将 Jenkins 上的配置迁移到 Zadig 上

下面详细介绍如何将已经在 Jenkins 上的相应配置迁移到 Zadig 上,按照不同的阶段拆解迁移的过程。

# 比较一:执行环境

对于工作流任务依赖的环境,在 Jenkins 上需在对应节点上手工制作,而在 Zadig 上支持管理任务运行时基础环境和依赖的软件包,方便平台运维统一管控业务构建、测试等过程使用的基础资源,保障资源的安全及合规。

Jenkins 任务的执行环境通过在配置中选择运行节点来指定,任务执行过程中用到的软件包需要在对应节点上安装和管理。

Zadig 任务的执行环境通过在配置中选择操作系统和依赖软件包来指定。

# 比较二:代码信息

对企业内部使用的代码源,在Jenkins上将其分散在不同的任务中进行管理,而在 Zadig 上由管理员统一集成,以确保代码源的安全性。

下面以 GitLab 为例,比对 Jenkins 和 Zadig 上代码信息的配置。

Jenkins 通过配置「源码管理」来实现构建代码源的定义。

Zadig 支持 GitLab、GitHub、Gerrit、Gitee 、其他通用 Git 代码源等代码托管平台的集成,完成集成后可列出代码库中有权限的代码仓库信息,包括 Branch、PR/MR、Tag 等等,对于开发者更加直观、体验更友好。

  • 步骤 2:任务中配置代码信息。Zadig 构建、测试、代码扫描及通用任务均支持拉取代码信息。

# 比较三:执行脚本及变量

对于服务执行脚本和变量的定义,在 Jenkins 上分散在各个任务中进行管理,而在 Zadig 上可以通过构建模版来标准化服务的构建过程,降低运维管理的负担。

下面以一个多服务的代码仓库的构建并推送镜像为例,比较 Jenkins 脚本编写和 Zadig 脚本编写的差异。

Jenkins 执行脚本及变量如下图所示,脚本中主要进行服务构建、镜像构建以及镜像推送过程。其中 $SERVICE、$VERSION、$PWD 变量需要在配置中定义。

Zadig 执行脚本及变量如下图所示,Zadig 构建内置 $SERVICE、$IMAGE 变量,脚本更加简洁。

两者之间的差异:

  1. Zadig 任务执行过程中根据工作流配置的镜像仓库自动完成 docker login 操作,所以无需在脚本中声明。
  2. 在 Zadig 中镜像命名规则支持统一配置和管理,具体可参考策略配置 (opens new window),所以无需在脚本中定义 IMAGE 变量的生成规则。

# 比较四:定时触发

工作流任务的定时执行场景比较常见,Jenkins 针对工作流任务的默认参数可以配置定时触发,而 Zadig 上除了可以指定触发时间周期外,还支持配置任务的执行变量,更加灵活。

Jenkins 触发器支持配置 Cron 表达式来定时触发任务。

Zadig 定时器支持多种触发方式,包括定时循环、间隔循环和 Cron 表达式,以满足各种定时触发的需求。此外,相较于 Jenkins 使用默认参数执行,Zadig 定时器允许配置不同的工作流执行变量,提供更灵活的定制选项。

# 比较五:代码变更触发

开发者提交代码自动触发工作流执行是持续集成和持续部署(CI/CD)中常见的实践。在 Jenkins 中,为实现这一需求,需要依赖插件。相比之下,Zadig 则内建 Git 触发器功能,无需额外插件,通过灵活的配置满足各种触发场景,从而提升整体效率。

Jenkins 可以通过安装插件实现代码变更触发任务的执行。

Zadig Git 触发器支持代码变更触发,通过定义代码信息、触发事件、代码文件目录以及工作流执行变量,来配置触发规则。这使得在代码库发生变更时,可以灵活而精准地触发相应的工作流,以满足各种复杂的自动化流程的执行。

除了上述两种触发器,Zadig 还支持多种其他触发器,包括「JIRA 触发器」、「飞书项目触发器」和「通用触发器」等,使用详情参考工作流的触发 (opens new window)

# 比较六:工作流之间的串接编排

企业内部对于一些服务化的任务,例如安全扫描服务,需要进行统一管理并在多个工作流中使用。通常,这些任务由安全部门或平台团队进行统一管理,然后在各个业务工作流中进行调用。为了降低实施和后续维护的负担,一般选择采用多工作流串接的方式,以实现更高效的任务调度和管理。

Jenkins 通过配置「构建其他工程」来触发其他任务。

Zadig 的工作流本身采用了服务化的设计,使得测试、代码扫描等配置可以实现集中化的管理,然后轻松挂接到各个工作流中使用。这种设计使得配置和管理变得更加高效,同时在不同的工作流中灵活地应用这些服务,提高了整体工作流的可维护性和可扩展性。

# 比较七:多任务并发执行

多任务并发执行在复杂的软件开发流程、持续集成和部署中尤为关键。这能够显著减少工程师的等待时间,提高整体研发效率,从而加速项目进程,更灵活地应对不断变化的需求。

Jenkins 流水线支持不同的 "stage" 并发执行,详细配置请参考以下结构。

pipeline {
    agent any
    stages {
        stage('Build and Deploy Services') {
            parallel {
                stage('Service 1') {
                    steps {
                        echo "构建和部署 Service 1 过程"
                    }
                }
                stage('Service 2') {
                    steps {
                        echo "构建和部署 Service 2 过程"
                    }
                }
                stage('Service 3') {
                    steps {
                        echo "构建和部署 Service 3 过程"
                    }
                }
            }
        }
    }
}

Zadig 工作流仅需在「阶段」上打开「并发执行」的开关,即可实现阶段内多个任务的并发执行。

# 比较八:任务并发数量控制

Jenkins 和 Zadig 均支持同一工作流的多个任务并发执行。Jenkins 通过资源节点来控制并发数量,而 Zadig 则统一管理并发调度策略,具有灵活控制任务优先级能力。

Jenkins 通过在节点上配置「任务执行数量」来控制多个任务的并发,单个 Jenkins 任务的并发可以在任务配置中指定。

Zadig 通过在任务配置中修改「任务并发数量设置」实现并发数控制,其中「工作流执行并发数量」控制同时执行的工作流数,「单任务服务并发数」控制同一个工作流任务内同一阶段下的任务并发数量。除此之外,面对低优先级任务占用全局并发数量的场景,可以通过配置工作流的「执行并发数」来解决。Zadig 具有更自由的任务并发数控制,能够灵活应对企业内部复杂的任务并发场景。

除以上能力外,Jenkins 通过插件来扩展更多的能力,而 Zadig 可以通过开发「自定义任务 (opens new window)」,和企业自建系统打通,来满足企业复杂流程。

Background Image

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

—— Zadig 创始人 Landy