(Imazhi nga nga
Привет!
Emri im Evgeniy Cherkin, Unë jam një programues në një ekip zhvillimi në një kompani minerare Polimetal.
Kur filloni ndonjë projekt të madh, filloni të mendoni: "Cili softuer është më i mirë për t'u përdorur për ta shërbyer atë?" Një projekt IT kalon nëpër një sërë fazash përpara se të lëshojë versionin tjetër. Është mirë kur zinxhiri i këtyre fazave është i automatizuar. Quhet procesi i automatizuar i lëshimit të një versioni të ri të një projekti IT vetë Integrimi i vazhdueshëm. BuildBot doli të jetë një asistent i mirë për ne në zbatimin e këtij procesi.
Në këtë artikull vendosa të jap një përmbledhje të mundësive BuildBot. Për çfarë është i aftë ky softuer? Si t'i afrohemi atij dhe si të ndërtojmë një MARRËDHËNIE normale EFEKTIVE PUNËS me të? Ju mund ta aplikoni vetë përvojën tonë duke krijuar një shërbim pune për ndërtimin dhe testimin e projektit tuaj në makinën tuaj.
Përmbajtje
Përmbajtje
1. Pse BuildBot?
Më parë në habr-e kam hasur në artikuj rreth zbatimit Integrimi i vazhdueshëm me BuildBot. P.sh. Më dukej më informuese. Ka një shembull tjetër - . Këta artikuj mund të jenë të kalitur Dhe pas kësaj, në anglisht. Coupe bën një pikënisje të mirë. Pas leximit të këtyre artikujve, me siguri do të dëshironi menjëherë diçka BuildBot bëj.
Ndalo! A e ka përdorur dikush me të vërtetë në projektet e tyre? Rezulton se po e zbatuan atë në detyrat e tyre. Mund te gjendet e përdorimit BuildBot dhe në arkivat e kodeve të Google.
Pra, cila është logjika e përdorimit të njerëzve Buildbot? Në fund të fundit, ka mjete të tjera: CruiseControl и Jenkins. Unë do të përgjigjem në këtë mënyrë. Për shumicën e detyrave Jenkins dhe e vërteta do të mjaftojë. Nga ana e tij, BuildBot - më adaptive, ndërsa problemet zgjidhen atje po aq thjesht sa në Jenkins. Zgjedhja është e juaja. Por duke qenë se ne po kërkojmë një mjet për një projekt objektiv në zhvillim, pse të mos zgjidhni atë që do të lejojë, duke filluar nga hapa të thjeshtë, të përftojmë një sistem ndërtimi që ka ndërveprim dhe një ndërfaqe unike.
Për ata, projekti i synuar i të cilëve është shkruar në python, lind pyetja: "Pse të mos zgjidhni një sistem integrimi që ka një ndërfaqe të qartë për sa i përket gjuhës së përdorur në projekt?" Dhe tani është koha për të paraqitur përfitimet BuildBot.
Pra, "kuarteti ynë instrumental". Për veten time, kam identifikuar katër tipare BuildBot:
- Është një kornizë me burim të hapur nën licencën GPL
- Ky është përdorimi i python si një mjet konfigurimi dhe përshkrimi i veprimeve të kërkuara
- Kjo është një mundësi për të marrë një përgjigje nga makina në të cilën bëhet montimi
- Këto janë, më në fund, kërkesat minimale për një Host. Vendosja kërkon python dhe të përdredhur, dhe nuk kërkon një makinë virtuale dhe makinë java.
2. Koncepti i udhëhequr nga BuildMaster
Në qendër të arkitekturës së shpërndarjes së detyrave është BuildMaster. Është një shërbim që:
- gjurmët ndryshimet në pemën burimore të projektit
- dërgon komandat që duhet të ekzekutohen nga shërbimi Worker për të ndërtuar projektin dhe testuar atë
- njofton përdoruesit për rezultatet e veprimeve të ndërmarra
BuildMaster konfiguruar përmes skedarit master.cfg. Ky skedar është në rrënjë BuildMaster. Më vonë do të tregoj se si krijohet kjo rrënjë. Vetë skedari master.cfg përmban një skrip python që përdor thirrjet BuildBot.
Objekti tjetër më i rëndësishëm BuildBot Ajo ka emrin Punëtor. Ky shërbim mund të lansohet në një host tjetër me një OS të ndryshëm, ose ndoshta në atë ku BuildMaster. Mund të ekzistojë gjithashtu në një mjedis virtual të përgatitur posaçërisht me paketat dhe variablat e veta. Këto mjedise virtuale mund të përgatiten duke përdorur shërbime të python si virtualenv, venv.
BuildMaster transmeton komanda për të gjithë Punëtor-y, dhe ai, nga ana tjetër, i përmbush ato. Kjo do të thotë, rezulton se procesi i ndërtimit dhe testimit të një projekti mund të vazhdojë Punëtor-e duke ekzekutuar Windows dhe në një tjetër Worker me Linux.
Përfundimi kodet burimore të projektit ndodhin në secilin Punëtor-e.
3. Instalimi
Pra, le të shkojmë. Unë do të përdor Ubuntu 18.04 si host. Unë do të vendos një mbi të BuildMaster-a dhe një Punëtor-a. Por së pari ju duhet të instaloni python3.7:
sudo apt-get update
sudo apt-get install python3.7
Për ata që kanë nevojë për python3.7.2 në vend të 3.7.1, mund të bëni sa më poshtë:
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
Hapi tjetër është instalimi Tweeted и BuildBot, si dhe paketat që ju lejojnë të përdorni funksione shtesë BuildBot-Të.
/*Все что под 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. Do të jetë në dosjen tonë /shtëpi/habr/mjeshtër.
mkdir master
buildbot create-master master # Собственно сдесь и создаемHapi tjeter. Le të krijojmë Punëtor. Do të jetë në dosjen tonë /shtëpi/habr/punëtor.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Kur vraponi Punëtor, atëherë si parazgjedhje do të krijohet në /shtëpi/habr/punëtor dosje me emrin e projektit, i cili është specifikuar në master.cfg. Dhe në dosjen me emrin e projektit do të krijojë një direktori ndërtuar, dhe do të vazhdojë ta bëjë atë arkë. Drejtoria e punës për Punëtor-dhe do të bëhet një drejtori /home/habr/yourProject/build.
"Çelësi i Artë
Dhe tani për çfarë kam shkruar paragrafin e mëparshëm: një skenar që Mjeshtër do të kërkojë nga Punëtor-dhe bërë nga distanca në këtë direktori nuk do të ekzekutohet sepse skripti nuk ka leje për të ekzekutuar. Për të korrigjuar situatën, do t'ju duhet një çelës --umask=0o22, i cili ndalon shkrimin në këtë drejtori, por do të ruajë të drejtat e nisjes. Dhe kjo është gjithçka që na duhet.
BuildMaster и Punëtor krijojnë një lidhje me njëri-tjetrin. Ndodh që shkëputet dhe Punëtor duke pritur për një kohë për një përgjigje nga BuildMaster-A. Nëse nuk ka përgjigje, lidhja riniset. Celës --keepalive=60 thjesht duhej të tregonte kohën pas së cilës lidh riniset.
5. Konfigurimi. Recetë hap pas hapi
konfiguracion BuildMaster kryhet në anën e makinës ku kemi ekzekutuar komandën krijoj-mjeshtër. Në rastin tonë, kjo është një drejtori /shtëpi/habr/mjeshtër. Skedari i konfigurimit master.cfg nuk ekziston ende, por vetë komanda e ka krijuar tashmë skedarin master.cmg.shembull. Duhet ta riemërtoni në master.cfg.shembull в master.cfg
mv master.cfg.sample master.cfgLe ta hapim këtë master.cfg. Dhe le të shohim se nga çfarë përbëhet. Dhe pas kësaj, le të përpiqemi të krijojmë skedarin tonë 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 — fjalori bazë i skedarit të konfigurimit. Duhet të përfshihet në skedarin e konfigurimit. Për lehtësinë e përdorimit, një pseudonim futet në kodin e konfigurimit "c". Titujt в c["keyFromDist"] janë elemente fikse për ndërveprim me BuildMaster. Për çdo çelës, objekti përkatës zëvendësohet si vlerë.
punëtorët 5.2
c['workers'] = [worker.Worker("example-worker", "pass")]Këtë herë ne tregojmë BuildMaster-y listën e Punëtor-s. Veten time Punëtor ne krijuam , duke treguar ju-punëtor-emër и Fjalëkalimi. Tani ato duhet të specifikohen në vend të tyre shembull-punëtor и kalojë .
5.3 ndryshimi_burimi
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ës ndryshim_burimi fjalor c ne kemi akses në listën ku duam të vendosim një objekt që anketon depon me kodin burimor të projektit. Shembulli përdor një depo Git që anketohet në intervale të caktuara.
Argumenti i parë është rruga për në depon tuaj.
drejtimi i punës përfaqëson rrugën për në dosje ku në anën Punëtor-një i afërm me rrugën /home/habr/worker/yourProject/build git do të ruajë versionin lokal të depove.
degë përmban një degë specifike në depo që duhet ndjekur.
Intervali i sondazhit përmban numrin e sekondave pas të cilave BuildMaster do të anketojë depon për ndryshime.
Ka disa metoda për të gjurmuar ndryshimet në depon e një projekti.
Metoda më e thjeshtë është votim, që nënkupton se BuildMaster anketon periodikisht serverin me depo. Nëse kryej pasqyroi ndryshimet në depo, atëherë BuildMaster do të krijojë një objekt të brendshëm me njëfarë vonese Ndrysho dhe dërgojeni te mbajtësi i ngjarjes Programues, i cili do të nisë hapat për të ndërtuar dhe testuar projektin Punëtor-e. Ndër këto hapa do të tregohet Përditësimi depo. Pikërisht në PunëtorKjo do të krijojë një kopje lokale të depove. Detajet e këtij procesi do të trajtohen më poshtë në dy seksionet e ardhshme. ( и ).
Një metodë edhe më elegante e gjurmimit të ndryshimeve në një depo është dërgimi i mesazheve direkt nga serveri që e pret atë në BuildMaster- në lidhje me ndryshimin e kodeve burimore të projektit. Në këtë rast, sapo zhvilluesi të bëjë kryej, serveri me depon e projektit do të dërgojë një mesazh BuildMaster-y. Dhe ai, nga ana tjetër, do ta përgjojë atë duke krijuar një objekt PBCchangeSource. Më pas, ky objekt do të transferohet në Programues, i cili aktivizon hapat për ndërtimin e projektit dhe testimin e tij. Një pjesë e rëndësishme e kësaj metode është puna me fiksohem-skriptet e serverit në depo. Në skenar fiksohem-a, përgjegjës për veprimet e përpunimit kur kryej-e, duhet të telefononi shërbimin dërgoj ndryshim dhe specifikoni adresën e rrjetit BuildMaster-A. Ju gjithashtu duhet të specifikoni portin e rrjetit që do të dëgjojë PBCchangeSource. PBCchangeSource, meqë ra fjala, është pjesë BuildMaster-A. Kjo metodë do të kërkojë leje admin-a në serverin ku ndodhet depoja e projektit. Së pari do t'ju duhet të bëni një kopje rezervë të depove.
5.4 planifikuesit
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"]))
planifikuesit – ky është një element që vepron si një shkas që nis të gjithë zinxhirin e montimit dhe testimit të projektit.
Ato ndryshime që u regjistruan ndryshim_burimi, i transformuar në proces pune BuildBot-a të kundërshtoj Ndrysho dhe tani çdo Sheduler në bazë të tyre, ai ndërton kërkesa për të filluar procesin e ndërtimit të projektit. Megjithatë, ajo përcakton gjithashtu se kur këto kërkesa transferohen më tej në radhë. Nje objekt Ndërtues ruan një radhë kërkesash dhe gjurmon gjendjen e asamblesë aktuale në një të veçantë Punëtor-e. Ndërtues ekziston më BuildMaster-e dhe me radhë Punëtor-e. Ai dërgon me BuildMaster-a on Punëtor-dhe tashmë specifike ndërtuar - një sërë hapash që duhen ndjekur.
Ne shohim se në shembullin aktual të tillë planifikuesit Janë krijuar 2 copë. Për më tepër, secila ka llojin e vet.
SingleBranchScheduler – një nga klasat më të njohura në orar. Ai shikon një degë dhe nxitet nga një ndryshim i regjistruar në të. Kur sheh ndryshime, ai mund të vonojë dërgimin e kërkesës së ndërtimit (shtyrë për periudhën e specifikuar në parametrin special treeStableTimer) NË emër vendos emrin e orarit që do të shfaqet BuildBot-ndërfaqja e internetit. NË Ndrysho Filterin vendoset një filtër, pas kalimit të të cilit ndryshimet në degë nxisin orarin për të dërguar një kërkesë për ndërtim. NË Emrat e ndërtuesve tregohet emri ndërtues-a, të cilën do ta vendosim pak më vonë. Emri në rastin tonë do të jetë i njëjtë me emrin e projektit: Projekti juaj.
ForceScheduler një gjë shumë e thjeshtë. Ky lloj orari aktivizohet nga një klikim i mausit BuildBot-ndërfaqja e internetit. Parametrat kanë të njëjtin thelb si në SingleBranchScheduler.
P.S. nr 3. Ndoshta do t'ju vijë në ndihmë
Periodike është një orar që funksionon në një frekuencë të caktuar kohore. Thirrja duket diçka si kjo
from buildbot.plugins import schedulers
nightly = schedulers.Periodic(name="daily",
builderNames=["full-solaris"],
periodicBuildTimer=24*60*60)
c['schedulers'] = [nightly]
5.5 Ndërtimi i Fabrikës
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 specifikon kohën e këtij periodiciteti në sekonda.
BuildFactory krijon një specifik ndërtuar, e cila më pas ndërtues dërgon në Punëtor. Në BuildFactory tregon hapat që duhen ndjekur Punëtor-y. Hapat shtohen duke thirrur metodën shtoniStep
Hapi i parë i shtuar në këtë shembull është git pastër -d -f -f –x, atëherë arkë git. Këto veprime përfshihen në parametër metodë, e cila nuk shprehet qartë por nënkupton një vlerë të paracaktuar i freskët... Parametri mode = 'rritje' tregon se skedarët janë nga drejtoria ku chechout, ndërsa mungon nga depoja, mbeten të paprekura.
Hapi i dytë i shtuar është thirrja e skenarit gjyq me parametër përshëndetje në anën Punëtor-a nga drejtoria /home/habr/worker/yourProject/build me variablin e mjedisit PATHONPATH=... Kështu, ju mund të shkruani skriptet tuaja dhe t'i ekzekutoni ato anash Punëtor- çdo hap util.ShellCommand. Këto skripta mund të vendosen direkt në depo. Pastaj në chechout-e ata do të bien në /home/habr/worker/yourProject/build. Sidoqoftë, atëherë ka dy "por":
- Punëtor duhet të krijohet me një çelës në mënyrë që të mos bllokojë të drejtat e ekzekutimit pas arkë-Të.
- në shtytje git-e prej këtyre skripteve ju duhet të specifikoni pronën i ekzekutueshëmnë mënyrë që më vonë chechout-e nuk e humbi të drejtën për të ekzekutuar skriptin Git.
5.6 ndërtues
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Për atë që është Ndërtues ishte thënë . Tani do t'ju tregoj më në detaje se si ta krijoni atë. BuilderConfig është një konstruktor ndërtues. Dizajner të tillë në c['ndërtuesit'] mund të specifikoni disa, pasi kjo është një fletë objektesh ndërtues lloji. Tani le të rishkruajmë shembullin nga BuildBot, duke e afruar me detyrën tonë.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Tani do t'ju tregoj për parametrat BuilderConfig.
emër specifikon emrin ndërtues-a. Këtu e emërtuam Projekti juaj. Kjo do të thotë se në Punëtor- do të krijohet pikërisht kjo rrugë /home/habr/worker/yourProject/build. Sheduler duke kërkuar ndërtues vetëm me këtë emër.
emrat e punëtorëve përmban fletë Punëtor-s. Secila prej të cilave duhet të shtohet c['punëtorët'].
fabrikë - specifike ndërtuar, me të cilin lidhet ndërtues. Ai do të dërgojë objektin ndërtuar mbi Punëtor për të përfunduar të gjitha hapat e përfshirë në këtë ndërtuar-Të.
6. Shembull i konfigurimit tuaj
Këtu është shembulli i arkitekturës së projektit që unë propozoj të zbatohet nëpërmjet BuildBot
.
Ne do të përdorim si një sistem kontrolli të versionit SVN. Vetë depoja do të jetë e vendosur në një lloj reje. Këtu është adresa e kësaj reje . Në renë poshtë SVN ekziston një emër përdoruesi i llogarisë: përdorues, passwd: Fjalëkalimi. Skriptet që përfaqësojnë hapat ndërtuar-a do të jetë edhe në degë SVN, në një dosje të veçantë buildbot/worker_linux. Këto skripta janë të vendosura në depo me pronën e ruajtur e ekzekutueshme.
BuildMaster и Punëtor drejtuar në të njëjtin host projekt.pritës .BuildMaster ruan skedarët e tij në një dosje /shtëpi/habr/mjeshtër. Punëtor ai ruhet në rrugën e mëposhtme /shtëpi/habr/punëtor. Procesi i komunikimit BuildMaster-a dhe Punëtor-a kryhet nëpërmjet portit 4000 sipas protokollit BuildBot-a, pra 'pb' protokoll.
Projekti i synuar është shkruar tërësisht në Python. Detyra është të gjurmoni ndryshimet e tij, të krijoni një skedar të ekzekutueshëm, të gjeneroni dokumentacion dhe të kryeni testime. Në rast dështimi, të gjithë zhvilluesit duhet të dërgojnë një mesazh me email ku thuhet se ka një veprim të pasuksesshëm.
Shfaqja në ueb BuildBot ne do të lidhemi me portin 80 për projekt.pritës. Nuk është e nevojshme të instaloni Apatch. Si pjesë e bibliotekës i shtrembëruar ekziston tashmë një server në internet, BuildBot e përdor atë.
Për të ruajtur informacionin e brendshëm për BuildBot ne do të përdorim sqlite.
Kërkohet një host për dërgimin e postës smtp.your.domain - lejon dërgimin e letrave nga posta projectHost@your.domain pa vërtetim. Gjithashtu në host 'SMTP “Procesverbali po dëgjohet në postën 1025.
Janë dy persona të përfshirë në proces: admin и përdorues. admin administron BuildBot. përdoruesi është personi që kryen kryej-s.
Skedari i ekzekutueshëm gjenerohet nëpërmjet pyinstaller. Dokumentacioni gjenerohet nëpërmjet doksigjeni.
Për këtë arkitekturë kam shkruar këtë: 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="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'] = "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"
}
Së pari ju duhet BuildMaster-a dhe Punëtor-a. Pastaj ngjiteni këtë skedar master.cfg в /shtëpi/habr/mjeshtër.
Hapi tjetër është fillimi i shërbimit BuildMasters
sudo buildbot start /home/habr/master
Pastaj filloni shërbimin Punëtor-a
buildbot-worker start /home/habr/worker
Gati! Tani Buildbot do të gjurmojë ndryshimet dhe do të aktivizojë kryej-y në SVN, duke kryer hapat e ndërtimit dhe testimit të një projekti me arkitekturën e mësipërme.
Më poshtë do të përshkruaj disa veçori të sa më sipër master.cfg.
6.1 Rrugës për te zotëria juaj.cfg
Gjatë shkrimit tim master.cfg Do të bëhen shumë gabime, kështu që do të kërkohet leximi i skedarit të regjistrit. Ajo ruhet si BuildMaster-e me rrugë absolute /home/habr/master/twistd.log, dhe në anën Punëtor-a me rrugë absolute /home/habr/worker/twistd.log. Ndërsa lexoni gabimin dhe rregulloni atë, do t'ju duhet të rinisni 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)
Së pari, le të hedhim një vështrim në svn_poller. Kjo është ende e njëjta ndërfaqe, duke anketuar rregullisht depon një herë në minutë. Në këtë rast svn_poller akseson vetëm në degë trung. Parametër misterioz split_file=util.svn.split_file_alwaystrunk vendos rregullat: si të ndash strukturën e dosjeve SVN në degë. Ai gjithashtu u ofron atyre rrugë relative. Nga ana e saj split_file_alwaystrunk thjeshton procesin duke thënë se depoja përmban vetëm trung.
В Planifikuesit treguar Ndrysho Filterinkush sheh Asnje dhe lidh një degë me të trung sipas një shoqate të caktuar nëpërmjet split_file_alwaystrunk. Duke iu përgjigjur ndryshimeve në trung, Nis ndërtues me emër Projekti juaj.
Pronat këtu është e nevojshme në mënyrë që administratori të marrë listat postare të rezultateve të ndërtimit dhe testimit si pronar i procesit.
hap ndërtuar-a arkë të aftë për të fshirë plotësisht çdo skedar të vendosur në versionin lokal të depove Punëtor-A. Dhe pastaj bëni të plotë përditësimi svn. Modaliteti konfigurohet përmes parametrit mode=plot, metodë=i freskët... Parametri haltOnTailure thotë se nëse përditësimi svn do të ekzekutohet me një gabim, atëherë i gjithë procesi i ndërtimit dhe testimit duhet të pezullohet, pasi veprimet e mëtejshme nuk kanë kuptim.
6.3 Letër për ju: gazetarët janë të autorizuar të deklarojnë
gazetarët është një shërbim për dërgimin e njoftimeve me email.
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="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 .
Njoftuesi i postës përdor email për të dërguar njoftime.
shabllon_html vendos shabllonin e tekstit për buletinin. HTML përdoret për të krijuar markup. Është modifikuar nga motori (mund të krahasohet me xhango). BuildBot ka një grup variablash, vlerat e të cilave zëvendësohen në shabllon gjatë procesit të gjenerimit të tekstit të mesazhit. Këto variabla janë të mbyllura në {{ kllapa me kaçurrela të dyfishta }}. Për shembull, përmbledhje tregon statusin e operacioneve të përfunduara, domethënë suksesin ose dështimin. A Projekte do të dalë Projekti juaj. Pra, duke përdorur komandat e kontrollit në xhinja2, variabla BuildBot-a dhe mjetet e formatimit të vargut python, mund të krijoni një mesazh mjaft informues.
Njoftuesi i postës përmban argumentet e mëposhtme.
ngaaddr – adresa nga e cila të gjithë do të marrin buletinin.
dërgoni Përdoruesit e Interesuar=True i dërgon një mesazh pronarit dhe përdoruesit që ka bërë kryej.
kërkim — një prapashtesë që duhet t'i shtohet emrave të përdoruesve që marrin buletinin. Kështu që admin se si përdoruesi do të marrë buletinin në admin@your.domain.
relayhost specifikon emrin e hostit në të cilin hapet serveri SMTP, Një smptPort specifikon numrin e portit që dëgjon SMTP server.
mode = "paralajmërim" thotë se dërgimi duhet të bëhet vetëm nëse ka të paktën një hap ndërtuar-a, e cila përfundoi me dështimin ose paralajmërimin e statusit. Në rast suksesi, nuk ka nevojë të dërgoni një buletin.
ekstramarrësit përmban një listë të personave të cilëve duhet t'u dërgohet postimi, përveç pronarit dhe personit që ka kryer kryej.
mesazhFormater është një objekt që specifikon formatin e mesazhit, shabllonin e tij dhe një grup variablash të disponueshëm nga xhinja2. Opsione të tilla si wantProperties=E vërtetë и wantSteps=E vërtetë Përcaktoni këtë grup variablash të disponueshëm.
with['service']=[sendMessageTo All] ofron një listë shërbimesh, ndër të cilat do të jetë edhe e jona raportues.
Ne e beme ate! urime
Ne krijuam konfigurimin tonë dhe pamë funksionalitetin që ai mund të bëjë. BuildBot. Kjo, mendoj, është e mjaftueshme për të kuptuar nëse ky mjet është i nevojshëm për të krijuar projektin tuaj. Jeni të interesuar për të? A do të jetë e dobishme për ju? A është ai rehat për të punuar me të? Atëherë nuk po e shkruaj kot këtë artikull.
Dhe më tej. Unë do të doja që komuniteti profesional të përdorte BuildBot, u bë më i gjerë, manualet u përkthyen dhe pati edhe më shumë shembuj.
Faleminderit të gjithëve për vëmendjen tuaj. Paç fat.
Burimi: www.habr.com
