Мое дело в том, что слишком сложная логика конфигурации проекта внутри определения рабочих мест Jenkins и со временем это становится сложнее и труднее иметь дело. Это также мешает вам легко выполнять задания сборки в других инструментах построения/CI.Как свести к минимуму конфигурацию конкретного проекта сервера?
Если бы эти проекты были основаны на Java, кто-то, вероятно, сказал бы мне использовать maven, поскольку я мог бы поместить большую часть вещей в файлы pom.xml и иметь их с проектом. Тем не менее, в моем случае речь идет о C/C++ или даже .NET-проектах, для которых все скрипты сборки обычно находятся в bash (cygwin является зависимостью от Windows).
Я знаю, что теоретически я мог бы закодировать части, которые теперь находятся в конфигурации работы jenkins в этих файлах bash, но это явно потребует значительных усилий, и было бы очень сложно настроить их, чтобы разрешить и отключить различные шаги на основе внешние условия.
Итак, я стараюсь достичь высокого уровня независимости в отношении системы сборки, поэтому, если захочу, я могу переключить ее в будущем.
Что вы посоветуете как решение для этого? Очевидно, мне нужно что-то, что можно использовать мультиплатформенность и не подтягиваться к конкретной системе сборки.
Имеет ли смысл использовать maven для этого, даже если эти проекты не являются Java? Лично я не большой поклонник файлов конфигурации XML, YAML, JSON и INI считаются более дружественными.
Какая дополнительная логика, существующая в конфигурации Дженкинса, мы говорим? Можно было бы развертывать, поскольку я хочу иметь возможность развертывать Nexus или подобные репозитории, выполнять тесты, охват кода и, возможно, публиковать результаты где-то.
Как сидение, глядя на конфигурационные файлы Трэвиса, заставляет меня задаться вопросом, почему Дженкинс не пошел на такой подход.
Выберите любой инструмент для сборки. Не только maven - это инструмент Java. Попробуйте gradle, rake, make и т. Д. :) –
Спасибо @DracoAter - мы уже используем 'make' в некоторых проектах, но, очевидно, нет таких вещей, как плагины развертывания для make. У меня был некоторый ограниченный (хороший) опыт работы с rake, но Ruby не так сильно любил здесь, что решение «Python», несомненно, было бы легче охватить, поскольку оно очень популярно внутри компании и уже упоминалось как зависимость (в отличие от Рубин) – sorin