(Imazhi nga from
🥇Si të arrish në qiell dhe të bëhesh pilot | ProHoster
Emri im është Evgeny Cherkin, un programer i ekipës së zhvilluesve në një kompani minerare Polymetal.
Kur fillon një projekt të madh, fillon të mendosh: «Cili është softueri më i mirë për ta mbështetur atë?». Një projekt IT kalon nëpër një seri hapash para lëshimit të versionit të tij të radhës. Është mirë kur zinxhiri i këtyre hapave automatizohet. Procesi i automatizuar i lëshimit të një versioni të ri të një projekti IT quhet Continuous Integration. BuildBot na doli të jetë një ndihmës i mirë, duke realizuar këtë proces.
Në këtë artikull vendosa të paraqes një përmbledhje të mundësive BuildBot. Çfarë është e aftë ky soft? Si t'i afrohemi dhe si të ndërtojmë një marrëdhënie EFEKTIVE DHE TË MIRË ME TË? Përvojën tonë mund ta aplikoni dhe ju, duke krijuar në makinën tuaj një shërbim ndihmës për ndërtimin dhe testimin e projektit tuaj.
Përmbajtja
Përmbajtja
1. Pse BuildBot?
Më parë në habr-e kam parë artikuj për realizimin e Continuous Integration duke përdorur BuildBot. Për shembull, më dukej më informues. Ka një shembull tjetër— . Këta artikuj mund të përforcohen , ndërsa për aktivizim, në anglisht. Në përgjithësi, krijohet një pikë e mirë përcjellëse. Pasi të keni lexuar këto artikuj, sigurisht që do të dëshironi menjëherë të bëni diçka në BuildBot të bëni.
Stop! A e ka përdorur ndokush atë në projektet e tij? Të duket se po, e kanë aplikuar atë në detyrat e tyre. Mund të gjejnë përdorimit BuildBot edhe në arkivat e kodëve të Google.
Cila është logjika e njerëzve që përdorin Buildbot? Ведь есть другие инструменты: CruiseControl dhe Jenkins. Do të përgjigjem kështu. Për shumicën e detyrave Jenkins vërtet do të mjaftojë. Në anën tjetër, BuildBot është më adaptues, dhe detyrat zgjidhen po aq lehtë, si në Jenkins. Zgjedhja është tuajat. Por nëse jemi duke kërkuar një mjet për një projekt që po zhvillohet, pse të mos zgjidhni atë që do të lejojë, nga hapat e thjeshta, të krijoni një sistem ndërtimi që ka interaktivitet dhe një ndërfaqe unike.
Për ata që projekti i tyre qëllimor është shkruar në python, lind pyetja: "Pse të mos zgjidhni një sistem integrimi, i cili ka një ndërfaqe të kuptueshme nga pikëpamja e gjuhës që përdoret në projekt?". Dhe tani është koha për të paraqitur avantazhet. BuildBot.
Pra, "katërshja e mjetit" tonë. Për vete, e kam përcaktuar katër veçori. BuildBot:
- Ky është një framework me kod të hapur nën licencën GPL.
- Kjo është përdorimi i python si një mjet konfigurimi dhe përshkrimi të veprimeve të kërkuara.
- Kjo është mundësia për të marrë përgjigje nga makina, në të cilën ndodh ndërtimi.
- Kjo, përfundimisht, kërkon kërkesa minimale për Host. Për implementimin kërkohet python dhe twisted, dhe nuk është e nevojshme makina virtuale dhe java-makina.
2. Koncepti nën drejtimin e BuildMaster
Vendi qendror në arkitekturën e shpërndarjes së detyrave zë BuildMaster. Ai përfaqëson një shërbim, i cili:
- ndjek ndryshimet në pemën e burimeve të projektit.
- dërgon komandat që duhen ekzekutuar nga shërbimi Worker për të ndërtuar projektin dhe për ta testuar atë.
- njofton përdoruesit për rezultatet e veprimeve të kryera.
BuildMaster konfigurohet përmes një skedari master.cfg. Ky skedar ndodhet në rrënjën BuildMaster. Më vonë do të tregoj se si krijohet kjo rrenjë. Vetë skedari master.cfg përmban një skript python, i cili përdor thirrje BuildBot.
Objekti tjetër më i rëndësishëm BuildBot quhet Punëtor. Ky shërbim mund të ekzekutohet në një host tjetër me një OS tjetër, ose mund të jetë edhe në atë ku BuildMaster. Ai gjithashtu mund të ekzistojë në një mjedis virtual të përgatitur me paketat dhe variablat e veta. Këto mjedise virtuale mund të përgatiten duke përdorur mjete python si virtualenv, venv..
BuildMaster transmeton urdhra çdo Punëtor-i, dhe ai, nga ana e tij, i ekzekuton. Kështu, procesi i ndërtimit dhe testimit të projektit mund të zhvillohet në Punëtor-in nën menaxhimin e Windows dhe në një Worker tjetër nën menaxhimin e linux.
Checkout e burimeve të kodit të projektit ndodh në çdo Punëtor-in.
3. Instalimi
Pra, le të fillojmë. Si host do të përdor Ubuntu 18.04. Atë do ta vendos një BuildMaster-a dhe një Punëtor-a. Por së pari do të kërkohet të instaloj python3.7:
sudo apt-get update
sudo apt-get install python3.7
Për ata që u nevojitet python3.7.2 në vend të 3.7.1, mund të bëjnë këtë:
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
Hapi tjetër është të instalojmë Twisted dhe BuildBot, si paketet që lejojnë përdorimin e funksionaliteteve shtesë 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. Hapat e parë
Koha për të krijuar BuildMaster. Ai do të jetë në folderin tonë /home/habr/master.
mkdir master
buildbot create-master master # Këtu e krijojmë në të vërtetëHapi tjetër. Do të krijojmë Punëtor. Ai do të jetë në folderin tonë /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 emriJuajPunes i fjalëkalimit
Kur ta filloni Punëtor, atëherë në mënyrë default do të krijojë në /home/habr/worker folderi me emrin e projektit, i cili është specifikuar në master.cfg. Dhe në folderin me emrin e projektit do të krijojë një drejtorinë build, dhe më pas do të bëjë checkout. Katalogu i punës për Punëtor-a do të jetë direktoria /home/habr/yourProject/build.
Çelësi "të arit"
Dhe tani, arsyeja për të cilën shkrova paragrafin e mëparshëm: skenari që Master do të kërkojë nga Punëtor-a të bëjë në mënyrë të largët në këtë drejtor, nuk do të ekzekutohet, sepse skripti nuk ka të drejtat për ta nisur. Për të zgjidhur situatën, do të nevojitet çelësi —umask=0o22, i cili vendos një ndalesë për shkrim në këtë direktori, por lë të drejtat e ekzekutimit. Dhe vetëm kjo na nevojitet.
BuildMaster dhe Punëtor për të krijuar një lidhje. Ndonjëherë, ajo ndërpritet dhe Punëtor disa kohë pret përgjigjen nga BuildMaster-a. Nëse nuk ka përgjigje, lidhja rifillojë. Çelësi —keepalive=60 është pikërisht ai që na nevojitet për të treguar kohën, pas së cilës connect rifillojë.
5. Konfigurimi. Receta hap pas hapi
Konfigurimi BuildMaster Kjo bëhet në anën e makinës, ku ne ekzekutuam komandën create-master. Në rastin tonë — kjo është katalogu /home/habr/master. Skedari konfiguruese master.cfg ende nuk ekziston, megjithatë komanda e vetë ka krijuar skedarin master.cmg.sample. Duhet ta ndryshojmë emrin në master.cfg.sample në master.cfg
mv master.cfg.sample master.cfgDo ta hapim këtë master.cfg. Dhe do të analizojmë nga çfarë përbëhet. Pas kësaj, do të provoni të krijoni skedarin tuaj të konfigurimit.
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 — fjalë kyçe të fjalorit të konfigurations. Ai duhet të përdoret domosdoshmërisht në skedarin e konfigurations. Për lehtësi përdorimi në kodin e konfigurations, futet një pseudonim i tij «c». Emrat në c[«keyFromDist»] janë elemente fikse për ndërveprimin me BuildMaster. Për secilin çelës, si vlerë venosen objekti përkatës.
5.2 punëtorët
c['workers'] = [worker.Worker("example-worker", "pass")]Këtë herë ne spesifikojmë BuildMaster- një listë të Punëtor-eve. Ne vetë Punëtor kemi krijuar , duke specifikuar you-worker-name dhe password. Tani ato duhet të spesifikohen në vend të example-worker dhe pass .
5.3 burimi i ndryshimeve
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Me çelësin change_source të fjalorit c, marrim qasje në listën, ku duhet të vendosim objektin që monitoron depozitat me kodin burimor të projektit. Në shembullin përdoret një depo Git që monitorohet me një interval të caktuar.
Argumenti i parë është rruga në depozitën tuaj.
workdir përfaqëson rrugën drejt dosjes, ku në anën Punëtor-s në lidhje me rrugën /home/habr/worker/yourProject/build git do të ruajë versionin lokal të depozitës.
branch përmban degën specifike në depo, për të cilën duhet të monitorohet.
pollInterval përmban numrin e sekondave, pas të cilave BuildMaster do të monitorojë depozitën për ndryshime.
Ka disa metoda për të ndjekur ndryshimet në depozitën e projektit.
Metoda më e thjeshtë është Monitorimi, që nënkupton se BuildMaster periodikisht e pyet serverin me repositorin. Në rast se commit reflekton ndryshimet në repositor, atëherë BuildMaster me një vonesë, do të krijojë një objekt të brendshëm Change dhe do ta dërgojë atë në trajtuesin e ngjarjeve Planifikuesi, që do të nisë hapat për ndërtimin dhe testimin e projektit në Punëtor-ë. Ndër këto hapa do të përfshihet përditësim repositori. Pikërisht në Punëtor-ë do të krijohet një kopje lokale e repositorit. Detajet e këtij procesi do të shpjegohen më poshtë në dy seksionet e ardhshme ( dhe ).
Një metodë edhe më të sofistikuar të ndjekjes së ndryshimeve në repositor është dërgimi i drejtpërdrejtë i mesazheve nga serveri ku është vendosur ai, te BuildMaster-i për ndryshimin e kodit burimor të projektit. Në këtë rast, sapo zhvilluesi të bëjë commit, serveri me repositorin e projektit do të dërgojë një mesazh BuildMaster-it. Ky i fundit, nga ana e tij, do ta kapë duke krijuar një objekt PBChangeSource. Më pas, ky objekt do të dërgohet në Planifikuesi, i cili do të aktivizojë hapat për ndërtimin e projektit dhe testimin e tij. Një pjesë e rëndësishme e kësaj metode është puna me hook-skritat e serverit në repositor. Në skriptin hook-it, që është përgjegjës për përpunimin e veprimeve gjatë commit-it, është e nevojshme të thirret utilita sendchange dhe të specifikohet adresa e rrjetit BuildMaster-it. Duhet të specifikohet gjithashtu porta e rrjetit, e cila do të dëgjojë PBChangeSource. PBChangeSource, të cilat, për fat të mirë, janë pjesë e BuildMaster-it. Kjo metodë do të kërkojë të drejta admin-a në serverin ku ndodhet repositori i projektit. Përpara duhet bërë një backup i repositorit.
5.4 programuesit
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 – është një element që vepron si një triger, duke nisur të gjithë zinxhirin e ndërtimit dhe testimit të projektit.
Ato ndryshime, të cilat janë regjistruar change_source, u transformuan gjatë punës BuildBot-a në një objekt Change dhe tani çdo Sheduler ndërtoi kërkesa për të nisur procesin e ndërtimit të projektit. Megjithatë, ai përcakton gjithashtu se kur këto kërkesa të dërgohen në radhë. Objekti Builder mban një radhë kërkesash dhe ndjek gjendjen e ndërtimit aktual në një të veçantë Punëtor-e. Builder ekziston edhe në BuildMaster-e dhe në Punëtor-e. Ai gjithashtu dërgon nga BuildMaster-a te Punëtor-a një seri hapat që duhet të kryhen. build Ne shohim se në shembullin aktual, ka pasur
krijohen 2 të tilla. Për më tepër, çdo njëri ka një lloj të vet. schedulers SingleBranchScheduler
Planifikuesi i Degëve të Vetme – një nga klasat më të njohura të orarit. Ai monitoron një degë dhe aktivizohet me një ndryshim të regjistruar në të. Kur sheh ndryshime, ai mund të vonojë dërgimin e kërkesës për ndërtim (të vonojë për një periudhë të caktuar, e cila është e specifikuar në parametrin e veçantë treeStableTimer). Në emri caktohet emri i orarit, i cili do të shfaqet në BuildBot-ndërfaqen web. Në ChangeFilter caktohet filtri, përmes të cilit ndryshimet në degë nxisin orarin të dërgojë kërkesën për ndërtim. Në builderNames specifikoni emrin ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit:yourProject ForceScheduler.
është një gjë mjaft e thjeshtë. Ky lloj orari aktivizohet me një klik miu nëpërmjet -ndërfaqes web. Parametrat kanë të njëjtin qëllim si në BuildBotP.S. №3. Mund të jetë e dobishme Planifikuesi i Degëve të Vetme.
Periodic
— ky është një orar, i cili aktivizohet me një frekuencë të caktuar. Duket thirrja e tij pak si from buildbot.plugins import schedulers nightly = schedulers.Periodic(name="daily", builderNames=["full-solaris"], periodicBuildTimer=24*60*60) c['schedulers'] = [nightly]
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": "."}))
5.5 BuildFactory
periodicBuildTimer
cakton kohën e kësaj periudhe në sekonda. BuildFactory
krijon një të veçantë , e cila më pas builddërgohet në ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit: specifikohen hapat, që duhet të kryhen Punëtor. Në krijon një të veçantë -it. Hapat shtohen përmes thirrjes së metodës PunëtoraddStep Hapi i parë i shtuar në këtë shembull është
git clean -d -f -f –x . Këto veprime janë të shtuara në parametrin, pastaj git checkout, i cili nuk është shfaqur qartë, por nënkupton një vlerë default methodfresh mode='incremental'. Parametri tregon se skedarët nga direktoria, ku bëhet chechout , ndërkaq skedarët që nuk janë në depot, mbeten të paprekur.Hapi i dytë i shtuar është thirrja e skriptit
me parametrin trial në anën hello -it nga direktoria Punëtorc variabla e ambientit PATHONPATH=… Kështu, ju mund të shkruani skriptet tuaja dhe t'i ekzekutoni në anën /home/habr/worker/yourProject/build -it përmes hapit Punëtorutil.ShellCommand . Këto skripte mund të vendosen drejtpërdrejt në depot. Atëherë, kur-i ato do të bien në , ndërkaq skedarët që nuk janë në depot, mbeten të paprekur.. Megjithatë, atëherë ka dy 'por': /home/habr/worker/yourProject/buildduhet të krijohet me çelësin
- Punëtor —umask -ve këtyre skripteve është e nevojshme të specifikohet pronësia checkout-a.
- Kur git pushexacutable , që më pas në-e të drejtat për ekzekutimin e skriptit Git të mos humbasin. , ndërkaq skedarët që nuk janë në depot, mbeten të paprekur.-it të drejtat për ekzekutimin e skriptit Git.
5.6 ndërtuesit
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Këtu është se çfarë është Builder u tregua . Tani do të flas pak më në detaje për atë se si ta krijoj. BuilderConfig është një ndërtues ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit:. Ka disa nga këta ndërtues në c[‘builders’] mund të vendosen disa, pasi që është një listë objektesh ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit: tipo. Tani do ta rishkruajmë pak shembullin nga BuildBot, duke e afruar atë me detyrën tonë.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Tani do të flas për parametrat BuilderConfig.
emri vendos emrin ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit:-a. Këtu e quajtëm ForceScheduler. Kjo do të thotë se në Punëtor-e do të krijohet ky rrugë /home/habr/worker/yourProject/build. Sheduler gjen ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit: pikërisht me këtë emër.
workernames përmban një listë Punëtor-ash. Secili prej të cilëve duhet të shtohet në c[‘workers’].
factory — një konkret build, me të cilin është i asocuar ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit:. Ai do të dërgojë një objekt build në Punëtor për të përfunduar të gjitha hapat që përfshihen në këtë build-a.
6. Një shembull i konfigurimit tonë
Ja arkitektura e shembujve të projektit që po sugjeroj ta realizojmë përmes BuildBot
.
Si sistem për kontrollin e versioneve do të përdorim svn. Repoja do të gjendet në një cloud të caktuar. Ja adresa e këtij cloud-i . Në cloud ka një llogari username: svn , passwd: user. Skriptet që përbëjnë hapat password-a do të jenë gjithashtu në degën build, në një dosje të veçantë svnbuildbot/worker_linux . Këto skripte janë në repo me pronësinë e ruajturexecutable punojnë në një host.
BuildMaster dhe Punëtor project.host ruan skedaret e saj në dosjen .BuildMaster aji ruan gjithashtu në rrugën e mëposhtme /home/habr/master. Punëtor . Komunikimi i proceseve /home/habr/worker-a dhe BuildMaster-a bëhet përmes portit 4000 me protokollin Punëtor-a, dmth BuildBot‘pb’ protokoll. Projekti i synuar është shkruar krejtësisht në python. Detyra është të monitorojmë ndryshimet e tij, të krijojmë një skedë ekzekutivi, të gjenerojmë dokumentacion, të kryejmë testime. Në rast dështimi, duhet t'u dërgojmë një mesazh të gjithë zhvilluesve në email se ka një veprim të dështuar.
Shfaqja Web
do ta lidhim në portin 80 për BuildBot . Apache nuk është e detyrueshme të instalohet. Në përbërje të bibliotekës ruan skedaret e saj në dosjentwisted ka një server web të pranishëm, ai e përdor. BuildBot Për ruajtjen e informacionit për përdorim të brendshëm do të përdorim
Për dërgimin e emaileve na nevojitet një host BuildBot smtp.your.domain sqlite.
— në të lejohet dërgimi i emaileve nga adresa projectHost@your.domain pa autentikim. Po ashtu në hostin ‘ smtp ‘ protokolli dëgjon në portin 1025.Personat e përfshirë në proces janë dy: . admin administron
. user është personi që bën admin dhe user-at. BuildBot. përdoruesi është një person që kryen commit-ët.
Fajlli ekzekutues gjenerohet përmes pyinstaller. Dokumentacioni gjenerohet përmes doxygen.
Për këtë arkitekturë kam shkruar të tillë 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>Statusi i ndërtimit të lëshimit: {{ summary }}</h4>
<p>Shërbimi i përdorur për ndërtimin: {{ workername }}</p>
<p>Projekti: {{ projects }}</p>
<p>Për të parë ndërfaqen e menaxhimit, vizitoni lidhjen: {{ buildbot_url }}</p>
<p>Për të parë rezultatin e ndërtimit, vizitoni lidhjen: {{ build_url }}</p>
<p>Duke përdorur WinSCP mund të lidheni me serverin me ip:xxx.xx.xxx.xx. Duke u regjistruar me habr/password, merrni skedarin executable të ndërtuar nga direktoria ~/worker/yourProject/build/dist.</p>
<p><b>Ndërtimi u realizua përmes 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'] = "Procesi i ndërtimit"
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"
}
Për të filluar, është e nevojshme BuildMaster-a bëhet përmes portit 4000 me protokollin Punëtor-a. Pastaj vendosni këtë skedar master.cfg në /home/habr/master.
Hapi i ardhshëm është të nisni shërbimin BuildMaster-a
sudo buildbot start /home/habr/master
Pastaj filloni shërbimin Punëtor-a
buildbot-worker start /home/habr/worker
Kryer! Tani Buildbot do të ndjekë ndryshimet dhe bëjë veprime sipas commit-u në svn, duke realizuar hapat e ndërtimit dhe testimit të projektit me arkitekturën e lartpërmendur.
Më poshtë do të përmend disa veçori të master.cfg.
6.1 Në rrugën drejt master.cfg tonë
Gjatë shkruarjes së tij master.cfg do të ndodhin shumë gabime, prandaj do të nevojitet të lexoni skedarin e log-ut. Ai ruhet si në BuildMaster-e c me rrugë absolute /home/habr/master/twistd.log, ashtu edhe në anën Punëtor-a me rrugë absolute /home/habr/worker/twistd.log. Ndërsa lexoni gabimet dhe i korrigjoni, do të jetë e nevojshme të ri-nisni shërbimin BuildMaster-a. Ja si bëhet:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Puna me 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)
Për të filluar, le t'i hedhim një sy svn_poller. Ky është i njëjti ndërfaqe, i cili pyet rregullisht depozitat çdo minutë. Në këtë rast svn_poller ai i referohet vetëm degës trunk. Parametri misterioz split_file=util.svn.split_file_alwaystrunk vendos rregullat: si të ndahen struktura e dosjeve svn në degë. Po ashtu, ai ofron rrugë relative për to. Nga ana e tij split_file_alwaystrunk lehtëson procesin, duke njoftuar se brenda depozitës ka vetëm trunk.
Në Schedulers shkruhet ChangeFilter, e cila shihni Asnjë dhe e asocioja atë me degën trunk në lidhje me asociacionin e dhënë përmes split_file_alwaystrunk. Duke reaguar ndaj ndryshimeve në trunk, nis ndërtuesit, që ne do të caktojmë pak më vonë. Emri në rastin tonë do të jetë e njëjtë me emrin e projektit: c me emrin ForceScheduler.
properties këtu është e nevojshme për që admini të marrë njoftime për rezultatet e ndërtimit dhe testimit si pronar i procesit.
Hapi build-a checkout është i aftë të bëjë një fshirje të plotë të çdo skedari që ndodhet në versionin lokal të depozitës Punëtor-a. Pastaj bën një azhurnim të plotë svn update.Mënyra është e vendosur përmes parametrave mode=full, method=fresh. Parametri haltOnTailure tregon se nëse svn update. nëse do të kryhet me gabim, atëherë e gjithë procesi i ndërtimit dhe testimit duhet të pezullohet, pasi veprimet e mëtejshme nuk kanë kuptim.
6.3 Ju keni një letër: reporterët janë të autorizuar të deklarojnë
raportuesit është një shërbim që dërgon njoftime përmes postës.
template_html=u'''
<h4>Statusi i ndërtimit të lëshimit: {{ summary }}</h4>
<p>Shërbimi i përdorur për ndërtimin: {{ workername }}</p>
<p>Projekti: {{ projects }}</p>
<p>Për të parë ndërfaqen e menaxhimit, vizitoni lidhjen: {{ buildbot_url }}</p>
<p>Për të parë rezultatin e ndërtimit, vizitoni lidhjen: {{ build_url }}</p>
<p>Duke përdorur WinSCP mund të lidheni me serverin me ip:xxx.xx.xxx.xx. Duke u regjistruar me habr/password, merrni skedarin executable të ndërtuar nga direktoria ~/worker/yourProject/build/dist.</p>
<p><b>Ndërtimi u realizua përmes 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]
Ai mund të dërgojë mesazhe .
MailNotifier përdor postën për të dërguar njoftime.
template_html përcakton template-n e tekstit për dërgesat. Për të krijuar markup përdoret html. Ai është modifikuar nga motori (mund të krahasohet me django). BuildBot ka një set variablash, vlerat e të cilëve plotësohen në template gjatë formimit të tekstin të mesazhit. Këto variabla janë të vendosura në {{ kllapat e dyfishta }}. Kështu, për shembull, përmbledhje tregon statusin e operacioneve të kryera, domethënë success ose failure. Ndërsa projeket do të shfaqë ForceScheduler. Kështu, me ndihmën e komandave që administrojnë jinja2, variablave BuildBot-it dhe mjeteve për formatimin e stringjeve të python, mund të krijoni një mesazh mjaft informativ.
MailNotifier ka argumentet e mëposhtme.
fromaddr – adresa nga e cila do të dërgohet gjithçka përmes postës.
sendToInterestedUsers=True dërgon mesazhin te pronari dhe përdoruesi që e bëri commit.
lookup – sufiksi që duhet të shtohet në emrat e përdoruesve që marrin dërgesat. Kështu admin si përdoruesi do të marrë dërgesat në adresën admin@your.domain.
relayhost përcakton emrin e hostit, në të cilin është hapur serveri Personat e përfshirë në proces janë dy:, a smptPort përcakton numrin e portit që po dëgjon Personat e përfshirë në proces janë dy: server.
mode=«warning» thotë se dërgimi duhet bërë vetëm në rastin që të paktën një hap build-i përfundoi me statusin failure ose warning. Në rastin e success, dërgimi nuk është i nevojshëm.
extraRecipients përmban një listë të personave te cilëve do t'u dërgohet dërgesa përveç pronarit dhe personit që e realizoi commit.
messageFormatter është një objekt që përcakton formatin e mesazhit, template-n tij, dhe setin e variablave të disponueshëm nga jinja2. Parametra të tillë si wantProperties=True dhe wantSteps=True përcaktojnë këtë set variablash të disponueshëm.
s[‘services’]=[sendMessageToAll] siguron një listë shërbimesh, përfshi edhe tonin tonë raportues.
E bëmë këtë! Urime
Ne krijuam konfigurimin tonë dhe pamë funksionalitetin që është në gjendje BuildBot. Mendoj se kjo është e mjaftueshme për të kuptuar nëse ky mjet është i nevojshëm për krijimin e projektit tuaj. A ju intereson? A do t'ju ndihmojë? A është e lehtë për t'u punuar? Atëherë, nuk jam më kot duke shkruar këtë artikull.
Dhe një gjë tjetër. Do doja që komuniteti profesionist, që përdor BuildBot, të zgjerohet, manualet të përkthehen dhe shembujt të rriten akoma më shumë.
Të gjithë faleminderit për vëmendjen. Fat të mbarë.
Burimi: habr.com
