マルチブランチパイプラインジョブタイプが成熟したので、シンプルパイプラインジョブタイプを使用する理由はありますか？今日はブランチが1つしかない場合でも、将来的には複数のブランチの可能性を考慮することをお勧めします。そのため、ジェンキンスパイプラインのパイプラインジョブタイプとマルチブランチパイプラインジョブタイプを常に使用する動機は、 JenkinsfileをSCMに格納していると仮定しますか？現在、2つのジョブタイプの間に機能パリティがありますか？マルチブランチパイプライン対パイプラインジョブ
CI/CDの状況では、すべてのブランチをターゲット環境に送信することは望ましくない場合があります。パイプラインを使用して単一のブランチを指定すると、フィルタリングし、/ masterのみをステージング環境または本番環境に送信できます。マルチブランチは、ブランチの変更をテスト環境に送信する場合に便利です。
一方、QA/AutomatedTestingプロセスが十分に徹底的であれば、ブランチをProductionに送信するリスクが許容される可能性があります。
マルチブランチパイプラインでの私の経験では、Jenkinsメインページの最後の成功/失敗/継続時間の列は表示されません。技術的にはサブジョブの「フォルダ」なので、Jenkinsのフロントページには「NA」と表示されます。
これ以外にも、マルチブランチを使用することについて他の「短所」を考えることはできません。
私は他の回答には同意していません....その場合、マルチブランチは「任意の」ブランチの変更を送信します。それは必ずしも真実ではありません。 Jenkinsfileがランダムな機能ブランチ上に存在し、そのブランチがパイプラインで定義されていない場合、典型的な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"'
}
}