Работа с несколькими ветвями в непрерывной интеграции
Я занимался проблемой масштабирования CI в своей компании и в то же время пытался выяснить, какой подход использовать, когда речь идет о CI и нескольких филиалах. Есть аналогичный вопрос в stackoverflow, Многофункциональные ветки и непрерывная интеграция . Я начал новый, потому что хотел бы получить больше обсуждения и провести некоторый анализ вопроса.
На данный момент я обнаружил, что есть 2 основных подхода, которые я могу использовать (или, может быть, некоторые другие? ??).
- Написание инструментов для управления дополнительными заданиями
- Массовое создание / изменение / удаление заданий
- Пользовательские настройки для каждого задания для каждой ветки (URL-адрес SCM, дублирование репозиториев управления)
- Некоторые примеры людей, решающих эту проблему с помощью инструментов оболочки, сценариев ant и Jenkins CLI. Видеть:
- http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
- http://jenkins.361315.n4.nabble.com/Is-it-possible -to-handle-multiple-branch-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729.html
- http://jenkins.361315.n4.nabble.com/Parallel -development-with-branch-td1013013.html
- Автоматическая настройка или создание задания Hudson
- Увеличивает нагрузку на ваш кластер CI
- Цикл обратной связи для разработчиков замедляется (если инфраструктура не может справиться с новой нагрузкой)
- Управляйте двумя наборами вручную (если вы измените конфигурацию задания, обязательно измените в другой ветви)
- PITA, но, по крайней мере, так мало для управления
- Другие дополнительные ветки не получат полный набор тестов, пока их не отправят разработчикам
- Недовольные разработчики. Почему разработчику должны волновать проблемы масштабирования CI. У него есть простая просьба: когда я перейду, я хочу протестировать свой код. Просто.
Кажется, что если я хочу предоставить разработчикам CI для их собственных веток, мне нужны специальные инструменты для Jenkins (API, сценарии оболочки или что-то еще?) И управление масштабированием. Или я могу посоветовать им чаще сливаться с DEV и жить без CI в пользовательских ветках. Какой из них вы бы выбрали, или есть другие варианты?