Question

现在Multibranch Pipeline作业类型已经成熟，是否有理由再使用简单的Pipeline作业类型？即使您今天只有一个分支，将来可能会考虑多个分支的可能性，那么使用Jenkins管道的管道作业类型与使用Multibranch的动机是什么动机呢？管道作业类型，假设您将Jenkins文件存储在SCM中？现在两种工作类型之间是否存在功能奇偶校验？

Answer 1

根据我对multibranch管道的经验，唯一的缺点是你无法在Jenkins主页上看到最后的成功/失败/持续时间列。他们只是在Jenkins首页上显示“NA”，因为它在技术上是子作业的“文件夹”。

除此之外，我无法想到使用multibranch的任何其他“缺点”。

我不同意另一个答案......那个案例是multibranch为“any”分支发送更改。这不一定是真的。如果Jenkins文件存在于随机要素分支上，但该分支未在管道中定义，那么您可以使用典型的if / else条件对其执行任何操作。

例如：

node {
  checkout scm
  def workspace = pwd()

  if (env.BRANCH_NAME == 'master') {
    stage ('Some Stage 1 for master') {
      sh 'do something'
    }
    stage ('Another Stage for Master') {
      sh 'do something else here'
    }
  }

  else if (env.BRANCH_NAME == 'stage') {
    stage ('Some stage branch step') {
      sh 'do something'
    }
    stage ('Deploy to stage target') {
      sh 'do something else'
    }
  }

  else {
    sh 'echo "Branch not applicable to Jenkins... do nothing"'
  }
}

Answer 2

在CI / CD情况下，可能不希望将每个分支发送到目标环境。使用管道并指定单个分支将允许您过滤，并仅将/ master发送到Staging或Production环境。 Multibranch可用于将任何分支上的任何更改专门发送到测试环境。

另一方面，如果QA / AutomatedTesting过程足够彻底，那么将任何分支机构发送到Production的风险都是可以接受的。

Answer 3

如果您的Jenkins作业处理单个git存储库，则Multibranch Pipeline运行良好。另一方面，当使用单个Jenkins作业处理多个git存储库时，管道作业可以是存储库中立的和分支中立的，并且非常灵活。

例如，假设你有来自repo-1的artifact-1，来自repo-2的artifact-2，以及来自repo-3的集成测试。而artifact-2依赖于artifact-1。 Jenkins的工作必须构建工件-1，然后构建工件-2，最后从repo-3运行集成测试。并假设您的代码更改转到repo-1的feature-1分支和repo-3中的新测试的feature-1分支。在这种情况下，Jenkins作业为artifact-1构建feature-1，然后使用＆＃39; dev＆＃39;从repo-2默认分支（如果在repo-2中未检测到feature-1），则运行＆＃39; feature-1＆＃39;来自repo-3进行新的集成测试。正如您所看到的，这项工作适用于三个git存储库。在这种情况下，repo-neutral / branch-neutral管道工作是理想的选择。

Answer 4

如果您仍在开发流程，那么简单的管道还具有支持参数化项目的优势。此功能对于在jenkins gui中开发声明性管道非常有用，它可以使用参数来控制要定位的分支/存储库。

Multibranch Pipeline vs Pipeline作业

4 个答案: