(Малюнак ад ад
Прывітанне!
Мяне клічуць Яўген Чэркін, я праграміст каманды распрацоўшчыкаў у горназдабыўной кампаніі Поліметал.
Прыступаючы да любога буйнога праекту пачынаеш задумвацца: "Які ж софт лепш выкарыстоўваць для яго абслугоўвання?". ІТ-праект перад выпускам чарговай версіі праходзіць шэраг этапаў. Добра, калі ланцужок гэтых этапаў аўтаматызаваны. Сам па сабе аўтаматызаваны працэс выпуску новай версіі IT-праекта называецца Бесперапынная інтэграцыя. BuildBot для нас аказаўся добрым памочнікам, які рэалізуе гэты працэс.
У гэтым артыкуле я вырашыў прадставіць агляд магчымасцяў BuildBot. На што здольны гэты софт? Як да яго падступіцца і як выбудаваць з ім нармальныя ЭФЕКТЫЎНЫЯ ПРАЦОЎНЫЯ АДНОСІНЫ? Наш вопыт вы можаце прымяніць і ў сябе, стварыўшы на сваёй машыне працоўны сэрвіс зборкі і тэсціравання вашага праекта.
Змест
Змест
1. Чаму BuildBot?
Раней на habr-e я сустракаў артыкулы аб рэалізацыі Бесперапынная інтэграцыя з выкарыстаннем BuildBot. Напрыклад, здалася мне найбольш інфарматыўнай. Ёсць іншы прыклад - . Дадзеныя артыкулы можна заправіць , А наўздагон, на англійскай мове. У купэ атрымліваецца нядрэнная адпраўная кропка. Прачытаўшы гэтыя артыкулы, вы напэўна адразу захочаце што-небудзь на BuildBot зрабіць.
Стоп! А хтосьці ўвогуле выкарыстаў яго ў сваіх праектах? Аказваецца так, прымянілі яго ў сваіх задачах. Можна знайсці выкарыстання BuildBot і ў архівах кодаў Google.
Дык якая ж логіка людзей, якія выкарыстоўваюць Buildbot? Бо ёсць іншыя інструменты: CruiseControl и Джэнкінс. Адкажу так. Для большасці задач Джэнкінс і праўда будзе дастаткова. У сваю чаргу, BuildBot - Больш адаптыўны, пры гэтым задачы там вырашаюцца гэтак жа проста, як і ў Джэнкінс. Выбіраць вам. Але раз ужо мы шукаем прыладу для які развіваецца мэтавага праекту, то чаму б не абраць той, які дазволіць, адштурхваючыся ад простых крокаў, атрымаць сістэму зборкі, мелую інтэрактыўнасць і ўнікальны інтэрфейс.
У тых, чый мэтавы праект напісаны на python, узнікае пытанне: "Чаму б не абраць сістэму інтэгравання, у якой ёсць зразумелы інтэрфейс з пункта гледжання мовы, выкарыстоўванага ў праекце?". І тут самы час прадставіць перавагі BuildBot.
Такім чынам, наш "інструментальны квартэт". Для сябе я вызначыў чацвёрку асаблівасцей BuildBot:
- Гэта framework з адкрытым зыходным кодам пад ліцэнзіяй GPL.
- Гэта выкарыстанне python як прылада канфігуравання і апісанні патрабаваных дзеянняў
- Гэта магчымасць атрымліваць адказ з боку машыны, на якой адбываецца зборка.
- Гэта, нарэшце, мінімальныя патрабаванні да Хасту. Для разгортвання патрабуецца python і twisted, і не патрабуецца віртуальная машына і java-машына.
2. Канцэпцыя на чале з BuildMaster
Цэнтральнае месца ў архітэктуры размеркавання задач займае Будмайстар. Ён уяўляе з сябе сэрвіс, які:
- адсочвае змены ў дрэве зыходнікаў праекта
- пасылае каманды, якія варта выканаць сэрвісу Worker для пабудовы праекту і яго тэставання
- паведамляе карыстальнікаў аб выніках выкананых дзеянняў
Будмайстар канфігуруецца праз файл master.cfg. Гэта файл ляжыць у корані Будмайстар. Пазней я пакажу, як гэты корань ствараецца. Сам па сабе файл master.cfg утрымоўвае ў сабе python - скрыпт, які выкарыстоўвае выклікі BuildBot.
Наступны найболей важны аб'ект BuildBot мае назву Працоўны. Гэты сэрвіс можа быць запушчаны на іншым хасце з іншай OS, а можа і на тым, дзе Будмайстар. Таксама ён можа існаваць у спецыяльна нарыхтаваным віртуальным асяроддзі са сваімі пакетамі і зменнымі. Дадзеныя віртуальныя асяроддзі могуць быць падрыхтаваны пры дапамозе python-утыліт накшталт vertualenv, venv.
Будмайстар транслюе каманды кожнаму Працоўны-у, а той, у сваю чаргу, іх выконвае. Гэта значыць атрымліваецца, што працэс пабудовы і тэсціравання праекта можа ісці на Працоўны-е пад кіраваннем Windows і на іншым Worker-е пад кіраваннем linux.
Сheckout зыходных кодаў праекта адбываецца на кожным Працоўны-е.
3. Устаноўка
Такім чынам, паехалі. У якасці хаста я буду выкарыстоўваць Ubuntu 18.04/XNUMX. На ім я размяшчу аднаго Будмайстар-a і аднаго Працоўны-a. Але спачатку спатрэбіцца ўсталяваць python3.7:
sudo apt-get update
sudo apt-get install python3.7
Для тых каму трэба python3.7.2 замест 3.7.1 можна зрабіць наступнае:
sudo apt-get update
sudo apt-get software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get install python3.7
sudo ln -fs /usr/bin/python3.7 /usr/bin/python3
pip3 install --upgrade pip
Наступным крокам мы ўстанаўліваем Twited и BuildBot, а гэтак жа пакеты якія дазваляюць задзейнічаць дадатковы функцыянал BuildBot-І.
/*Все что под sudo будет установленно для всех пользователей в директорию /usr/local/lib/python3.7/dist-packages*/
#На хосте который производит мониторинг Worker-ов
sudo pip install twisted #Библиотека twisted
sudo pip install buildbot #BuildMaster
#Дополнительный функционал
pip install pysqlite3 #Устанавливаем базу sqllite в учебных целях
pip install jinja2 #framework наподобие django, для web и для почтовых рассыллок
pip install autobahn #Web cокеты для связи BuildMaster->Worker
pip install sqlalchemy sqlalchemy-migrate #Для отображения схемы базы данных
#Для Web отображения BuildBot-a
pip install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view
pip install python-dateutil #Отображение дат в web
#На стороне хоста который непосредственно осуществляет сборку и тестирование
pip install buildbot-worker #Worker
#Дополнительный функционал
sudo pip install virtualenv #Виртуальная среда
4. Першыя крокі
Час стварыць Будмайстар. Ён будзе ў нас у тэчцы /home/habr/master.
mkdir master
buildbot create-master master # Собственно сдесь и создаемНаступны крок. Створым Працоўны. Ён будзе ў нас у тэчцы /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Калі вы запусціце Працоўны, то па змаўчанні ён створыць у /home/habr/worker тэчку з назвай праекта, які пазначаны ў master.cfg. А ў татачку з назвай праекта ён створыць дырэкторыю будаваць, і далей у яе будзе рабіць кантроль. Рабочым каталогам для Працоўны-а стане дырэкторыя /home/habr/yourProject/build.
"Залаты" ключык
А зараз тое, дзеля чаго я пісаў папярэдні абзац: скрыпт, які Майстар запатрабуе ў Працоўны-а зрабіць выдалена ў гэтай дырэкторыі, не будзе выкананы, паколькі ў скрыпту няма правоў для запуску. Каб выправіць сітуацыю, спатрэбіцца ключык —umask=0o22, які накладвае забарону на запіс у гэтую дырэкторыю, але правы запуску пакіне. А нам толькі гэта і патрэбна.
Будмайстар и Працоўны усталёўваюць паміж сабой злучэнне. Здараецца, што яно абрываецца і Працоўны некаторы час чакае адказу ад Будмайстар-а. Калі адказу не рушыць услед, то падлучэнне перазапускаецца. Ключ —keepalive=60 якраз і патрэбен для таго, каб пазначыць час, па сканчэнні якога злучацца перазагружаецца.
5. Канфігурацыя. Пакрокавы рэцэпт
Канфігурацыя Будмайстар вядзецца на баку машыны, дзе мы выконвалі каманду create-master. У нашым выпадку - гэта каталог /home/habr/master. Канфігурацыйны файл master.cfg пакуль яшчэ не існуе, аднак сама каманда ўжо стварыла файл master.cmg.sample. Неабходна перайменаваць яго ў master.cfg.sample в master.cfg
mv master.cfg.sample master.cfgАдкрыем гэты master.cfg. І разбяром тое, з чаго ён складаецца. А пасля гэтага паспрабуем зрабіць свой канфігурацыйны файл.
master.cfg
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
name="all",
change_filter=util.ChangeFilter(branch='master'),
treeStableTimer=None,
builderNames=["runtests"]))
c['schedulers'].append(schedulers.ForceScheduler(
name="force",
builderNames=["runtests"]))
factory = util.BuildFactory()
factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental'))
factory.addStep(steps.ShellCommand(command=["trial", "hello"],
env={"PYTHONPATH": "."}))
c['builders'] = []
c['builders'].append(
util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
c['services'] = []
c['title'] = "Hello World CI"
c['titleURL'] = "https://buildbot.github.io/hello-world/"
c['buildbotURL'] = "http://localhost:8010/"
c['www'] = dict(port=8010,
plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
c['db'] = {
'db_url' : "sqlite:///state.sqlite",
}
5.1 BuildmasterConfig
c = BuildmasterConfig = {} BuildmasterConfig - базавы слоўнік канфігурацыйнага файла. Ён павінен быць абавязкова задзейнічаны ў канфігурацыйным файле. Для зручнасці выкарыстання ў кодзе канфігурацыі ўводзіцца яго псеўданім. "с". Назвы в c[«keyFromDist»] з'яўляюцца фіксаванымі элементамі для ўзаемадзеяння з Будмайстар. Пад кожны ключ у якасці значэння падстаўляецца які адпавядае аб'ект.
работнікі 5.2
c['workers'] = [worker.Worker("example-worker", "pass")]На гэты раз мы паказваем Будмайстар-у спіс з Працоўны-ов. Сам Працоўны мы стваралі , паказаўшы you-worker-name и пароль. Цяпер іх жа трэба паказаць замест example-worker и праходзіць .
5.3 change_source
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Па ключы change_source слоўніка c атрымліваем доступ да спісу, куды патрабуецца пакласці аб'ект, які апытвае рэпазітар з зыходным кодам праекта. У прыкладзе выкарыстоўваецца Git рэпазітар, які апытваецца з некаторай перыядычнасцю.
Першы аргумент з'яўляецца шляхам да вашага рэпазітара.
workdir уяўляе сабой шлях да тэчкі, дзе на баку Працоўны-а адносна шляхі /home/habr/worker/yourProject/build будзе git захоўваць лакальную версію рэпазітара.
філіял змяшчае канкрэтную галінку ў рэпазітары, за якой варта сачыць.
pollInterval змяшчае лік секунд, па заканчэнні якіх Будмайстар будзе апытваць рэпазітар на наяўнасць змен.
Ёсць некалькі метадаў адсочваць змены ў рэпазітары праекта.
Самы просты метад - гэта Апытанне, які мае на ўвазе, што Будмайстар перыядычна апытвае сервер з рэпазітаром. У выпадку, калі здзейсніць адбіў змены ў рэпазітары, то Будмайстар з некаторай затрымкай створыць унутраны аб'ект Мяняць і накіруе яго ў апрацоўшчык падзей Планавальнік, які і запусціць крокі па зборцы і тэсціраванню праекта на Працоўны-е. Сярод гэтых крокаў будзе паказаны абнаўленне рэпазітара. Менавіта на Працоўны-е створыцца лакальная копія рэпазітара. Дэталі гэтага працэсу будуць раскрыты ніжэй у наступных двух раздзелах ( и ).
Яшчэ больш хупавым метадам адсочвання змен у рэпазітары з'яўляецца прамая адпраўка паведамленняў ад сервера, на якім ён размешчаны, да Будмайстар-у аб змене зыходных кодаў праекту. У гэтым выпадку, як толькі распрацоўшчык зробіць здзейсніць, сервер з рэпазітаром праекта пашле паведамленне Будмайстар-у. А той, у сваю чаргу, яго перахопіць стварыўшы аб'ект PBChangeSource. Далей гэты аб'ект будзе перададзены ў Планавальнік, які і актывуе крокі па зборцы праекта і яго тэсціраванню. Важная частка гэтага спосабу гэтая праца з кручок-скрыптамі сервера ў рэпазітары. У скрыпце кручок-а, які адказвае за апрацоўку дзеянняў пры здзейсніць-е, неабходна выклікаць утыліту sendchange і пазначыць сеткавы адрас Будмайстар-а. Указаць трэба і сеткавы порт, які будзе слухаць PBChangeSource. PBChangeSource, дарэчы, з'яўляецца часткай Будмайстар-а. Гэта метад запатрабуе права адмін-a на серверы, дзе размешчаны рэпазітар праекту. Папярэдне спатрэбіцца зрабіць backup рэпазітара.
5.4/XNUMX shedulers
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
name="all",
change_filter=util.ChangeFilter(branch='master'),
treeStableTimer=None,
builderNames=["runtests"]))
c['schedulers'].append(schedulers.ForceScheduler(
name="force",
builderNames=["runtests"]))
планавальнікі – гэта элемент, які выступае трыгерам, які запускае ўвесь ланцужок зборкі і тэставанні праекта.
Тыя змены, якія былі зафіксаваны change_source, пераўтварыліся ў працэсе працы BuildBot-a у аб'ект Мяняць і зараз кожнае Sheduler на іх аснове будуе запыты на запуск працэсу зборкі праекту. Аднак ён вызначае і тое, калі гэтыя запыты перадаць далей у чаргу. Аб'ект Будаўнік захоўвае ў сябе чаргу запытаў і адсочвае стан бягучай зборкі на асобным Працоўны-э. Будаўнік існуе і на Будмайстар-e і на Працоўны-e. Ён жа пасылае з Будмайстар-а на Працоўны-а ўжо канкрэтны будаваць - серыю крокаў, якую варта выканаць.
Мы бачым, што ў бягучым прыкладзе такіх планавальнікі ствараецца 2 штукі. Прычым кожная мае свой тып.
SingleBranchScheduler - Адзін з самых папулярных класаў раскладу. Ён назірае за адной галінкай і спрацоўвае па зафіксаванай змене ў ёй. Калі ён бачыць змены, то можа адкласці адпраўку запыту на пабудову (адкласці на перыяд, пазначаны ў спецыяльным параметры treeStableTimer). У імя задаецца імя раскладу, які будзе адлюстроўвацца ў BuildBot-web-інтэрфейсе. У ChangeFilter задаецца фільтр, прайшоўшы які змены ў галінцы падахвочваюць расклад паслаць запыт на пабудову. У builderNames паказваецца імя будаўнік-a, якое мы зададзім крыху пазней. Імя ў нашым выпадку будзе тое ж, што і імя праекту: yourProject.
ForceScheduler вельмі простая штука. Гэты від раскладу спрацоўвае па пстрычцы мышы праз BuildBot-web-інтэрфейс. Параметры маюць тую ж сутнасць, што і ў SingleBranchScheduler.
PS №3. Раптам спатрэбіцца
Перыядычны - Гэта расклад, які спрацоўвае з пэўнай фіксаванай па часе перыядычнасцю. Выглядае выклік яго прыкладна так
from buildbot.plugins import schedulers
nightly = schedulers.Periodic(name="daily",
builderNames=["full-solaris"],
periodicBuildTimer=24*60*60)
c['schedulers'] = [nightly]
5.5/XNUMX BuildFactory
factory = util.BuildFactory()
factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental'))
factory.addStep(steps.ShellCommand(command=["trial", "hello"],
env={"PYTHONPATH": "."}))
periodicBuildTimer задае час гэтай перыядычнасці ў секундах.
BuildFactory стварае канкрэтны будаваць, які потым будаўнік адсылае на Працоўны. У BuildFactory паказваюцца крокі, якія трэба выканаць Працоўны-у. Крокі дадаюцца пры дапамозе выкліку метаду addStep
Першы дададзены крок у гэтым прыкладзе - git clean -d -f -f -x, затым Git Checkout. Гэтыя дзеянні закладзены ў параметры метад, які наглядна не паказаны, але мае на ўвазе значэнне па змаўчанні свежы. Параметр mode='incremental' кажа аб тым, што файлы з дырэкторыі, куды робіцца chechout, пры гэтым адсутныя ў рэпазітары, застаюцца некранутымі.
Другі дададзены крок - гэта выклік скрыпту. пробны c параметрам добры дзень на баку Працоўны-а з дырэкторыі /home/habr/worker/yourProject/build c зменнай асяроддзі PATHONPATH=… Такім чынам, вы можаце пісаць свае скрыпты і выконваць іх на баку Працоўны-a праз крок util.ShellCommand. Дадзеныя скрыпты можна пакласці прама ў рэпазітар. Тады пры chechout-е яны будуць трапляць у /home/habr/worker/yourProject/build. Аднак тады ёсць два "але":
- Працоўны павінен быць створаны з ключом для таго, каб ён не блакаваў права на выкананне пасля кантроль-І.
- Пры мярзотнік штуршок-е гэтых скрыптоў неабходна паказаць уласцівасць exacutable, Каб потым пры chechout-e правы на выкананне скрыпту Git не страціў.
5.6 будаўнікоў
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Пра тое, што такое Будаўнік было расказана . Цяпер я падрабязней распавяду аб тым, як яго стварыць. BuilderConfig з'яўляецца канструктарам будаўнік. Такіх канструктараў у c['builders'] можна задаць некалькі, паколькі гэта ліст аб'ектаў будаўнік тыпу. Цяпер ледзь перапішам прыклад ад BuildBot, наблізіўшы яго да нашай задачы.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Цяпер раскажу аб параметрах BuilderConfig.
імя задае імя будаўнік-a. Тут мы назвалі яго yourProject. Гэта значыць, што на Працоўны-е будзе створаны гэты самы шлях /home/habr/worker/yourProject/build. Sheduler шукае будаўнік якраз па гэтым імені.
workernames змяшчае ліст Працоўны-ов. Кожны з якіх павінен быць дададзены ў c['workers'].
завод - канкрэтны будаваць, з якім асацыіраваны будаўнік. Ён пашле аб'ект будаваць на Працоўны для выканання ўсіх крокаў, якія ўваходзяць у склад гэтага будаваць-І.
6. Прыклад сваёй канфігурацыі
Вось архітэктура прыкладу праекту, якую я прапаную рэалізаваць праз BuildBot
.
У якасці сістэмы кантролю версіямі будзем выкарыстоўваць svn. Сам рэпазітар будзе знаходзіцца ў нейкім воблаку. Вось адрас гэтага аблокі . У воблаку пад svn ёсць улікоўка username: карыстальнік, passwd: пароль. Скрыпты, якія ўяўляюць сабой крокі будаваць-a будуць таксама ляжаць у галінцы svn, у асобнай тэчцы buildbot/worker_linux. Гэтыя скрыпты ляжаць у рэпазітары з захаванай уласцівасцю выкананы.
Будмайстар и Працоўны працуюць на адным хасце project.host .Будмайстар захоўвае свае файлы ў тэчцы /home/habr/master. Працоўны ж захоўвае па наступным шляху /home/habr/worker. Сувязь працэсаў Будмайстар-а і Працоўны-а вядзецца праз 4000 порт па пратаколе BuildBot-a, гэта значыць 'pb' пратакол.
Мэтавы праект цалкам напісаны на python-ы. Задача адсачыць яго змены, стварыць executable файл, згенераваць дакументацыю, правесці тэставанне. У выпадку failure трэба ўсім распрацоўнікам даслаць паведамленне на пошту аб тым, што ёсць няўдала выкананае дзеянне.
Web адлюстраванне BuildBot мы падключым на 80 порт для project.host. Apatch ставіць не абавязкова. У складзе бібліятэкі скручаны ужо прысутнічае web сервер, BuildBot яго выкарыстоўвае.
Для захоўвання інфармацыі ўнутранага прызначэння для BuildBot будзем выкарыстоўваць sqlite.
Для паштовага рассылання патрэбен хост smtp.your.domain - на ім дазволена адпраўка лістоў з пошты [электронная пошта абаронена] без аўтэнтыфікацыі. Гэтак жа на хасце 'SMTP ' пратакол слухаецца на пасадзе 1025.
Задзейнічаных асоб у працэсе двое: адмін и карыстальнік. admin адмініструе BuildBot. user з'яўляецца асобай, якая здзяйсняе здзейсніць-ы.
Exacutable файл генеруецца праз pyinstaller. Дакументацыя генеруецца праз doxygen.
Для дадзенай архітэктуры я напісаў вось такі master.cfg:
master.cfg
import os, re
from buildbot.plugins import steps, util, schedulers, worker, changes, reporters
c= BuildmasterConfig ={}
c['workers'] = [ worker.Worker('yourWorkerName', 'password') ]
c['protocols'] = {'pb': {'port': 4000}}
svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk",
svnuser="user",
svnpasswd="password",
pollinterval=60,
split_file=util.svn.split_file_alwaystrunk
)
c['change_source'] = svn_poller
hourlyscheduler = schedulers.SingleBranchScheduler(
name="your-project-schedulers",
change_filter=util.ChangeFilter(branch=None),
builderNames=["yourProject"],
properties = {'owner': 'admin'}
)
c['schedulers'] = [hourlyscheduler]
checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk',
mode='full',
method='fresh',
username="user",
password="password",
haltOnFailure=True)
projectHost_build = util.BuildFactory()
cleanProject = steps.ShellCommand(name="Clean",
command=["buildbot/worker_linux/pyinstaller_project", "clean"]
)
buildProject = steps.ShellCommand(name="Build",
command=["buildbot/worker_linux/pyinstaller_project", "build"]
)
doxyProject = steps.ShellCommand(name="Update Docs",
command=["buildbot/worker_linux/gendoc", []]
)
testProject = steps.ShellCommand(name="Tests",
command=["python","tests/utest.py"],
env={'PYTHONPATH': '.'}
)
projectHost_build.addStep(checkout)
projectHost_build.addStep(cleanProject)
projectHost_build.addStep(buildProject)
projectHost_build.addStep(doxyProject)
projectHost_build.addStep(testProject)
c['builders'] = [
util.BuilderConfig(name="yourProject", workername='yourWorkerName', factory=projectHost_build)
]
template_html=u'''
<h4>Статус построенного релиза: {{ summary }}</h4>
<p>Используемый сервис для постраения: {{ workername }}</p>
<p>Проект: {{ projects }}</p>
<p>Для того что бы посмотреть интерфейс управления пройдите по ссылке: {{ buildbot_url }}</p>
<p>Для того что бы посмотреть результат сборки пройдите по ссылке: {{ build_url }}</p>
<p>Используя WinSCP можно подключиться к серверу c ip:xxx.xx.xxx.xx. Войдя под habr/password, забрать собранный executable файл с директории ~/worker/yourProject/build/dist.</p>
<p><b>Построение было произведено через Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="[email protected]",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['[email protected]'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
c['title'] = "The process of bulding"
c['titleURL'] = "http://project.host:80/"
c['buildbotURL'] = "http://project.host"
c['www'] = dict(port=80,
plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
c['db'] = {
'db_url' : "sqlite:///state.sqlite"
}
Для пачатку неабходна Будмайстар-а і Працоўны-a. Затым уставіць гэты файл master.cfg в /home/habr/master.
Наступным крокам патрабуецца запусціць службу Будмайстар-а
sudo buildbot start /home/habr/master
Затым запусціць службу Працоўны-a
buildbot-worker start /home/habr/worker
Гатова! Цяпер Buildbot будзе адсочваць змены і спрацоўваць па здзейсніць-у ў svn, выконваючы крокі зборкі і тэсціравання праекта з вышэйпаказанай архітэктурай.
Ніжэй я распішу некаторыя асаблівасці вышэйпаказанага master.cfg.
6.1 На шляху да свайго master.cfg
Падчас напісання свайго master.cfg будзе здзейснена нямала памылак, таму запатрабуецца чытанне log-файла. Ён захоўваецца як на Будмайстар-ec абсалютным шляхам /home/habr/master/twistd.log, так і на баку Працоўны-a з абсалютным шляхам /home/habr/worker/twistd.log. Па меры чытання памылкі і яе выпраўленні запатрабуецца перазагрузка службы Будмайстар-a. Вось як гэта робіцца:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Праца з svn
svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk",
svnuser="user",
svnpasswd="password",
pollinterval=60,
split_file=util.svn.split_file_alwaystrunk
)
c['change_source'] = svn_poller
hourlyscheduler = schedulers.SingleBranchScheduler(
name="your-project-schedulers",
change_filter=util.ChangeFilter(branch=None),
builderNames=["yourProject"],
properties = {'owner': 'admin'}
)
c['schedulers'] = [hourlyscheduler]
checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk',
mode='full',
method='fresh',
username="user",
password="password",
haltOnFailure=True)
Для пачатку зірнем на svn_poller. Гэта ўсё той жа інтэрфейс, які рэгулярна апытвае рэпазітар раз у хвіліну. У дадзеным выпадку svn_poller звяртаецца толькі да галінкі ствол. Загадкавы параметр split_file=util.svn.split_file_alwaystrunk задае правілы: як разбіваць структуру тэчак svn на галінкі. Ён жа прапануе ім адносныя шляхі. У сваю чаргу split_file_alwaystrunk спрашчае працэс, кажучы аб тым, што ў рэпазітары толькі ствол.
В Планавальнікі паказваецца ChangeFilter, які бачыць ні адзін і асацыюе з ім галінку ствол па зададзенай асацыяцыі праз split_file_alwaystrunk. Рэагуючы на змены ў ствол, запускае будаўнік з імем yourProject.
ўласцівасці тут патрэбен для таго, каб адмін атрымліваў рассылку ў выніках зборкі і тэставанні як уладальнік працэсу.
Крок будаваць-a кантроль здольны рабіць поўнае выдаленне любых файлаў, якія ляжаць у лакальнай версіі рэпазітара Працоўны-а. A затым рабіць поўны абнаўленне СВН. Рэжым настроены праз параметр mode=full, method=fresh. Параметр haltOnTailure кажа аб тым, што калі абнаўленне СВН будзе выкананы з памылкай, то ўвесь працэс зборкі і тэсціравання варта прыпыніць, бо далейшыя дзеянні не маюць сэнсу.
6.3 Вам ліст: reporters упаўнаважаны заявіць
журналістам - Гэта сэрвіс рассылання апавяшчэнняў на пошту.
template_html=u'''
<h4>Статус построенного релиза: {{ summary }}</h4>
<p>Используемый сервис для постраения: {{ workername }}</p>
<p>Проект: {{ projects }}</p>
<p>Для того что бы посмотреть интерфейс управления пройдите по ссылке: {{ buildbot_url }}</p>
<p>Для того что бы посмотреть результат сборки пройдите по ссылке: {{ build_url }}</p>
<p>Используя WinSCP можно подключиться к серверу c ip:xxx.xx.xxx.xx. Войдя под habr/password, забрать собранный executable файл с директории ~/worker/yourProject/build/dist.</p>
<p><b>Построение было произведено через Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="[email protected]",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['[email protected]'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
Ён можа рассылаць паведамленні .
MailNotifier выкарыстоўвае пошту для рассылкі апавяшчэнняў.
template_html задае шаблон тэксту для рассылання. Для стварэння разметкі выкарыстоўваецца html. Ён мадыфікаваны рухавіком (можна параўнаць з Джанга). BuildBot мае набор зменных, значэнні якіх падстаўляюцца ў шаблон падчас фармаванняў тэксту паведамлення. Гэтыя зменныя ўпісаны ў {{ падвойныя фігурныя дужкі}}. Так, напрыклад, рэзюмэ выводзіць статут выкананых аперацый, гэта значыць success або failure. А праектаў выведзе yourProject. Так, пры дапамозе кіраўнікоў каманд у jinja2, зменных BuildBot-а і сродкаў фарматавання радкоў python можна стварыць суцэль інфарматыўнае паведамленне.
MailNotifier змяшчае наступныя аргументы.
fromaddr - адрас, з якога ўсім будзе прыходзіць рассыланне.
sendToInterestedUsers=True адсылае паведамленне ўладальніку і карыстальніку, які зрабіў здзейсніць.
пошук - Суфікс, які трэба дадаць да імён карыстальнікаў, якія атрымліваюць рассылку. Так адмін як карыстальнік атрымае рассылку па адрасе [электронная пошта абаронена].
relayhost задае імя хаста, на якім адкрыты сервер SMTPДа smptPort задае нумар порта які слухае SMTP сервер.
mode="warning" кажа, што рассылку трэба рабіць толькі ў выпадку наяўнасці хаця б аднаго кроку будаваць-а, які скончыўся са статусам failure ці warning. У выпадку success рассыланне рабіць не патрабуецца.
extraRecipients змяшчае спіс асоб, каму трэба зрабіць рассылку акрамя ўладальніка і асобы, якая ажыццявіла здзейсніць.
messageFormatter з'яўляецца аб'ектам, якія задаюць фармат паведамлення, яго шаблон, і набор зменных даступных з jinja2. Такія параметры, як wantProperties=True и wantSteps=True задаюць гэты набор даступных зменных.
з['services']=[sendMessageToAll] падае спіс сэрвісаў, сярод якіх і будзе наш рэпарцёр.
Мы зрабілі гэта! Мае віншаванні
Мы стварылі ўласную канфігурацыю і ўбачылі функцыянал, на які здольны BuildBot. Гэтага, думаю, дастаткова для таго, каб зразумець, ці патрэбен гэты інструмент для стварэння вашага праекта. Ён вам цікавы? Ён вам спатрэбіцца? З ім зручна працаваць? Тады я пісаць гэты артыкул не дарма.
І яшчэ. Хацелася б, каб прафесійная супольнасць, якая выкарыстоўвае BuildBot, стала шырэй, мануалы перакладаліся, і прыкладаў станавілася яшчэ больш.
Усім дзякуй за ўвагу. Удачы.
Крыніца: habr.com