多分支管道与管道作业

Question

现在多分支管道作业类型已经成熟，还有什么理由再使用简单的管道作业类型吗？即使您现在只有一个分支，考虑到未来多个分支的可能性可能是明智的，那么假设您将Jenkins管道存储在SCM中，那么为您的Jenkins管道使用管道作业类型与始终使用多分支管道作业类型的动机是什么？现在这两种作业类型之间是否存在功能平价？

Answer 1

在CI/CD情况下，可能不希望将每个分支发送到目标环境。使用管道并指定单个分支将允许您进行筛选，并仅将/master发送到暂存或生产环境。多分支将有助于将任何分支上的任何更改专门发送到测试环境。

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

Answer 2

如果您的Jenkins作业处理单个git存储库，那么多分支管道工作得很好。另一方面，当使用单个Jenkins作业处理多个git存储库时，管道作业可以是存储库中立和分支中立的，并且非常灵活。

例如，假设您有来自repo-1的artiface-1、来自repo-2的artiface-2和来自repo-3的集成测试。artiface-2依赖于artiface-1。Jenkins作业必须构建artiface-1，然后构建artiface-2，最后从repo-3运行集成测试。并假设您的代码更改转到repo-1的特征1分支和repo-3中的新测试的特征1分支。在这种情况下，Jenkins作业为artiface-1构建特征1，然后使用“dev”分支作为repo-2的默认值（如果在repo-2中未检测到特征1），并从repo-3运行“特征1”以进行新的集成测试。如您所见，该作业适用于三个git存储库。回购中性/分支中性管道作业在此设置中是理想的。

Answer 3

根据我使用多分支管道的经验，唯一的缺点是在Jenkins主页上看不到最后的成功/失败/持续时间列。他们只是在詹金斯的头版上显示“NA”，因为从技术上讲，它是一个包含子作业的“文件夹”。

除此之外，我想不出使用multibranch还有什么其他的“缺点”。

我不同意另一个答案......这种情况是多分支发送“任何”分支的更改。这不一定是真的。如果Jenkinsfile存在于随机特征分支上，但该分支未在管道中定义，那么您不能使用典型的if/否则条件对其执行任何操作。

例如：

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"'
  }
}