管理构建任务的5个必选插件

965 阅读5分钟

最近发现很多小伙伴在使用 Jenkins 过程中管理任务有点小散乱,其实 Jenkins 的插件库里面也有很多任务管理插件来解决这类问题。

下面分享5个我最常用的任务管理插件和相关应对场景

Folders

1. 插件介绍

Folder 这个插件允许用户创建一个目录组织 jobs。可以按照自己的需求场景定义分类方法(比如:通过产品,组织架构等),Folders 能递归创建并且可以在内部创建视图(View)。

2. 应对场景

通常大家创建任务是放在路径,比如下图,大量的任务堆积在一个目录下,通过视图(Views)分类展示

这种方式有一些缺点:

  1. 任务多了后不方便管理,页面加载会很慢
  2. 通过视图方式隔离展示任务没法进行权限控制
  3. 任务操作不聚焦,容易误操作。

Folder 可以很好的解决这些问题,下面是使用方法

1. 安装插件

在下图中的可选插件中输入Folders Plugin勾选并安装

2. 创建目录

创建目录和创建 job 流程一样,操作如下图:

目录创建名称可以设置几种规则,比如安装产品和系统目录创建,下图中创建了 bakSystemdebug 登录目录分别存放不同类型的 job,比如:

  1. System 目录用于存放备份,构建记录清理任务等
  2. bak 目录类似回收站,将需要清理的任务移动到这里,
  3. debug 目录是调试功能使用。

categorized-view

1. 插件介绍

categorized-view 一个将任务进行分组折叠的方式展示任务的视图插件,通过强大的正则表达式可以实现很多种分组策略。

2. 应对场景

当一个应用的构建发布流程有很多 job 的时候需要通过一种应用视图的方式展示任务。

1.安装插件

在下图中的可选插件中输入categorized-view勾选并安装

2.配置应用视图

这个目录下面有很多 job 以这种方式看会很不友好,

点击 All 视图旁边的 + 号,输入视图名称,并选择视图类型为 Categorized Jobs View

进入配置页面,通过下图中的3步配置后点击保存

查看配置结果并调试

Dashboard View

1. 插件介绍

Dashboard View 一种铺砖的视图展示任务信息和 Jenkins 状态,效果如下图:

2. 应对场景

当我是一个 Jenkins 管理维护人员,需要了解当前正在运行的任务,最新失败的任务,当前有多少任务和多少次构建等信息,可以通过这个视图快速拿到,这样定位问题和处理问题效率会很高。

Build Monitor View

1. 插件介绍

Build Monitor View 构建监视器插件提供了一个高度可见的视图所选Jenkins作业的状态。。

2. 应对场景

这个插件的出现是基于一个information radiators(信息发射源) 的概念产生的,这个概念通常被用在敏捷的圈子里。

据敏捷专家Alistair Cockburn所说:

一个信息发射源是一个贴在一个地方的显示器,当人们工作或路过时能够看到它。它给读者展示他们关系的信息而不用问别人一个问题。这意味着更多的交流和更少的打断。

这种特定的信息发射源通常被称为构建发射源(build radiator)。

之前将这种插件运用在测试团队的自动化用例开发过程中,当时帮测试团队配置好各种测试用例构建任务后,找了一台老旧的显示器放在团队成员都能看到的地方,展示此插件视图,当任务出现失败,能及时发现并分析处理,通过在上面展示用例数量可以激发团队成员努力开发用例填补缺失场景用例。

类似效果图

Job DSL

1. 插件介绍

Job DSL 一个很好的利用 DSL 设置和运行 Job 的插件。除了可以自动配置 Job 外还可以配置 View 。

2. 应对场景

2.1. 场景一

一个产品大约40个代码库,分为前端、后端、中间件等服务需要根据环境创建不同的 job,每个项目估计要 3~5 个 job,每种job有各自的配置方式,这个时候就需要通过代码化的方式创建。下面是简单的一个样例代码,后面出文章详细讲解代码开发和任务配置

第一步:抽象每个应用的 job 开发出创建应用的函数

def genBuildJob(String folder, String appName, String envId, String gitlabRepo, String configDir, String filter="xxx.*") {
    String branchType = "PT_BRANCH"
    String jobPrefix = "test-build"
    String branchMatch = "develop"

    String jobName = "${folder}/${jobPrefix}${appName}"
    String gitParamDef = "gitlabBranch"
    String jenkinsfilePath = "${folder}/${configDir}/Jenkinsfile"

    pipelineDefinitionScmBuilder(
            pipelineBuilder(jobName)
                    .withParameters(listGitBranchesParameter(gitParamDef, '', '',
                            gitlabRepo, Constants.GIT_CRED_ID).withType(branchType).withTagFilter(filter))
                    .withTriggers(gitlabTrigger().withSecretToken("xxxx")
                            .withBrancRegexBasedFilter(branchMatch, ""))
    ).withGitScm(DockerConstants.PIPELINE_SCRIPT_GIT_REPO, Constants.GIT_CRED_ID, "*/master",
            "${jenkinsfilePath}", true)

}

static def genDeployJob(String folder, String appName, String tmplName=null) {

    def DEPLOY_JOB_SCRIPT = """\
        #!groovy

        xxxDeploy {
            appGroup = "${folder}"
            appName = "${appName}"
        }

        """.stripIndent()

    pipelineDefinitionScriptBuilder(pipelineBuilder("${folder}/deploy-${appName}"))
            .withScript(DEPLOY_JOB_SCRIPT)
}

def genAppBuilds(String folder, String appName, String gitRepo, configDir) {
    genBuildJob(folder, appName, "test", gitRepo, configDir, "xxx.*").build(this as DslFactory)
    genBuildJob(folder, appName, "prod", gitRepo, configDir, "xxx.*").build(this as DslFactory)
    genDeployJob(folder, appName, "xxx").build(this as DslFactory)
}

第二步:整理好应用列表,通过一个循环搞定


[
        "apollo-configservice",
        "apollo-adminservice",
        "apollo-portal"
].each {
    genAppBuilds(JOB_DIR, it, "git@git.url:xxx/apollo.git", "apollo")
}

这种方法还要配合 Jenkinsfile 一起实现,这种方法的好处就是可以在很短时间重建产品的构建系统。

2.2. 场景二

在自动化测试过程中,比如现在测试团队有1000+个测试用例,分10个模块,每个模块需要单独执行构建,并设置每日构建时间。处理方式和场景一类似。

最后

视图插件的配置方式都很类似,这里就没有细讲,大家可以实际配置体验一下。


如果你觉得今天这餐不错,欢迎点赞分享加关注。