Comments 15
Имея опыт нескольких лет работы с Jenkins, TeamCity и меньше с GitLab CI, всё что я могу сказать, это то, что все эти CI системы крайне слабо развиты и Jenkins выглядит самым гибким, но да, глюков хватает. Если я буду делать новый CI на новом проекте, то я скорее опять выберу Jenkins, в котором будет такой груви пайплайн, в котором написан только список реп которые нужно вотчить и чекаутить и потом вызов моего скрипта который сделает всю работу.
Тоже работал с разными CI, и писал общий Jenkins pipeline, который умел делать все со всеми десятками билдов, что были нужны.
И да, на Jenkins можно написать что угодно (с разными плагинами), и понятно, как решать проблемы - это же просто код на Groovy (ну, почти Groovy)
То с другими - вот у меня происходит проблема в каком-то странном месте. И я даже нашел CLI команду, которая бы делала, как мне надо. Но как ее вставить в нужное место этого стильного модного CI? Особенно если он пытается быть декларативным
Когда речь заходит про CI, я всё время вспоминаю цитату из Симпсонов:
> Check out The Willie World News! I reviewed the new tractors! They're all shite!
Выбор CI выглядит как поиск наименее плохого варианта :(
Для мелких проектов мне прекрасно зашел buildbot. Там конфиг - это тупо скрипт на пайтоне. Можно делать все что угодно.
Для совсем мелких проектов подходит почти всё, что угодно.
Проблемы начинаются когда увеличивается количество хотелок:
Хочется, чтобы в выводе сборки можно было узнать, какие тесты попадали и как?
Хочется иметь хоть какую-то статистику по тестам (тут с ностальгией вспоминаю TeamCity);
Хочется иметь разбивку по этам сборки, чтобы не нужно было искать ошибку в одном гигантском логе;
Хочется иметь нотификации авторам о падении тестов;
Хочется иметь интеграцию с системой контроля версий;
Хочется иметь возможность как-то управлять секретами;
Хочется иметь возможность делать цепочки сборок;
И т.д. и т.п.
При этом основные проблемы визуализации возникают в негативном сценарии: пока всё работает, оно никому не интересно. А вот возможность по выводу понять, что и где пошло не так, очень полезна.
Если использовать Declarative Pipeline, то Jenkinsfile может выглядеть вообще просто.
Screenshot
Если сборка совсем типовая, то всю эту сложность можно попытаться спрятать, но что-то мне подсказывает, что под капотом standardDeclarativePipelineTemplate творится жесть.
Ну и декларативный pipeline в Jenkins то еще поделие: это де-факто инструкция императивного pipeline, то есть всё равно нельзя сказать, что сделает pipeline не выполнив его.
Из-за этого, в частности:
вечно поломанная визуализация сборки;
объявления параметров и опций в pipeline влияет на следующую, а не на текущую сборку.
Хм. Ну я вам так скажу - у нас ради безопасности запретили вызов стольких методов и стольких классов, что самый простой метод что-то сделать в Jenkins - это выкачать из репозитория проект, и собрать его. Это может быть maven проект (и там GMAvenPlus на том же груви), или gradle проект, или любой другой проект на чем вам удобно. И вот проектам - им уже практически все можно. Т.е. вся логика переносится в сборку. А в Jenkins остается минимум, упрощающий настройки на скажем окружение (разработка или пром).
И вообще - Jenkins конечно (или скорее всего) самый навороченный из похожих инструментов, но он был написан очень давно, его тогда звали Hudson, и он тащит за собой столько легаси кода, что скажем писать под него плагины - да ну его нафиг...
Там конечно занимательные хитросплетения кода, но я бы не сказал что всё отвратительно. Тот же Гитлаб если была бы задача расширять, так же как это позволяет Женкинс, можно совсем закопаться и не вылезти, имхо.
Проблему безопасности можно частично решить через вынос общих запчастей в отдельную "доверенную" Jenkins Shared Library. Тогда на её код в src не будут распространяться ограничения песочницы, хотя на vars - всё ещё будут.
На счет плагинов я с Вами согланен: в Jenkins безумное количество legacy и очень разное качество кода от плагина к плагину.
Ну и отдельная проблема в том, что там модульность доведена до абсурда: обычно функционал затрагивает сразу несколько плагинов и не всегда очевидно, какой именно за какую часть фичи отвечает.
Ох не тот язык назвали brainfuck`ом, не тот
Я больше удивлен что Джум ещё жив и даже есть на хабре
Jenkinsfile – это не Groovy