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