Comments 16
Работал с Jenkins и TeamCity (версии 5-7-летней давности). Наверное, Jenkins был чуть более гибким и функциональным.
Как же одна из главных особенностей по запуску и работе с пайпами? В дженкинсе проще сделать кучу разных сценариев, настроить чек-боксы, выбор переменных из списка, в дженкинсе пайп и репозиторий не связаны, в дженкинсе отличная ролевая модель. Аналогично можно расписать и про гитлаб. Нет ни слова про нагрузку, сколько тянет тот или иной инструмент. Берёте в сравнение гитлаб, но даже не указываете какой именно (есть бесплатная и несколько платных версий). Слабый анализ, коллеги.
Статья ни о чем.
По большому счету, что должна делать CI/CD система? Она должна определить наступление какого-то события, запустить действие, соответствующее этому событию, понять успешно ли оно завершилось, сохранить логи выполнения действия и, возможно, какой-то артефакт.
Событием может быть комит в гит, ручное действие, внешний триггер, завершение другого пайплайна, и обе эти системы +/- с этим справляются.
Но! Gitlab это opinionated система. Тоесть у неё есть своё мнение как хорошо и правильно делать CI/CD. На гитлаб довольно не просто сделать плохо. Гитлаб это пайплайны как код, который лежит фактически совместно с вашим репозиторием и является его частью.
Jenkins же это одна большая головная боль. Большинство инсталляций дженкинса превращаются со временем в помойку, где намешаны какие-то горе-плагины, кривые дженкинсфайлы и куски говнокода на груви (на котором наговнокодить почему-то легче чем на том же баше).
Я не знаю, каких возможностей гитлаб не хватает любителям дженкинса. Скорее всего это от того что они либо не разобрались в гитлаб, либо хотят странного.
Ну например это заявление в статье: гитлпб поддерживает только баш. В гитлаб ты можешь задать свой экзекутор - от пауэршелл до кастомного бинаря. Но я не понимаю людей, которые пишут гигантские портянки на баше или груви в CI/CD. 10 строк кода на джоб - всё что нужно в 99% при правильно спроектированном процессе CI/CD. Ну максимум 20. Если вы не можете убраться в этот предел, возможно написание пайплайнов не для вас?
Ну в смысле в статье стоило бы сравнить важные фичи этих систем. Какие источники действий и триггеры они могут обслуживать, возможности по построению и управлению пайплайнами, возможности организации интерфейса для работы с пользователями/управления пайплайнами, ролевую модель доступа, интеграцию с внешними системами (от sonarqube до jira и kubernetes). В этой же статье, сравнивается скорее ваш опыт работы с этими системами. И поскольку с гитлаб он кажется не велик, тут идёт очевидный перекос...
Этот комментарий, кстати, содержательней чем вся статья целиком. Также соглашусь с мнением, что автор похоже мало знаком с ГЛ...
Если ничего не путаю, то jenkins все таки это лоепльная система, а гитлабовская часть гитлаба, которую легко могут отключить по чьей то воле.
Наговнокодить же можно на чем угодно. Это не проблема инструмента, а того кто им пользуется.
Про 10-20 строк кода это же шутка, да?
Как человек долгое время проработавший с Gitlab, характеризую Jenkins как любовь и ненависть в одном флаконе (огромное кол-во времени тратится на решение всевозможных проблем с плагинами, groovy кодом и т.д).
"В Jenkins вы можете взять язык программирования Groovy или Java и написать код, тесты и др. " - не могли бы вы уточнить как и для чего можно выбрать Java? Насколько я знаю в Jenkins есть возможность использовать любые Java библиотеки, но работать все равно придется с Groovy. Также с недавнего времени стал доступен выбор Kotlin, но его функциональность также весьма ограничена.
Не знаю как в дженкинс, но Gitlab CI/CD при работе с несколькими кластерами, вам нужно заплатить за ee версию
Интересно было бы еще почитать сравнение с Azure DevOps server, бывший Team Foundation Server (TFS)
На текущем проекте имел возможность переносить несложный пайплайн с Jenkins Freestyle jobs на Jenkins Pipeline, а после с Jenkins Pipeline на Gitlab CI/CD
Freestyle -> Pipeline. Это была боль. Я даже не мог представить, что в такой простой задаче я встречу так много проблем и багов с самим jenkins, при этом их баг-трекер https://issues.jenkins.io/ как-то странно индексируется гуглом, и чтобы найти похожую проблему надо прям извертеться написать запрос. Про проблемы с плагинами, скудостью официальной доки я даже говорить не хочу.
Pipeline -> Gitlab CI/CD. Оказалось Gitlab CI/CD имеет небольшой набор возможностей (по сравнению с Jenkins) и даже платная версия не сильно помогает. Например, очень не хватает возможности авто-запуска джоб сразу после запуска ручной джобы. Радует, что багов по сравнению с Jenkins меньше и они активно развивают свой продукт, например добавили возможность видеть список переменных при запуске джобы вручную.
Jenkins и Gitlab CI/CD: что выбрать