Задний план:
Я разработчик программного обеспечения, у которого есть некоторый опыт настройки решений непрерывной интеграции, но я не очень хорошо знаком с плюсами и минусами определенных стратегий непрерывной интеграции, и хотел бы получить совет относительно преимуществ и проблем двух стратегий управления сервером.
Вопрос:
У нас есть 3 отдельных сложных приложения для Android, для которых я создаю серверы непрерывной интеграции. Я успешно создал прототип виртуальной машины под управлением Windows Server 2008, которая успешно компилирует код, запускает эмулятор и выполняет модульные тесты Android. Отдельно я также смог запустить статический анализ, который мы хотим запустить в этом коде, чтобы предоставить разработчикам обратную связь.
В предыдущих конфигурациях с использованием CruiseControl.NET вместо jenkins мы успешно поддерживали 3 отдельные виртуальные машины, все с независимым виртуализированным оборудованием. В преимущества Эта настройка является разделением - один проект может изменить свой сервер сборки, не затрагивая другой проект.
Однако, переходя к Дженкинсу, отмечу, что он поддерживает ведущие / ведомые узлы, который мог бы позволить мне настроить один главный экземпляр Jenkins с несколькими проектами, а затем настроить несколько подчиненных узлов, которые, насколько я понимаю, будут выполнять любые задачи Jenkins - компиляцию, модульное тестирование, статический анализ и передавать эту информацию обратно в мастер-сервер. В преимущества этой установки кажутся:
Вызовы в этой ситуации выглядят:
Есть ли какие-то другие непосредственные преимущества или проблемы, которые я забыл, или кто-то, у кого есть опыт настройки jenkins, имеет мнение о том, какой подход будет более подходящим?
Ваше понимание вполне полное. Единственное, что я могу добавить, это то, что использование терминологии «главный / подчиненный» в jenkins / hudson, на мой взгляд, немного искажено. Ведь «рабы» больше похожи на исполнителей в распределенной схеме запуска заданий / сборок / проектов. Я не думаю, что иметь 3 отдельных мастеров Дженкинса разумно в вашей ситуации.
1) - Мне нужно научиться создавать рабов - На самом деле это не проблема, это всего лишь один jar-файл для ведомого устройства. Легко устанавливается на разные ОС (Linux, Windows, Unix), может запускаться как сервис / демон. Тогда вам просто нужно будет прикрепить этого ведомого к мастеру.
2) Мне нужно будет справиться с коммуникацией между клиентами и рабами - Это тоже довольно тривиально, так как все, что вам нужно, это управлять ключами ssh и учетной записью пользователя для ведомых устройств для подключения к клиентам.
3) У меня могут возникнуть проблемы с запуском модульных тестов, требующих взаимодействия с пользовательским интерфейсом - Это снова не должно быть проблемой. К настоящему времени должно быть множество решений.
Опять же, я действительно рекомендую вам использовать jennkins в вашем рабочем процессе разработки для CI и CD, на самом деле нет вещей, которые jenkins не могли бы сделать, что доходит до этого. Начал пользоваться 3 года назад и никогда не оглядывался назад.
Единственный краеугольный камень, который я вижу в вашей конкретной ситуации, - это то, что это новый инструмент, и, возможно, потребуется небольшая кривая обучения и некоторые корректировки, которые нужно внести при переходе со старого рабочего процесса, но, скорее всего, это принесет большую пользу вам и вашей команде в долгий пробег.
Надеюсь это поможет.