#jenkins #continuous-integration #gitlab #legacy #infrastructure
#дженкинс #непрерывная интеграция #gitlab #наследие #инфраструктура
Вопрос:
В нашей организации мы работаем в автономном режиме (отключены от Интернета). Большинство используемых нами инструментов установлено на одном сервере, который должен обслуживать всех пользователей (около 500 одновременных пользователей).
мы используем все следующие операционные системы: Linux (все варианты), Windows (2000, XP, 7, 10), VxWorks, Solaris и некоторые системы, разработанные собственными силами. Мы используем почти следующие языки разработки: C, C , C #, Java, JavaScript, python, ruby, visual Basic и некоторые более старые языки (у нас много устаревшего кода).
учитывая тот факт, что мы должны поддерживать все эти платформы, вы бы порекомендовали использовать Jenkins или Gitlab CI в качестве основного инструмента CI?
что нам нужно, так это возможность интеграции большого количества программного обеспечения (старого программного обеспечения!), И поскольку в настоящее время мы переходим на Gitlab в качестве нашей системы управления версиями, мы все еще не решаемся менять инструмент CI. мы не хотим использовать оба инструмента, чтобы иметь возможность использовать сценарии / потоки из разных команд и проектов.
что должно быть основным соображением нашей компании в отношении этого вопроса — принимая во внимание, что это решение может быть инфраструктурой, которую мы будем использовать в течение следующих 5-10 лет?
Если потребуется дополнительная информация, я был бы рад предоставить ее!
Ответ №1:
Я не думаю, что есть окончательный ответ на этот вопрос, но то, что вы могли бы принять во внимание, — это скорость принятия Jenkins и поддержка сообщества, которая, вероятно, подойдет вам, поскольку у вас есть проекты на нескольких языках программирования. С другой стороны, GitLab CI он более прост в использовании и намного чище, поскольку вы пишете конвейеры в YAML формате. Мне, например, стало GitLab CI нравиться больше, чем Дженкинс, но это всего лишь предположение.
Комментарии:
1. Забудьте о «скорости принятия Дженкинса и поддержке сообщества»… Подумайте о степени принятия на вашем собственном рабочем месте. С такой разрозненной комбинацией SW, OS и т. Д. Централизованная система сборки, подобная Jeknins, может превратиться в кошмар для внедрения или принятия. Ваше рассмотрение CI не зависит от системы управления версиями, но иногда проще предоставить им возможность самостоятельно управлять готовым решением. Учитывайте первоначальные затраты — затраты на лицензию плюс HW по сравнению с использованием cloud .
Ответ №2:
Я использую Дженкинс с 2013 года. Это оказалось хорошим надежным инструментом, который требует МНОГО обслуживания.
Последняя реализация, которую я создал, — это master, работающий в контейнерах и обрабатывающий конвейеры и задания пользовательского интерфейса на нескольких агентах: контейнеры для сборок Linux и обычные виртуальные машины для Windows и другие.
Каждая команда владеет подчиненным устройством и получает собственное пространство в Jenkins, не вмешиваясь в работу других и не являясь администраторами jenkins. Это оставляет мне время для поддержки ит и дает им свободу экспериментировать и работать с разной скоростью и уровнями знаний. Также может быть полезен JCASC (мне все еще нужно его попробовать). Вы можете предоставить каждой команде docker-compose, vagrant amp; scripts для установки собственного агента.
Bamboo, TFS, Gitlab и cruisecontrol сильно ограничивали мои возможности делегирования в прошлом.