2009-08-02 2 views
12

В последнее время я изучаю buildbot, и отсутствие хорошей документации и конфигураций образцов затрудняет понимание того, как обычно используется buildbot.Как масштабировать buildbot в компании

В соответствии с руководством по монтажу каждый строительный мастер несет ответственность за 1 базу кода. Это означает, что компания, которая хочет использовать buildbot на, скажем, 10 проектах, должна поддерживать 10 различных наборов установок buildbot (конфигурации master-slave, открытые порты, веб-сайты с выходом и т. Д.). Это действительно так, как это делается? У меня отсутствует опция, которая создает сетку, которую легко поддерживать и контролировать?

Спасибо!

+1

FWIW, в настоящее время ведутся работы по улучшению масштабирования buildbot, спонсируемого проектом Mozilla. (Кто управляет _very large_ buildmaster). Подробные сведения см. В списке почтовых сообщений buildbot. – Macke

ответ

4

В моем месте работы мы используем Buildbot для тестирования одной программы по нескольким архитектурам и версиям Python. Я использую один мастер сборки для наблюдения за 16 подчиненными. Каждый набор подчиненных устройств вытягивается из другого репо и проверяет его на Python 2.X.

Из моего опыта было бы легко сконфигурировать одного мастера сборки, чтобы запускать проекты. Это может быть не очень хорошая идея, потому что страница с водопадом (где результаты отчетов о подчиненных сборках) может сильно перегружаться более чем несколькими подчиненными. Если вам удобно прокручивать страницу с длинными водопадами, это не будет проблемой.

EDIT:

Команда обновления в master.cfg:

test_python26_linux.addStep(ShellCommand, name = "update pygr", 
    command = ["/u/opierce/PygrBuildBot/update.sh","000-buildbot","ctb"], workdir=".") 

000-BuildBot и CTB дополнительные параметры, чтобы указать, какая ветвь и репо тянуть из, чтобы получить информацию. Скрипт update.sh - это то, что я написал, чтобы избежать несвязанной проблемы git. Если вы хотите запускать разные проекты, вы можете написать что-то вроде:

builder1.addStep(ShellCommand, name = "update project 1", 
    command = ["git","pull","git://github.com/your_id/project1.git"], workdir=".") 

(the rest of builder1 steps) 

builder2.addStep(ShellCommand, name = "update project 2", 
    command = ["git","pull","git://github.com/your_id/project2.git"], workdir=".") 

(the rest of builder2 steps) 

Эти два проекта не обязательно должны быть связаны. Buildbot создает каталог для каждого строителя и выполняет все шаги в этом каталоге.

+0

Основная конфигурация просто сообщает подчиненному устройству о запуске серии команд терминала. Чтобы запустить другую версию или другой проект, вы просто скажете, чтобы он вытащил из другого репо. Поскольку вы можете индивидуализировать команды для каждого подчиненного устройства, у вас может быть каждый подчиненный, работающий на другой версии/проекте/независимо. –

+0

Нет, это противоположность тому, что я говорю. Идея непрерывной интеграции - вытащить из хранилища и запустить сборку в реальном времени. Мы используем git для контроля версий. –

+0

Наконец-то я понял, что вы имеете в виду, и на самом деле это хорошая идея. Только примечание стоит дать - мы решили использовать категории, чтобы теперь мы могли разделить вид водопада в соответствии с этими категориями, и поэтому каждый разработчик видит только те проекты, которые его интересуют. – abyx

3

FYI, BuildBot 0.8.x поддерживает несколько репозиториев на одном хозяине, что упрощает некоторые вещи.

+1

Вы можете увидеть пример в [связанном вопросе] (http://stackoverflow.com/questions/2795386/support-for- множественные-хранилища, использующий-BuildBot/7148534 # 7148534) – hithwen

Смежные вопросы