Comments 11
О чём это и зачем это? Перевели First Run с оффсайта? Ок.
Можно было бы хотя бы написать о том, чем BuildBot лучше (или хуже), чем Hudson, Jenkins, CruiseControl и т.п., почему именно BuildBot, почему вы хотите потратить время на написание конфига на Python вместо того, чтобы накликать всё это мышкой в том же Jenkins, предупредить, что для сложных проектов кода на Python будет реально много, но показать, почему это нужно и как это помогает решить те или иные задачи.
Можно было бы хотя бы написать о том, чем BuildBot лучше (или хуже), чем Hudson, Jenkins, CruiseControl и т.п., почему именно BuildBot, почему вы хотите потратить время на написание конфига на Python вместо того, чтобы накликать всё это мышкой в том же Jenkins, предупредить, что для сложных проектов кода на Python будет реально много, но показать, почему это нужно и как это помогает решить те или иные задачи.
Да, начинал статью немного с другой целью, но вышло уж сильно похоже на туториал.
Я обязательно об этом расскажу, если надобность есть.
Я обязательно об этом расскажу, если надобность есть.
Конкретно у меня такой надобности нет — мы уже успешно используем BuildBot. Но поставьте себя на место читателя, который ничего не знает про BuildBot и прочитал вашу статью. Какие выводы он может для себя сделать? Да, есть такая штука BuildBot, вот с таким страшным Waterfall и кривой формой Force Build. Думаете этого достаточно, чтобы заинтересовать людей?
Я бы с удовольствием послушал, чем BuildBot принципиально отличается и какие преимущества перед Hudson или Jenkins. Мы вроде бы пока справляемся вполне с помощью hudson, плагинов и парой тулзов, написанных собственноручно. Так вот хотелось бы узнать, стоит тратить время на освоение BuildBot.
Побольше бы примеров, желательно из своей практики. Жду продолжения.
Мне тоже интересно, в чем принципиальное от Jenkins, Teamcity и т.п.
Допускаю, что процесс автотестирования может быть каким-то нетиповым и есть вероятность, что к готовой CI-системе нужно прикручивать какие-нибудь костыли. И правильно ли я понял, что можно просто настроить buildbot, а так же развернуть самописную CI систему с минимальными усилиями?
Мне тоже интересно, в чем принципиальное от Jenkins, Teamcity и т.п.
Допускаю, что процесс автотестирования может быть каким-то нетиповым и есть вероятность, что к готовой CI-системе нужно прикручивать какие-нибудь костыли. И правильно ли я понял, что можно просто настроить buildbot, а так же развернуть самописную CI систему с минимальными усилиями?
Для сборки Java, публикации тестов для нее подходит?
Вполне себе. Он умеет кушать xunit. Только вот Jenkins, всё-таки, лучше под яву заточен.
На Jenkins неудобно развесистые зависимости делать между проектами.
Чтобы элементарно собрать несколько проектов из разных репозиториев, собрать из них образ и запустить в параллели на этом образе несколько разных тестов требуется увлекательное кликанье мышкой по штук пяти заданиям с кучей свернутых менюшек (см. обычную в Jenkins «свертку» «Advanced») — по полчаса-часу на бранч — и это когда все отлажено и рука уже набита. Обещают workflow-plugin к нему, где все это на Groovy писать можно будет, но пока это early beta.
В остальном то Jenkins устраивает практически полностью.
Чтобы элементарно собрать несколько проектов из разных репозиториев, собрать из них образ и запустить в параллели на этом образе несколько разных тестов требуется увлекательное кликанье мышкой по штук пяти заданиям с кучей свернутых менюшек (см. обычную в Jenkins «свертку» «Advanced») — по полчаса-часу на бранч — и это когда все отлажено и рука уже набита. Обещают workflow-plugin к нему, где все это на Groovy писать можно будет, но пока это early beta.
В остальном то Jenkins устраивает практически полностью.
Sign up to leave a comment.
Continuous Integration вместе с buildbot: введение