(Attēls no no
Sveiki!
Mani sauc Evgenijs Čerkins, esmu programmētājs izstrādātāju komandā ieguves uzņēmumā Polymetal.
Sākot jebkuru lielu projektu, tu sāc domāt: "Kāds softs ir labākais, lai to apkalpotu?" IT projekts pirms nākamās versijas izlaišanas iziet vairākus posmus. Labi, ja šo posmu ķēde ir automatizēta. Pats automatizētais process jaunas IT projekta versijas izlaidei tiek saukts par Nepārtraukta integrācija. BuildBot kas izrādījās labs palīgs šī procesa īstenošanā.
Šajā rakstā es nolēmu sniegt pārskatu par iespējām BuildBot. Ko šis softs spēj? Kā pie tā pieiet un kā izveidot ar to normālas EFEKTĪVAS DARBA ATTIECĪBAS? Mūsu pieredzi jūs varat pielāgot savām vajadzībām, izveidojot savā mašīnā darba būvniecības un testēšanas servisu jūsu projektam.
Satelīte
Satelīte
1. Kāpēc BuildBot?
Iepriekš habr-e esmu sastapis rakstus par realizācijas Nepārtraukta integrācija izmantojot BuildBot. Piemēram, šķita visinformatīvākais. Ir cits piemērs — . Šos rakstus var papildināt , bet pārsteigumiem angļu valodā. Kopsummā tas veido labu sākumpunktu. Izlasot šos rakstus, jūs noteikti uzreiz vēlēsities kaut ko par BuildBot izdarīt.
Apstājos! Vai kāds to vispār ir izmantojis savos projektos? Izrādās, jā, to pielietoja savām vajadzībām. Var atrast lietojuma BuildBot un Google kodu arhīvos.
Kāda tad ir cilvēku loģika, kuri izmanto Buildbot? Ведь есть другие инструменты: CruiseControl un Jenkins? Atbildēšu tā. Lielākajai daļai uzdevumu Jenkins un patiešām pietiks. Savukārt, BuildBot — adaptīvāks, turklāt uzdevumi tiek risināti tikpat viegli, kā Jenkins. Izvēle ir jūsu. Bet, ja mēs meklējam rīku attīstošam mērķa projektam, tad kāpēc neizvēlēties to, kas ļaus no vienkāršiem soļiem iegūt būvniecības sistēmu ar interaktivitāti un unikālu saskarni.
Tiem, kuru mērķa projekts ir uzrakstīts Python, rodas jautājums: "Kāpēc nepiedāvāt integrācijas sistēmu ar skaidru interfeisu, ņemot vērā programmēšanas valodu, kas izmantota projektā?". Un šeit ir īstais brīdis iepazīstināt ar priekšrocībām. BuildBot.
Tātad, mūsu "instrumentālā kvarteta" komanda. Esmu izstrādājis četras īpašības. BuildBot:
- Tas ir atvērtā koda ietvars ar GPL licenci.
- Tas ir Python izmantošana kā konfigurācijas rīks un nepieciešamo darbību aprakstīšana.
- Tas ir iespēja saņemt atbildi no mašīnas, uz kuras notiek būvēšana.
- Visbeidzot, minimālās prasības pret hostu. Ir nepieciešams Python un Twisted, un nav nepieciešama virtuālā mašīna vai Java mašīna.
2. Koncepcija ar BuildMaster priekšgalā
Centrālā vieta uzdevumu sadales arhitektūrā ieņem BuildMaster.Tas ir pakalpojums, kas:
- uzrauga izmaiņas projekta avota kodā.
- nosūta komandas, kuras jāizpilda Worker pakalpojumam projekta būvēšanai un testēšanai.
- informē lietotājus par paveikto darbību rezultātiem.
BuildMaster. to var konfigurēt, izmantojot failu master.cfg.Šis fails atrodas direktorijā BuildMaster.. Vēlāk es parādīšu, kā šī direktorija tiek izveidota. Pats fails master.cfg. ietver Python - skriptu, kas izmanto izsaukumus. BuildBot.
Nākamais visvairāk svarīgais objekts BuildBot ir nosaukts Darbinieks. Šo pakalpojumu var palaist citā hostā ar citu operētājsistēmu vai arī tajā pašā, kurā ir BuildMaster.. Tas var pastāvēt arī īpaši sagatavotā virtuālā vidē ar savām pakām un mainīgajiem. Šīs virtuālās vides var sagatavot, izmantojot Python utilītas, piemēram, virtualenv, venv..
BuildMaster. pārvērš komandas ikvienam Darbinieks-am, un tas, savukārt, tās izpilda. Tātad process projekta būvēšanai un testēšanai var noritēt uz Darbinieks-a, kas darbojas Windows, un uz cita Worker, kas darbojas Linux.
Checkout projekta avota kodu notiek katrā Darbinieks-ā.
3. Uzstādīšana
Tātad, uz priekšu. Kā hostu es izmantosiu Ubuntu 18.04. Uz tā es izvietošanu veicu ar vienu BuildMaster.-u un vienu Darbinieks-u. Bet vispirms būs nepieciešams instalēt Python 3.7:
sudo apt-get update
sudo apt-get install python3.7
Tiem, kam nepieciešams Python 3.7.2, nevis 3.7.1, var izdarīt šādi:
sudo apt-get update
sudo apt-get install 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
Nākamais solis ir instalēt Twisted. un BuildBot, kā arī pakotnes, kas ļauj izmantot papildu funkcionalitāti BuildBot-a.
/*Все что под 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. Pirmie soļi
Laiks izveidot BuildMaster.. Tas atradīsies mūsu mapē /home/habr/master.
mkdir master
buildbot create-master master # Šeit mēs tiešām izveidojamNākamais solis. Izveidosim Darbinieks. Tas atradīsies mūsu mapē /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Kad jūs palaidīsiet Darbinieks, tad pēc noklusējuma tiks izveidota /home/habr/worker mape ar projekta nosaukumu, kas norādīts master.cfg.. Šajā projekta mapē tiks izveidota direktorija build, un tālāk tajā tiks veiktas checkout. Darba katalogs priekš Darbinieks-a būs direktorija /home/habr/yourProject/build.
Zelta atslēga
Un tagad tas, kādēļ es rakstīju iepriekšējo paragrāfu: skripts, kas Master prasīs no Darbinieks-a veikt attālināti šajā direktorijā, netiks izpildīts, jo skriptam nav tiesību izpildīt. Lai novērstu šo situāciju, nepieciešama atslēga --umask=0o22, kas ierobežo rakstīšanu šajā direktorijā, bet atstāj izpildes tiesības. To mums arī vajag.
BuildMaster. un Darbinieks izveido savienojumu. Gadās, ka tas pārtrūkst un Darbinieks zināmu laiku gaida atbildi no BuildMaster.-a. Ja atbildes nebūs, tad savienojums tiks restartēts. Atslēga --keepalive=60 tieši ir vajadzīga, lai norādītu laiku, pēc kura connect tiek restartēts.
5. Konfigurācija. Soli pa solim recepte
Konfigurācija BuildMaster. notiek mašīnā, kur mēs izpildījām komandu create-master. Mūsu gadījumā — tas ir katalogs /home/habr/master. Konfigurācijas fails master.cfg. vēl nav izveidots, tomēr pati komanda jau ir izveidojusi failu master.cmg.sample. Jāmaina tā nosaukums uz master.cfg.sample par master.cfg.
mv master.cfg.sample master.cfgAtvērsim šo master.cfg.. Un analizēsim, no kā tas sastāv. Pēc tam mēs mēģināsim izveidot savu konfigurācijas failu.
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 — bāzes konfigurācijas vārdu krājums. Tas obligāti jāizmanto konfigurācijas failā. Lai atvieglotu konfigurācijas koda izmantošanu, tiek ieviests tā pseidonīms. «c». Nosaukumi par c[«keyFromDist»] ir fiksēti elementi mijiedarbībai ar BuildMaster.. Katram atslēgas vērtībai tiek piešķirts attiecīgais objekts.
5.2 darbinieki
c['workers'] = [worker.Worker("example-worker", "pass")]Šoreiz mēs norādām BuildMaster.- sarakstu no Darbinieks-iem. Mēs Darbinieks jaunus darbiniekus izveidojām , norādot your-worker-name un password. Tagad tos pašu jānorāda vietā example-worker un pass .
5.3 mainīt_avotu
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Pa atslēgu change_source vārdnīcas c mēs piekļūstam sarakstam, kurā jānovieto objekts, kas aptaujā projekta kodu repozitoriju. Piemērā tiek izmantots Git repozitorijs, kas tiek aptaujāts noteiktā intervālā.
Pirmais arguments ir ceļš uz jūsu repozitoriju.
workdir ir ceļš uz mapīti, kurā pusē Darbinieks-a attiecībā uz ceļu /home/habr/worker/yourProject/build git uzglabās vietējo repozitorija versiju.
branch satur konkrētu filiāli repozitorijā, kuru jāseko.
pollInterval satur skaitu sekunžu, pēc kurām BuildMaster. tiks pietaujots repozitorijs par izmaiņām.
Ir vairāki veidi, kā uzraudzīt izmaiņas projekta repozitorijā.
Vienkāršākais veids ir Pietaugošana, kas nozīmē, ka BuildMaster. periodiski vaicā serverim, kurā ir glabātuve. Ja commit tiek atspoguļoti grozījumi glabātuvē, tad BuildMaster. ar zināmu aizkavi tiks izveidots iekšējs objekts Change un nosūtīts notikumu apstrādātājam Scheduler, kurš uzsāks projekta būvniecības un testēšanas soļus Darbinieks-ā. Starp šiem soļiem tiks norādīts update glabātuves. Tieši uz Darbinieks-ā tiks izveidota vietējā glabātuves kopija. Šī procesa detaļas tiks atklātas zemāk esošajos divos punktos ( un ).
Vēl elegants veids, kā izsekot izmaiņām glabātuvē, ir tiešs ziņojumu nosūtīšana no servera, uz kura tas ir izvietots, uz BuildMaster.-u par projekta avota kodu izmaiņām. Šajā gadījumā, tiklīdz izstrādātājs veiks commit, serveris ar projekta glabātuvi nosūtīs ziņojumu BuildMaster.-am. Tas, savukārt, to pieņems, izveidojot objektu PBChangeSource. Pēc tam šis objekts tiks nosūtīts uz Scheduler, kurš aktivizēs projekta būvniecības un testēšanas soļus. Būtiska šī veida daļa ir darbs ar hook-servera skriptiem glabātuvē. Skriptā hook-ā, kas atbild par darbību apstrādi pie commit-a, ir jāizsauc utilīta sendchange un jānorāda tīkla adrese BuildMaster.-am. Jānorāda arī tīkla ports, kuru klausīs PBChangeSource. PBChangeSource, starp citu, ir daļa no BuildMaster.-a. Šī metode prasīs tiesības admin-am serverī, kurā atrodas projekta glabātuve. Iepriekš nepieciešams izveidot dublējumu glabātuvei.
5.4 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"]))
schedulers – tas ir elements, kas darbojas kā ģenerators, uzsākot visu būvniecības un testēšanas ķēdi projekta.
Izmaiņas, kas ir fiksētas change_source, ir pārvērstas darba procesā BuildBot-ā par objektu Change un tagad katrs Scheduler balstoties uz tām veido pieprasījumus būvniecības procesa uzsākšanai. Tomēr tas nosaka arī to, kad šos pieprasījumus nosūtīt tālāk rindā. Objekts Builder uztur pieprasījumu rindu un izseko pašreizējās būvniecības stāvokli atsevišķā Darbinieks-ā. Builder pastāv arī uz BuildMaster.-ā un uz Darbinieks-ā. Tas sūta no BuildMaster.-ā uz Darbinieks-am jau konkrētu build — soļu sēriju, kas jāveic.
Mēs redzam, ka pašreizējā piemērā izveidojas 2 vienības. Turklāt katrai ir savs tips. schedulers SingleBranchScheduler
SingleBranchScheduler – ir viens no populārākajiem grafiku veidiem. Tas uzrauga viena zara un reaģē uz fiksētām izmaiņām tajā. Kad tas redz izmaiņas, tas var atlikt pieprasījuma nosūtīšanu būves izsaukumam (atliekot uz laiku, kas norādīts īpašajā parametrā treeStableTimer). name Tiek norādīts grafika nosaukums, kas tiks attēlots BuildBot-web-interfērā. ChangeFilter tiek norādīts filtrs, pēc kura izmaiņas zara mudinās grafiku nosūtīt pieprasījumu uz būvi. builderNames norāda nosaukumu builder-a, ko mēs norādīsim nedaudz vēlāk. Nosaukums mūsu gadījumā būs tāds pats kā projekta nosaukums: yourProject.
ForceScheduler ir ļoti vienkārša lieta. Šis grafika veids reaģē ar peles klikšķi caur BuildBot-web-interfēru. Parametri ir tādi paši kā SingleBranchScheduler.
P.S. Nr. 3. Varbūt noderēs
Periodic – tas ir grafiks, kas reaģē ar noteiktu fiksētu laika periodiskumu. Izsaukums izskatās aptuveni šādi
from buildbot.plugins import schedulers
nightly = schedulers.Periodic(name="daily",
builderNames=["full-solaris"],
periodicBuildTimer=24*60*60)
c['schedulers'] = [nightly]
5.5 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 norāda šo periodiskumu sekundēs.
BuildFactory izveido konkrētu build, kas vēlāk builder nosūtīs uz Darbinieks. Iz BuildFactory norāda soļus, kas jāpaveic Darbinieks-u. Soļi tiek pievienoti, izmantojot metodes addStep
Pirmais pievienotais solis šajā piemērā ir git clean -d -f -f –x, tad jebkurai apņemšanai.. Šīs darbības ir ieviestas parametrā metode, kas acīmredzot nav tieši norādīts, bet pieņem noklusējuma vērtību fresh. Parametrs mode='incremental' norāda, ka faili no direktorijas, uz kuru tiek veikta chechout, vienlaikus trūkstošie repozitorijā, paliek neskarti.
Otrais pievienotais solis – tas ir izsaukums uz skriptu trial ar parametru hello sānos Darbinieks-a no direktorijas /home/habr/worker/yourProject/build c vides mainīgajā PATHONPATH=… Tādēļ jūs varat rakstīt savus skriptus un izpildīt tos sānos Darbinieks-a caur soli util.ShellCommand. Šos skriptus var novietot tieši repozitorijā. Tad pie chechout-e tie tiks iekļauti /home/habr/worker/yourProject/build. Tomēr tad ir divi „bet”:
- Darbinieks ir jāizveido ar atslēgu lai tas neierobežotu tiesības uz izpildi pēc checkout-a.
- Veicot git push-e šiem skriptiem ir jānorāda īpašība exacutable, lai vēlāk pie chechout-e tiesības uz skriptu Git nezaudētu.
5.6 būvētāji
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Par to, kas ir Builder tika stāstīts . Tagad es sīkāk pastāstīšu, kā to izveidot. BuilderConfig ir konstruktors builder. Tādus konstruktori ir iespējams definēt c[‘builders’] var būt vairāki, jo tas ir objektu saraksts builder . Tagad mazliet pārrakstīsim piemēru BuildBot, tuvojot to mūsu uzdevumam.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Tagad pastāstīšu par parametriem BuilderConfig.
name nosaka vārdu builder-a. Šeit mēs to nosaucām yourProject. Tas nozīmē, ka uz Darbinieks-e tiks izveidots tieši šis ceļš /home/habr/worker/yourProject/build. Scheduler meklē builder tieši pēc šā nosaukuma.
workernames satur sarakstu Darbinieks-u. Katrs no tiem ir jāpievieno c[‘workers’].
factory — konkrēts build, ar kuru tas ir saistīts builder. Tas nosūtīs objektu build uz Darbinieks izpildei visiem soļiem, kas ietver build-a.
6. Savas konfigurācijas piemērs
Šeit ir projekta arhitektūra, kuru es piedāvāju realizēt caur BuildBot
.
Kā versiju kontroles sistēmu izmantosim svn. Pašreizējā repozitorija atradīsies kaut kur mākonī. Šī ir šī mākoņa adrese . Mākonī zem svn ir konts username: user, passwd: password. Skripti, kas ietver soļus build-a būs arī atrodami šajā zarā svn, atsevišķā mapē buildbot/worker_linux. Šie skripti ir repozitorijā ar saglabātu īpašību executable.
BuildMaster. un Darbinieks darbojas uz viena hosta project.host .BuildMaster. uzglabā savus failus mapē /home/habr/master. Darbinieks tā arī uzglabā pēc sekojoša ceļa /home/habr/worker. Procesu saikne BuildMaster.-am un Darbinieks-am tiek nodrošināta caur 4000 portu pēc protokola BuildBot-a, proti, ‘pb’ protokols.
Mērķa projekts ir pilnībā uzrakstīts python valodā. Uzdevums ir izsekot izmaiņām, izveidot executable failu, ģenerēt dokumentāciju, veikt testēšanas procesu. Gadījumā, ja notiek failure, ir jānosūta ziņojums visiem izstrādātājiem pa e-pastu par to, ka ir notikusi neizdevusies darbība.
Web attēlojums BuildBot mēs pieslēgsim 80. portā project.host. Apatch instalēt nav obligāti. Bibliotēkas sastāvā twisted jau ir iekļauts web serveris, BuildBot ko tā izmanto.
Lai uzglabātu iekšējai informācijai BuildBot mēs izmantosim sqlite.
Lai nodrošinātu e-pasta izsūtīšanu, nepieciešams host smtp.your.domain — uz tā ir atļauta e-pastu nosūtīšana no adreses projectHost@your.domain bez autentifikācijas. Arī hostā ‘smtp ‘ protokols klausās uz porta 1025.
Procesā piedalās divi cilvēki: admin un user. admin administrē BuildBot. user ir persona, kas veic commit-us.
Exacutable fails tiek ģenerēts caur pyinstaller. Dokumentācija tiek ģenerēta caur doxygen.
Šai arhitektūrai es uzrakstīju šādu 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>Būvētā izlaiduma statuss: {{ summary }}</h4>
<p>Izmantojamais pakalpojums būvēšanai: {{ workername }}</p>
<p>Projekts: {{ projects }}</p>
<p>Lai apskatītu vadības saskarni, lūdzu, apmeklējiet saiti: {{ buildbot_url }}</p>
<p>Lai apskatītu būvēšanas rezultātu, lūdzu, apmeklējiet saiti: {{ build_url }}</p>
<p>Izmantojot WinSCP, varat pieslēgties serverim ar ip:xxx.xx.xxx.xx. Piesakoties ar habr/password, varat lejupielādēt izstrādāto izpildāmo failu no direktorijas ~/worker/yourProject/build/dist.</p>
<p><b>Būvēšana tika veikta caur Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="projectHost@your.domain",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['user@your.domain'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
c['title'] = "Būvēšanas process"
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"
}
Vispirms jātiek BuildMaster.-am un Darbinieks-a. Pēc tam jāievieto šis fails master.cfg. par /home/habr/master.
Nākamais solis ir palaišana pakalpojumā BuildMaster.-s
sudo buildbot start /home/habr/master
Pēc tam jāpalaiž pakalpojums Darbinieks-a
buildbot-worker start /home/habr/worker
Gatavs! Tagad Buildbot tiks uzraudzītas izmaiņas un darbosies pēc commit-u svn, veicot projekta būves un testēšanas soļus ar iepriekš minēto arhitektūru.
Zemāk es aprakstīšu dažas iezīmes augstāk minētā master.cfg.
6.1 Ceļā uz savu master.cfg
Rakstot savu master.cfg. tiks izdarītas daudz kļūdu, tāpēc būs nepieciešama log faila lasīšana. Tas tiek glabāts gan uz BuildMaster.-e c ar absolūtu ceļu /home/habr/master/twistd.log, gan pusē Darbinieks-a ar absolūtu ceļu /home/habr/worker/twistd.log. Lasot kļūdas un tās labojot, būs nepieciešams restartēt pakalpojumu BuildMaster.-a. Šādi to izdarīt:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Darbs ar 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)
Vispirms aplūkosim svn_poller. Tas ir tas pats interfeiss, kas regulāri aptaujā glabātuvi reizi minūtē. Šajā gadījumā svn_poller tiek vērtēts tikai uz filiāli trunk. Noslēpumainais parametrs split_file=util.svn.split_file_alwaystrunk nosaka noteikumus: kā sadalīt mapju struktūru svn uz filiālēm. Tas piedāvā tām relatīvos ceļus. Savukārt split_file_alwaystrunk vienkāršo procesu, norādot, ka glabātuvē ir tikai trunk.
No Schedulers norādīts ChangeFilter, kurš redz None un asociē ar to filiāli trunk pēc noteiktās asociācijas caur split_file_alwaystrunk. Reaģējot uz izmaiņām trunk, uzsāk builder c ar nosaukumu yourProject.
properties ir nepieciešams, lai administrators saņemtu ziņojumus par būves un testēšanas rezultātiem kā procesa īpašnieks.
Solis build-a checkout spēj veikt pilnīgu visu failu dzēšanu, kas atrodas lokālajā glabātuvē Darbinieks-a. A tad veikt pilnu svn update. Režīms tiek iestatīts ar parametru mode=full, method=fresh. Parametrs haltOnTailure norāda, ka, ja svn update ja kļūdas dēļ tiek pārtraukts viss montāžas un testēšanas process, jo turpmākās darbības nav jēgpilnas.
6.3 Jums nosūtīts: reporters pilnvarots paziņot
ziņotāji — ir brīdinājumu sūtīšanas pakalpojums e-pastā.
template_html=u'''
<h4>Būvētā izlaiduma statuss: {{ summary }}</h4>
<p>Izmantojamais pakalpojums būvēšanai: {{ workername }}</p>
<p>Projekts: {{ projects }}</p>
<p>Lai apskatītu vadības saskarni, lūdzu, apmeklējiet saiti: {{ buildbot_url }}</p>
<p>Lai apskatītu būvēšanas rezultātu, lūdzu, apmeklējiet saiti: {{ build_url }}</p>
<p>Izmantojot WinSCP, varat pieslēgties serverim ar ip:xxx.xx.xxx.xx. Piesakoties ar habr/password, varat lejupielādēt izstrādāto izpildāmo failu no direktorijas ~/worker/yourProject/build/dist.</p>
<p><b>Būvēšana tika veikta caur Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="projectHost@your.domain",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['user@your.domain'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
Tas var sūtīt ziņojumus .
MailNotifier izmanto e-pastu brīdinājumu sūtīšanai.
template_html nosaka teksta veidni sūtīšanai. Marķējuma izveidei tiek izmantots html. Tas ir modificēts ar motoru (to var salīdzināt ar django). BuildBot satur mainīgos, kuru vērtības tiek ielikti veidnē ziņojuma satura ģenerēšanas procesā. Šie mainīgie ir ierakstīti {{ divās apaļās šķērssavienojumos }}. Piemēram, kopsavilkums izvadīs izpildīto operāciju statusu, proti, success vai failure. Savukārt projekti izvadīs yourProject. Tādējādi, izmantojot vadības komandas, jinja2, mainīgos BuildBot-a un Python teksta formatēšanas rīkus, var izveidot diezgan informatīvu ziņojumu.
MailNotifier satur šādus argumentus.
fromaddr – adrese, no kuras visiem tiks sūtīti ziņojumi.
sendToInterestedUsers=True sūta ziņojumu īpašniekam un lietotājam, kurš veicis commit.
lookup — sufikss, ko jāpievieno lietotāju vārdiem, kuri saņem sūtījumu. Tādējādi admin lietotājs saņems sūtījumu uz adresi admin@your.domain.
relayhost nosaka viesdatora nosaukumu, kurā ir atvērts servers smtp, a smptPort nosaka portu, kuram ir pieslēgts smtp servera.
mode=«warning» norāda, ka sūtījumu vajadzētu veikt tikai tad, ja vismaz viens solis build-a beidzas ar statusu failure vai warning. Ja status ir success, sūtījumus veikt nav nepieciešams.
extraRecipients satur sarakstu ar personām, kam jāsūta ziņojumi, papildus īpašniekam un personai, kas veic commit.
messageFormatter ir objekts, kas nosaka ziņojuma formātu, tā veidni un pieejamo mainīgo kopu no jinja2. Šādi parametri kā wantProperties=True un wantSteps=True nosaka šo pieejamo mainīgo kopu.
s[‘services’]=[sendMessageToAll] sniedz mūsu vidū esošo pakalpojumu sarakstu, no kuriem būs arī mūsu ziņotājs.
Mēs to izdarījām! Mani apsveikumi
Mēs izveidojām savu konfigurāciju un redzējām funkcionalitāti, uz kuru tas spēj. BuildBotPietiek, lai saprastu, vai šis rīks ir nepieciešams jūsu projektam. Vai tas jūs interesē? Vai tas būs noderīgs? Vai ar to ir ērti strādāt? Tad rakstīt šo rakstu man nebija velti.
Un vēl. Es vēlētos, lai profesionālā kopiena, kas izmanto BuildBot, kļūtu plašāka, rokasgrāmatas tiktu tulkotas un piemēru būtu vēl vairāk.
Visiem paldies par uzmanību. Veiksmi.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
Finnish
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish