Jenkins Pipeline阶段的最佳大小是多少

38次阅读
没有评论

问题描述

想知道在Jenkins Pipeline中,阶段的最佳大小是多少。他想知道是应该创建一个单独的checkout阶段,还是多个阶段,比如checkout scriptscheckout codecheckout something else。他还想知道如何决定将哪些逻辑放入单独的阶段中,或者阶段只是一个流水线可视化工具。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

在Jenkins Pipeline中,阶段的最佳大小是根据单一职责原则(SRP)来决定的。单一职责原则指的是一个类或模块应该只有一个原因需要被修改。如果一个模块有两个不同的原因需要修改,那么这两个方面应该被视为两个独立的职责,并应该分别放在不同的类或模块中。这样做的好处是使类更加健壮,如果报告编译过程发生变化,将更容易导致打印代码出错,因为它们不再耦合在同一个类中。
根据单一职责原则,我在创建Jenkins阶段时会考虑这一点。这意味着我会为checkout、build和publish等操作创建单独的阶段。如果一个阶段变得太大,即超过15行代码,我会创建一个脚本,并在该阶段中运行脚本。这样做的好处包括可读性、对脚本进行单元测试以及与CI无关,即可以迁移到其他CI工具。
以下是一个示例Jenkinsfile文件:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building..'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing..'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying....'
            }
        }
    }
}

在上面的示例中,我们定义了三个阶段:Build、Test和Deploy。每个阶段都有自己的步骤。你可以根据需要添加更多的阶段和步骤。

方案2

除了作为流水线可视化工具外,阶段还可以标识可以在彼此之间更或少独立执行的流水线部分,可能在不同的工作节点上执行。选择正确的流水线结构非常重要。
阶段可以在需要时重新执行,例如在环境问题导致的失败情况下,无需重新运行已经完成的上游阶段。
阶段提供了流水线分支的能力。例如,一个单独的构建阶段可以生成多个并行执行的下游测试阶段可以使用的构件,以缩短整个流水线的执行时间。
每个阶段操作可以由不同类型和大小的工作节点池支持。
阶段可以有条件地执行。例如,一个昂贵的集成测试阶段(耗时长且/或资源池比构建阶段小)可以只在一段时间内执行一次,而不是在每次提交时执行,或者只在发布分支上执行,而不在主要开发分支上执行。
由于通常意图是使流水线由每个提交触发,因此流水线的大小(即阶段的数量、持续时间和流水线图的结构)与以下因素可能存在复杂的关系:
– 触发流水线的提交的速率和配置文件
– 用于支持流水线阶段操作的资源池
– 分支的角色,强制执行的质量级别以及其在验证流水线结构方面的映射(即哪些阶段失败被视为阻塞,需要回退/回滚相应的更改,哪些阶段失败只需记录问题以在以后解决)
– 用于识别流水线执行中检测到的阻塞故障的罪魁祸首并修复它们所需的额外工作/资源量,以完成(持续)集成/交付/部署过程
在较小规模的项目中,通常情况下事情通常很简单,但在较大规模的项目中,这些方面需要认真思考,因为它们可能对整个开发过程产生巨大影响。
我将以你的第一个问题为例:
– 如果你有十几个仓库,组合起来需要不到一分钟的时间来checkout/pull,那么将它们全部放在一个阶段中可能是可以接受的。
– 如果你有几千个仓库,可能需要1小时以上来checkout/pull,那么你应该在每个阶段中只checkout/pull你需要的内容。或者,可以在第一个阶段中checkout/pull所有内容,然后缓存它们,并在后续阶段中重复使用该缓存,以避免重复冗长的checkout/pull操作。
根据你的项目上下文选择合适的方案。

正文完