Сценарий таков: для ежедневных сборок моего мультиплатформенного приложения на основе Jenkins я получил довольно сложную настройку сборки; «корневое» задание Jenkins запускается таймером, оно выбирает соответствующую / самую последнюю версию git из соответствующей ветви git (на основе предоставленного параметра GIT_BRANCH) и запускает нижестоящие задания Jenkins на различных подчиненных машинах для сборки Mac, Исполняемые файлы приложения для Windows и Linux из этой git-ревизии. После успешного завершения всех этих сборок запускаются дополнительные задания сборки для обработки подписи, упаковки и загрузки артефактов сборки в соответствующие местоположения.
Все это прекрасно работает, и я очень доволен - однако, потому что это работает так хорошо, несколько команд в моей компании все хотят иметь свой отдельный / частный экземпляр этого. Например, основная команда разработчиков использует свой экземпляр для ежедневной сборки на основе git «master» ветки, чтобы помочь им в разработке версии нашего приложения следующего поколения, в то время как разработчики обслуживания используют их экземпляр для ежедневного получения сборка для тестирования их небольших исправлений, которые они сделали в боковой ветке, и, наконец, команда SQA также имеет свой отдельный экземпляр, который снабжает их последним кандидатом на выпуск (из другой боковой ветки) для оценки для публичное издание в ближайшее время.
Чтобы быть ясным: ни одна из этих групп не хочет "делиться" одним и тем же набором сборочных заданий Jenkins с какой-либо из других групп, поскольку совместное использование затруднит для них доверие, что "их" артефакты сборки все еще существуют строится из "своей" гит-ветки. (Загрузка, установка и запуск артефакта объемом 300 МБ только для того, чтобы узнать, что кто-то в SQA изменил настройку GIT_BRANCH, чтобы вчера указывать на свою ветку git, и поэтому вы потратили полчаса на установку неправильной версии приложения, просто без веселья)
Итак, как де-факто менеджер Jenkins, мое решение до сих пор заключалось в том, чтобы настроить один набор заданий сборки Jenkins (около дюжины заданий, все параметризованные, чтобы их можно было настроить для сборки из любой git-ветви) и затем, как только они будут работать так, как я хочу, я дублирую все задания сборки Jenkins в группе, так что теперь существует независимая копия всей группы, которая может содержать свои собственные настройки параметров по умолчанию, хранилище свои собственные отдельные каталоги-артефакты сборки и в целом живут независимо от исходного набора, в то же время выполняя практически тот же процесс сборки. Затем я делаю это снова для третьего экземпляра.
Это работает нормально, за исключением того, что необходимость поддерживать три набора идентичных заданий Jenkins действительно утомительна и подвержена ошибкам - первоначальное дублирование набора заданий занимает около часа каждый раз, а затем всякий раз, когда мне нужно внести изменения к потоку работ Дженкинса я должен применить каждое из изменений в трех разных местах.
Мой вопрос таков: есть ли в Jenkins какой-либо рекомендуемый способ «создать экземпляр» набора заданий Jenkins, чтобы одни и те же параметры задания можно было применить к нескольким заданиям Jenkins? Или есть какой-то другой подход к решению этой проблемы обслуживания / масштабируемости, который я должен рассмотреть вместо этого?