Почему Jenkins? ( Рассуждения о причинах выбора "Jenkins" в качестве CI/CD-сервиса в корпоративной среде. )

Некоторое время у меня не было определённости, каким инструментарием управлять процессами CI/CD сборок сразу для "Linux", "MacOS", "Microsoft Windows", а также, потенциально, для мобильных платформ. Была мысль воспользоваться для управления сборками сервером "GitLab", но позже стало понятно, что эта идея хороша лишь для небольшой команды с одним-двумя продуктами.

Прежде всего, в случае использования "GitLab", для управления удалёнными стендами сборки (CI) и серверами развёртывания (CD) понадобится постоянное прямое соединение с центром управления, что делает схему небезопасной в том смысле, что к хранилищу исходного кода придётся организовать доступ отовсюду - надо оно на самом деле, или нет. Таким образом, в корпоративной среде сервис CI/CD должен быть реализован в виде отдельного сервера, чтобы минимизировать прямые бесконтрольные соединения с хранилищем репозиториев кода.

В процессе тестирования разных вариантов использования выявлено, что "GitLab" откровенно заточен под программные продукты на "Linux" и "MacOS", настолько, что для агента исполнения "GitLab Runner" в "Microsoft Windows" даже отображение символов национальных кодировок (русской, например) журнала событий простыми методами невозможно настроить - для "Linux" и "MacOS" без проблем, а вот транскодированием комбинаций "cp866", "cp1251" и "utf8" разработчики "GitLab" фактически попросту отказались заниматься.


Рассматривалась возможность использовать "JetBrains TeamCity". Изучение функционала выявило, что этот инструмент скорее для CI, нежели для CD - во всяком случае неоднократно отмечались проблемы с распределением и закреплением задач CI/CD за целевыми агентами исполнения, что как-то можно принять в процедурах "сборки", но совершенно недопустимо при "деплое". Кроме того, опыт эксплуатации продукта "YouTrack" этой же компании показал, что решения у "JetBrains" красивые, но местами непроработанные, и в командах более десятка-двух сотрудников уже недостаточно функциональные (в частности, буквально на днях выяснилось, что в "YouTrack" нет журнала изменения конфигурации - что невероятно с точки зрения эксплуатационника).

Варианты "Travis", "Bamboo", "CircleCI" и тому подобных отпадают пока ввиду отсутствия компетенций у специалистов ближнего круга.

Таким образом, на роль сервиса управления CI/CD наиболее вероятным кандидатом оказывается "Jenkins", у которого не выявлено никаких проблем с кодировками (свойственных "GitLab"-у).

Проблемы с безопасностью "Jenkins", выраженные в невозможности полностью взаимно изолировать конфигурации проектов обходятся запуском на одном сервере нескольких инстансов приложения внутри docker-контейнеров, что гарантирует изоляцию конфигураций.