PodnimatelPingvinov 10 фев 2019 в 19:03

Buildbot: сказ с примерами еще об одной системе непрерывной интеграции

15 мин

12K

Open source*Python*Twisted*Системы сборки*DevOps*

Туториал

+20

Комментарии 22

sshikov 10 фев 2019 в 19:38

>но у своих Java конкурентов
Но при этом ни Jenkins, ни Teamcity даже не упомянуты. Что у них выигрывает по потреблению памяти — вполне верю (хотя много лет уже не сталкивался с тем, чтобы CI не хватало памяти), а вот по функциональности — как-то сомнительно.

Можно писать пайплайны на питоне? Ну это не факт что преимущество по сравнению с возможностью писать их же на груви. Оба — универсальные широко известные языки общего назначения, и те примеры, что вы показываете, они вполне соответствуют по сложности тому, что я вижу каждый день на Jenkins.

То что можно выбрать инструмент, который программируется на любимом языке — это скорее всего хорошо, но для объективности более детально сравнить с Jenkins наверное не помешало бы.

PodnimatelPingvinov 10 фев 2019 в 21:52

Я и не говорю что по функциональности выигрывает. Надо очень сильно постараться (если вообще возможно), найти то, что можно сделать в Jenkins'e, но нельзя в билдботе и наоборот. Сравнение таких мощных инструментов — весьма дискуссионная штука. Тут скорее на первый план выходят какие-то личные предпочтения, от языка до внешнего вида веб-интерфейса. Иногда тот или иной инструмент используется по историческим причинам. Я не был обременен легаси, а потому выбрал билдбот вместо дженкинса по 2 причинам: мне больше нравится питон и была важна ресурсозатратность. Если разработка основного проекта идет на джаве и есть мощный сервак, то разработчику скорее всего примешивать туда питон будет ни к чему и он выберет дженкинс.

sshikov 10 фев 2019 в 22:07

Да это в общем была и не претензия, просто вы как-то забыли про пару самых известных пожалуй инструментов, что было странно.

acmnu 11 фев 2019 в 09:41

Ну это не факт что преимущество по сравнению с возможностью писать их же на груви.

Если бы там был чистый груви, то вопросов не было бы, а так, это язык на базе груви запускаемый в песочнице, под которую нет sdk. Вопросы отладки не проработаны.

Да и груви, по сути популярен только среди Java тусовки и найти девопса на рынке, которые это знает и любит тяжко. Мой опыт собеседований говорит, что процентов 80 народа используют Jenkins как cron, запускающий скрипты на Python или Ansible. Pipelines знают единицы.

sshikov 11 фев 2019 в 10:17

Я и сказал, что это относительное преимущество. У вас много пишущих на питоне — вам это хорошо. У нас как раз Java тусовка — и нам груви более чем хорош.

P.S. Pipelines тривиальны. Просто примените внушение, и пусть не отлынивают от работы ;)

Про песочницу с отладку — согласен. Особенно доставляет, когда админы решат по каким-то своим соображениям безопасности запретить часть методов.

acmnu 11 фев 2019 в 11:03

Pipelines тривиальны

Да? А вы пробовали использовать shared_lib? Особенно не выключая безопасность. Если да, то напишите статью об этом. Лично я буду премного благодарен.

sshikov 11 фев 2019 в 15:20

> А вы пробовали использовать shared_lib? Особенно не выключая безопасность.
Пробовал. Нам безопасность никто и не дает отключать, она включена, причем в режиме параноика (на мой взгляд) — допустим, пайплайн не может сканировать файловую систему, независимо от того, в какой мы папке — внутри workspace, или где-то еще. При этом скажем maven build вполне может это делать.

Суть моего заявления в том, что они тривиальны для освоения. А что они во всем удобны — я не говорил. shared_lib тоже самое.

acmnu 11 фев 2019 в 15:43

Я имел ввиду, что я не знаю варианта нормально разрабатывать что-то под shared lib, поскольку не sdk, не эмулятора не наблюдается — приходится деплоить изменение в Jenkins на каждый чих, что мягко говоря не тривиально.

sshikov 11 фев 2019 в 15:55

Так я согласен. Речь о том, что сами по себе shared lib — довольно простая штука. Но писать их — не слишком удобно, и не только потому, что их отладить автономно нельзя, но и потому скажем, что одна библиотека — один репозиторий. А почему собственно так? У меня вот репозитории заводят админы — и что, я сижу в рамках одной shared lib?

SirEdvin 12 фев 2019 в 12:20

Можно писать пайплайны на питоне? Ну это не факт что преимущество по сравнению с возможностью писать их же на груви. Оба — универсальные широко известные языки общего назначения, и те примеры, что вы показываете, они вполне соответствуют по сложности тому, что я вижу каждый день на Jenkins.

Последний раз, когда я пользовался jenkins, у них не работал цикл forEach в груви. Было очень классно, конечно, но суррогатные языки — это путь в никуда

sshikov 12 фев 2019 в 12:50

Он назвал тебя желтым земляным червяком! :)

У всех работал, а у вас почему-то не работал. groovy на сегодня 15 лет от роду, в то что там баги бывают — так это наверняка, что баги в дженкинсе бывают — тоже без сомнения. Но при этом и тот и другой настолько распространены, что в длительное существование бага «не работает forEach» я поверить не могу.

SirEdvin 12 фев 2019 в 12:52

Как насчет где-то двух лет? Пруф и там есть ссылка на issues.

Проблему уже описали выше — groovy в дженкинсе это не groovy, это квазиязык, который похож на groovy.

sshikov 12 фев 2019 в 13:10

Не, тут вы ошибаетесь. Это обычный груви, просто ограниченный в правах. Язык pipeline — это DSL на базе груви, то что вы пишете внутри — это тело closures, ничего более. И это кстати хорошо видно в стеках, которые приводятся по вашим ссылкам. Ровно также работают всякие билдеры (MarkupBuilder к примеру).

Да, там все сложнее, чем в простом груви. Но на самом деле, такого рода DSL на питоне вы вообще не сделаете скорее всего.

vasyan 10 фев 2019 в 20:16

Так и не понял, зачем оно надо, если есть Teamcity, где можно мышкой натыкать конфигурацию, есть плагины и куча инфы на stackoverflow. Чтобы настроить CI для среднего проекта вообще мозг включать не надо, можно следовать гайдам.

PodnimatelPingvinov 10 фев 2019 в 22:10

Тут справедливы все те же размышления, что я привел в ветке выше касательно дженкинса. Конкретно про TeamCity — это все же не полностью бесплатный продукт, а билдбот — тру open source.

Про настройку для среднего проекта — у любой уважающей себя ci есть раздел наподобие «getting started», если ему следовать, то задумываться почти не надо. Билдбот тут не исключение. Для себя я не считаю настройку мышкой через интерфейс проще написания конфигурационного файла, а прочитав документацию еще и хорошо понимаю, что там происходит на самом деле.

acmnu 11 фев 2019 в 09:43

Так и не понял, зачем оно надо, если есть Teamcity, где можно мышкой натыкать конфигурацию

Посмотрю я как вы будет натыкивать скажем 1к джобов.

sshikov 11 фев 2019 в 10:19

Кстати, чистая правда. Данный конкретный продукт на меня не произвел впечатление, но сам подход в виде написания скриптов — он вполне имеет право на жизнь. Скажем, дженкинсовский CLI достаточно примитивен, и зачастую хочется большего. А неудобно.

acmnu 11 фев 2019 в 11:07

Ну, на самом деле, в TC неплохая автоматизация. Точнее, скорее прототипирование на Kotlin, по типу Jenkins DSL, что были модны до Pipelines и JJB.

acmnu 11 фев 2019 в 11:11

Я пробовал внедрить BuildBot и столкнулся главным образ с то же проблемой, что и Pipelines — заточенность на один юз кейс: есть репа, с кодом — его нужно собрать. Мне бы хотелось видеть более универсальную платформу, которая занимается не только сборкой, но доставкой, отслеживаением артефактов и т.д. Строить такую вещь на BuildBot, как и на чистом Jenkins неудобно.

sshikov 12 фев 2019 в 12:51

У меня было похожее. Только немного другие кейсы — есть скажем JIRA, там есть баги и задачи, нужно создавать потоки сборки того, что попадет в релиз. Тоже было очень неудобно.