Работа по проекту Multibranch Pipeline vs Pipeline

Теперь, когда тип задания Multibranch Pipeline созрел, есть ли причина использовать простой тип задания Pipeline? Даже если у вас есть только один филиал сегодня, вероятно, разумно учитывать возможность использования нескольких веток в будущем, и поэтому было бы целесообразным использовать тип задания Pipeline для вашего Jenkins Pipeline и всегда использовать тип задания Multibranch Pipeline, если вы храните свой файл Jenkins в SCM? Существует ли соотношение четности между двумя типами заданий?

ОТВЕТЫ

Ответ 1

В моем опыте работы с многоканальными конвейерами, единственный недостаток заключается в том, что вы не можете видеть последние столбцы успеха/отказа/продолжительности на главной странице Jenkins. Они просто показывают "NA" на первой странице Jenkins, так как это технически "папка" подзаголовков.

Кроме этого, я не могу думать о каких-либо других "минусах" использования мультибренда.

Я не согласен с другим ответом.... Дело в том, что multibranch отправляет изменения для "любой" ветки. Это не обязательно так. Если файл 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"'
  }
}

Ответ 2

В ситуации CI/CD может быть нежелательно отправлять каждую ветвь в целевую среду. Использование конвейера и указание одной ветки позволит вам фильтровать и отправлять только /master в среду постановки или производства. Multibranch был бы полезен для отправки любых изменений в любом филиале специально в тестовую среду.

С другой стороны, если процесс QA/AutomatedTesting достаточно тщателен, риск отправки любой ветки в Production может быть приемлемым.

Ответ 3

Многопоточный конвейер работает хорошо, если ваша работа с Jenkins работает с одним репозиторием git. С другой стороны, конвейерное задание может быть нейтральным по отношению к хранилищу, нейтральным по отношению к ветвям и очень гибким при работе с несколькими репозиториями git с одним заданием Jenkins.

Например, предположим, что у вас есть артефакт-1 из репо-1, артефакт-2 из репо-2 и интеграционные тесты из репо-3. А артефакт-2 зависит от артефакта-1. Задание Дженкинса должно собрать артефакт-1, затем создать артефакт-2 и, наконец, запустить интеграционные тесты из repo-3. И предположим, что ваше изменение кода идет в ветку feature-1 repo-1 и feature-1 для новых тестов в repo-3. В этом случае задание Jenkins создает компонент-1 для артефакта-1, затем использует ветку 'dev' по умолчанию из repo-2 (если функция-1 не обнаружена в repo-2) и запускает 'feature-1' из РЕПО-3 для новых интеграционных тестов. Как видите, работа хорошо работает с тремя репозиториями git. В этом случае идеально подходит работа с нейтральным или неприкосновенным участком трубопровода.