Continuous Integrationi rakenduse näide BuildBoti abil.

Continuous Integrationi rakenduse näide BuildBoti abil.
(Pilt autor Computerizer from Pixabay)

Tere!

Minu nimi on Evgeny Cherkin, ma olen programmeerija kaevandamisettevõtte arendajate meeskonnas Polymetal.

Alustades suurte projektidega hakkad mõtlema: "Millist tarkvara oleks parem kasutada selle hooldamiseks?". IT-projekt läbib enne uue versiooni väljaandmist mitmeid etappe. Hästi, kui nende etappide ahel on automatiseeritud. Automatiseeritud protsessi, mis välja annab uue versiooni IT-projektist, nimetatakse Jätkuv integreerimine. BuildBot , mis on meile osutunud heaks abiks selle protsessi elluviimisel.

Selles artiklis soovin tutvustada BuildBotvõimalusi. Milleks see tarkvara võimeline on? Kuidas sellega läheneda ja kuidas luua normaalsed TÕHUSAD TÖÖSUHTED? Meie kogemust saate rakendada ka enda juures, luues oma masinas töötlus- ja testimisteenuse oma projekti jaoks.

Sisu

Sisu

1. Miks BuildBot?
2. Kontseptsioon BuildMasteri juhtimise all
3. Paigaldamine
4. Esimese sammud

5. Konfigureerimine. Samm-sammuline juhend

5.1 BuildmasterConfig
5.2 töötajad
5.3 muudatus_allikas
5.4 ajakavad

5.5 BuildFactory
5.6 ehitajad

6. Näidis oma konfiguratsioonist

6.1 Teel oma master.cfg
6.2 Töö svn-iga
6.3 Teile kiri: reporters on volitatud teatama

Me tegime seda! Minu õnnitlused

1. Miks BuildBot?

Varem kohtasin habr-e artikleid rakenduste kohta Jätkuv integreerimine kasutades BuildBot. Näiteks, see tundus mulle kõige informatiivsem. On ka teine näide — lihtsam. Nendele artiklitele võib lisaks tuua näite käsiraamatust, ja see mugavuseks, ingliskeelsest. Kokkuvõttes on see hea lähtekoht. Kui olete need artiklid läbi lugenud, soovite kindlasti midagi BuildBot teha.

Peatus! Kas keegi on teda oma projektides kasutanud? Tundub, et jah, paljud kasutasid seda oma ülesannetes. Võib leida näidiste kasutusi BuildBot ka Google'i koodiarhiividest.

Mis on siis inimeste loogika, kes kasutavad Buildbot? Ведь есть другие инструменты: CruiseControl ja Jenkins. Vastan nii. Enamikul juhtudel Jenkins on see tõesti piisav. Omakorda, BuildBot — see on paindlikum, samas lahendatakse seal ülesanne sama lihtsalt nagu Jenkins. Valik on teie. Kuid kuna otsime tööriista areneva sihtprojekti jaoks, siis miks mitte valida see, mis võimaldab, tuginedes lihtsatele sammudele, luua ehitusüsteem, millel on interaktiivsus ja ainulaadne liides.

Kui sihikindel projekt on kirjutatud Pythonis, kerkib küsimus: "Miks mitte valida integratsioonisüsteemi, millel on arusaadav liides, arvestades projektis kasutatavat keelt?" Just nüüd on aeg tutvustada eeliseid. BuildBot.

Nii et meie "instrumentaalne kvartett". Olen määratlenud neli omadust. BuildBot:

  1. See on avatud lähtekoodiga raamistik GPL litsentsi alusel.
  2. See kasutab Pythonit konfiguratsiooni ja vajalike toimingute määratlemise tööriistana.
  3. See annab võimaluse saada vastuseid masina kaudu, kus kogumine toimub.
  4. Ja lõpuks on minimaalne hostimisnõue. Käitamiseks on vajalik Python ja Twisted, virtuaalmasinat ega Java masinat ei nõuta.

2. Kontseptsioon BuildMasteri juhtimise all

Continuous Integrationi rakenduse näide BuildBoti abil.

Tööde jaotuse arhitektuuris mängib keskset rolli BuildMaster. See on teenus, mis:

  • jälgib muutusi projekti lähtekoodide puudel
  • saadab käsklusi, mida töötaja teenus peab projekti ehitamiseks ja testimiseks täitma
  • teavitab kasutajaid teostatud toimingute tulemustest

BuildMaster konfigureeritakse faili kaudu master.cfg. See fail asub juurdas. BuildMaster. Hiljem näitan, kuidas see juur luuakse. Fail ise master.cfg sisaldab python - skripti, mis kasutab kõnesid BuildBot.

Järgmine kõige olulisem objekt BuildBot on nimega Worker. See teenus võib töötada teisel serveril teises opsüsteemis või samas, kus BuildMaster. Samuti võib see eksisteerida spetsiaalselt ettevalmistatud virtuaalses keskkonnas oma pakettide ja muutujatega. Need virtuaalsed keskkonnad võivad olla ette valmistatud python-utilities nagu vertualenv, venv.

BuildMaster edastab käske igale Worker-le, ja seejärel täidab need. See tähendab, et projekti ehitamise ja testimise protsess võib kulgeda Worker-l Windowsi haldusel ja teisel Worker-il Linuxi all.

Koodide hankimine toimub igas -s. WorkerNii et alustame. Hosti osas kasutan Ubuntu 18.04. Sellel paigaldan ühe

3. Paigaldamine

-i ja ühe BuildMaster-i. Kuid enne seda tuleb paigaldada python3.7: Workersudo apt-get update sudo apt-get install python3.7

Neile, kellele on vajalik python3.7.2 asemel 3.7.1, võib teha järgmist:

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


Järgmise sammuna paigaldame

Twited Twited ja BuildBot, samuti paketid, mis võimaldavad lisafunktsioone kasutada 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. Esimese sammud

Aeg luua BuildMaster. See jääb meile kausta /home/habr/master.

mkdir master
buildbot create-master master # Siin me tegelikult loobume

Järgmine samm. Loome Worker. See jääb meile kausta /home/habr/worker.

mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password

Kui te käivitate Worker, siis loob see vaikimisi kausta, mille nimi on projektinimes /home/habr/worker . Ja projektinimega kaustas loob ta katalooge master.cfg, ja sinna ta hakkab tegema build, ja edasi sellesse tegema checkout. Töökaust Worker-a on kaust /home/habr/yourProject/build.

«Kuldne» võtmeosa
Ja nüüd see, miks ma eelmist lõiku kirjutasin: skript, mis Master nõuab, et Worker-a teeks seda kaugelt selles kaustas, ei saa teostada, kuna skriptil pole käivitamisõigusi. Probleemi lahendamiseks on vajalik võtmeosa —umask=0o22, mis keelab kirjutamise sellele kaustale, kuid jäetakse käivitamisõigused alles. Me vajame just seda.

BuildMaster ja Worker loovad omavahel ühenduse. Juhtub, et see katkeb ja Worker ootab mõnda aega vastust BuildMaster-a. Kui vastust ei järgne, siis ühendus taaskäivitub. Võti —keepalive=60 on just vajalik selleks, et määrata aeg, mille möödumisel ühenda taaskäivitub.

5. Konfigureerimine. Samm-sammuline juhend

Konfiguratsioon BuildMaster käivitamisest, mis toimus masinal, kus me käsu andsime create-master. Meie puhul on see kataloog /home/habr/master. Konfiguratsioonifail master.cfg ei eksisteeri veel, kuid käsk on juba faili loonud master.cmg.sample. Tuleb see ümber nimetada master.cfg.sample ühes master.cfg

mv master.cfg.sample master.cfg

Avame selle master.cfg. Analüüsime, mis see sisaldab, ja seejärel proovime luua oma konfiguratsioonifaili.

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 — konfiguratsioonifaili põhikogum. See peab olema kohustuslikult kaasatud konfiguratsioonifaili. Koodi mugavuse huvides kasutatakse selle jaoks hüüdnime «c». Nimetused võtmed ühes c[«keyFromDist»] on fikseeritud elemendid, millega suhelda BuildMaster. Iga võtme jaoks antakse väärtuseks vastav objekt.

5.2 töötajad

c['workers'] = [worker.Worker("example-worker", "pass")]

Seekord näitame me BuildMaster- nimekirja Worker-dest. Me ise Worker loomise üle, märkides you-worker-name ja password. Nüüd tuleb need asendada example-worker ja pass .

5.3 muudatus_allikas

c['change_source'] = []
c['change_source'].append(changes.GitPoller(
                            'git://github.com/buildbot/hello-world.git',
                             workdir='gitpoller-workdir', branch='master',
                             pollInterval=300))                

Võtme change_source sõnastikus c saame juurdepääsu nimekirjale, kuhu tuleb paigutada objekt, mis küsib projekti lähtekoodi hoidlat. Näites kasutatakse Git-hoidlat, mida küsitakse teatud regulaarsuse järgi.

Esimene argument on tee teie hoidlast.

workdir näitab kausta teed, kus Worker-l seoses teega /home/habr/worker/yourProject/build git salvestab hoidla kohaliku versiooni.

branch sisaldab konkreetset haru hoidlas, millele jälgimist rakendatakse.

pollInterval sisaldab sekundite arvu, mille möödumisel BuildMaster küsitakse hoidla muudatuste järele.

On mitmeid viise, kuidas muudatusi projekti hoidlas jälgida.

Lihtsaim meetod on Polling, mis tähistab, et BuildMaster külastatakse serverit, kus asub repository. Kui commit peegeldab muudatusi repository's, siis BuildMaster mõne viivitusega loob sisemise objekti Change ja saadab selle sündmuste töötlejale Ajastaja, mis algatab projekti ülesehitamise ja testimise sammud Worker-s. Nende sammude hulgas on märgitud update repository. Just Worker-s luuakse kohalik koopia repository'st. Selle protsessi üksikasjad avaldatakse allpool järgmistes kahes osas (5.4 ja 5.5).

Veelgi elegantsem meetod muudatuste jälgimiseks repository's on otsene sõnumite saatmine serverilt, kus see asub, BuildMaster-le projekti lähtekoodide muutumisest. Sellisel juhul, kui arendaja teeb commit, saadab repository server projekti sõnumi BuildMaster-le. See omakorda püüab selle kinni, luues objekti PBChangeSource. Seejärel edastatakse see objekt Ajastaja, mis aktiveerib projekti ülesehitamise ja selle testimise sammud. Selle meetodi oluline osa on töö hook-serveri skriptidega repository's. Skriptis, hookmis vastutab toimingute töötlemise eest commit-s, tuleb kutsuda utiliit sendchange ja ja märkida võrguaadress BuildMaster-a. Tuleb märkida ka võrgupordi, mis kuulab PBChangeSource. PBChangeSource, muide, on osa BuildMaster-a. See meetod nõuab õigusi admin-a serveris, kus projektirepositoorium asub. Eelnevalt on vajalik repositooriumi varundamine.

5.4 ajakavad


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 – on element, mis toimib triggereina, käivitades kogu projekti ehitamise ja testimise ahela.
Continuous Integrationi rakenduse näide BuildBoti abil.

Need muudatused, mis on fikseeritud change_source, muundusid käitamise protsessis BuildBot-a objektiks Change ja nüüd iga Sheduler ehitab nende alusel päringud projekti ehitusprotsessi käivitamiseks. Samuti määrab ta, millal need päringud edastada järjekorda. Objekt Builder hoiab enda juures päringute järjekorda ja jälgib praeguse ehituse olekust eraldi Worker-e. Builder eksisteerib nii BuildMaster-e kui ka Worker-e. Just tema saadab BuildMaster-a Worker-a juba konkreetse build — sammude seeria, mida tuleb täita.
Nägime, et antud näites loob neid schedulers 2 tükki. Igal neist on oma tüüp.

SingleBranchScheduler – üks populaarsemaid ajakava klasse. See jälgib ühte haru ja aktiveerub kui sellel on fikseeritud muudatus. Kui see näeb muudatusi, võib see edasilükkamist taotleda (edasi lükata määratud ajavahemikuks spetsiaalses parameetris. treeStableTimer). Ajakava nimi määratakse, see kuvatakse name -veebiliideses. Ajakava määramisel BuildBotChangeFilter määratakse filter, mille läbimine sunnib haru muudatusi ajakava saatma ehitustaotluse. Ajakava määramisel builderNames märkige nimi builder builder-a, mille määrame natuke hiljem. Meie puhul on nimi sama, mis projekti nimi: yourProject.

ForceScheduler on üsna lihtne. See ajakava tüüp aktiveerub hiireklõpsuga veebiliideses. Parameetrid on samasugused nagu BuildBotP.S. nr. 3. Äkki on sellest kasu. SingleBranchScheduler.

Periodic
— see on ajakava, mis aktiveerub teatud fikseeritud ajaperioodilisuse järel. Selle väljakutse näeb välja umbes nii from buildbot.plugins import schedulers nightly = schedulers.Periodic(name="daily", builderNames=["full-solaris"], periodicBuildTimer=24*60*60) c['schedulers'] = [nightly]


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 määrab selle perioodi aja sekundites.

BuildFactory loomine konkreetne build, mis seejärel builder saadetakse Worker. Dokumendihalduses BuildFactory märgitakse sammud, mis tuleb täita Worker-le. Sammud lisatakse meetodi kutsumise kaudu addStep

Esimene lisatud samm selles näites on git clean -d -f -f –x, seejärel git checkout. Need toimingud on tõstetud parameetris meetod, mis pole selgelt näidatud, kuid tähistab vaikimisi väärtust fresh. Parameeter mode='incremental' ütleb, et kaustast, kuhu tehakse checkuot, jäävad samas repository's puuduvad failid puutumatuks.

Teine lisatud samm on skripti kutsumine trial parameetriga hello poolel Worker-lt kaustast /home/habr/worker/yourProject/build muutujaga PATHONPATH=… Seega saate kirjutada oma skripte ja käitada neid poolel Worker-s samm util.ShellCommand. Need skriptid saab asetada otse repository'sse. Siis, kui checkuot-s nad satuvad /home/habr/worker/yourProject/build. Siiski on kaks „aga“:

  1. Worker peab olema loodud võtmega —umask et see ei blokeeriks õigusi täitmise järel. checkout-a.
  2. Koormuse analüüsi korral git push-e neid skripte tuleb määrata omadus exacutable, et siis see ei kaoks checkuot-e õigused Git-i skripti täitmiseks.

5.6 ehitajad


c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
                                        workernames=["example-worker"],
                                        factory=factory))

Sellest, mis see on Builder oli räägitud siit. Nüüd räägin ma lähemalt, kuidas seda luua. BuilderConfig on konstruktor builder. Selliseid konstruktorid on c[‘builders’] võimalik määrata mitu, kuna see on objektide loetelu builder tüüpi. Nüüd pisut ümber kirjutame näite BuildBot, tuues selle meie ülesande lähedale.


c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
                                            workernames=["yourWorkerName"],
                                            factory=factory))

Nüüd räägin parameetritest BuilderConfig.

name määrab nime builder-a. Siin nimetasime selle yourProject. See tähendab, et sellele Worker-e luuakse see tee /home/habr/worker/yourProject/build. Sheduler otsitakse builder just selle nime järgi.

workernames sisaldab loetelu Worker-sid. Igaüks neist peab olema lisatud c[‘workers’].

factory — konkreetne build, millega see on seotud builder. See saadab objekti build järgnevaga Worker kõigi sammude täitmiseks, mis kuuluvad selle build-a.

6. Näidis oma konfiguratsioonist

Siin on projekti arhitektuur, mille ma pakun ellu viia BuildBot
.

Versioonihaldussüsteemina kasutame svn. Repositsioon asub mingis pilves. Siin on selle pilve aadress svn.host/svn/yourProject/trunk. Pilves, all svn on kontod username: kasutaja, passwd: password. Skriptid, mis koosnevad sammudest build-a asuvad samuti haru svn, eraldi kaustas buildbot/worker_linux. Need skriptid asuvad reposis, millel on salvestatud omadus executable.

BuildMaster ja Worker töötavad ühel hostil project.host .BuildMaster salvestab oma failid kausta /home/habr/master. Worker salvestab ka järgmisel teel /home/habr/worker. Protsesside vaheline suhtlus BuildMaster-a ja Worker-a toimub 4000 pordi kaudu protokolli BuildBot-a, nimelt ‘pb’ protokoll.

Sihtprojekt on täielikult kirjutatud pythonis. Ülesanne on jälgida selle muutusi, luua executable fail, genereerida dokumentatsioon, teostada testimist. Tõrke korral tuleb kõigile arendajatele saata e-kiri teatega, et on toimunud ebaõnnestunud tegevus.

Veebivaade BuildBot me ühendame 80 pordile eesmärgiga project.host. Apatchi paigaldamine ei ole vajalik. Raamatukogus twisted on juba olemas veebiserver, BuildBot mida kasutatakse.

Sisemise teabe salvestamiseks BuildBot asemel sqlite.

Mailide saatmiseks on vajalik host smtp.your.domain — see lubab saata kirju aadressilt projectHost@your.domain ilma autentimiseta. Samuti kuulatakse hostis ‘smtp ‘ protokolli pordi 1025 peal.

Protsessis osaleb kaks isikut: admin ja kasutaja. admin haldab BuildBot. user on isik, kes teostab commit-d.

Exacutable fail genereeritakse läbi pyinstaller. Dokumentatsioon genereeritakse läbi doxygen.

Selle arhitektuuri jaoks kirjutasin ma sellise 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>Valminud versiooni olek: {{ summary }}</h4>
<p>Kasutatav teenus ülesehitamiseks: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Juhtimisse paneeli vaatamiseks minge linki: {{ buildbot_url }}</p>
<p>Kogumise tulemuse vaatamiseks minge linki: {{ build_url }}</p>
<p>WinSCP abil saate serveriga ühendust võtta IP-ga: xxx.xx.xxx.xx. Logige sisse habr/password ja võtke allalaaditud executable fail kataloogist ~/worker/yourProject/build/dist.</p>
<p><b>Kogumine tehti Buildboti kaudu</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'] = "Kogumise protsess"
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"
}

Esmalt tuleb luua BuildMaster-a ja Worker-a. Seejärel sisestage see fail master.cfg ühes /home/habr/master.

Järgmiseks sammuks tuleb käivitada teenus BuildMaster-a


sudo buildbot start /home/habr/master

Seejärel käivitage teenus Worker-a


buildbot-worker start /home/habr/worker

Valmis! Nüüd Buildbot jälgib muudatusi ja käivitub commit-u svn, tehes projekti koostamise ja testimise samme antud arhitektuuriga.

Allpool kirjeldan ma mõningaid spetsiifikaid eespool mainitud master.cfg.

6.1 Teel oma master.cfg


Oma kirjutamise ajal tekib palju vigu, seega on vajalik logifaili lugemine. See salvestatakse nii master.cfg -e c absoluutse teega BuildMaster, kui ka poole /home/habr/master/twistd.log-a absoluutse teega Worker. Viga lugedes ja parandades tuleb teenus /home/habr/worker/twistd.log-a taaskäivitada. Nii see käib: BuildMastersudo buildbot stop /home/habr/master sudo buildbot upgrade-master /home/habr/master sudo buildbot start /home/habr/master


sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master

6.2 Töö svn-iga


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)

Alustame vaatamisest svn_poller. See on sama liides, mis küsib hoidlast iga minuti tagant. Antud juhul svn_poller puutub kokku ainult oksaga trunk. Salapärane parameeter split_file=util.svn.split_file_alwaystrunk määrab reeglid: kuidas kaustastruktuuri svn oksadeks jagada. Samal ajal pakub ta neile suhtelisi teid. Omakorda split_file_alwaystrunk lihtsustab protsessi, öeldes, et hoidlas on ainult trunk.

V Schedulers näidatakse määratakse filter, mille läbimine sunnib haru muudatusi ajakava saatma ehitustaotluse. Ajakava määramisel, mis näeb Puudub ja seondab sellega oksa trunk antud assotsiatsiooni kaudu split_file_alwaystrunk. Reageerides muudatustele trunk, käivitab builder c nimega yourProject.

properties siin on vajalik, et administraator saaks teateid kogumise ja testimise tulemuste kohta protsessi omanikuna.

Samm build-a checkout on suuteline täielikult kustutama kõiki faile, mis asuvad kohaliku hoidla versioonis. Worker-a. Ja seejärel teha täielik svn update. Režiim on seadistatud parameetri abil mode=full, method=fresh. Parameeter haltOnTailure näitab, et kui svn update töötatakse vea tõttu, tuleks kogu kogumise ja testimise protsess peatada, kuna edasised tegevused ei ole mõttekad.

6.3 Teile kiri: reporters on volitatud teatama


reporters on teavitusteenus e-posti teel.


template_html=u'''
<h4>Valminud versiooni olek: {{ summary }}</h4>
<p>Kasutatav teenus ülesehitamiseks: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Juhtimisse paneeli vaatamiseks minge linki: {{ buildbot_url }}</p>
<p>Kogumise tulemuse vaatamiseks minge linki: {{ build_url }}</p>
<p>WinSCP abil saate serveriga ühendust võtta IP-ga: xxx.xx.xxx.xx. Logige sisse habr/password ja võtke allalaaditud executable fail kataloogist ~/worker/yourProject/build/dist.</p>
<p><b>Kogumine tehti Buildboti kaudu</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]

See võib saata sõnumeid erinevate viisidega.

MailNotifier kasutab e-postit teadete saatmiseks.

template_html määrab sõnumi saatmiseks kasutatava teksti malli. Vormindamiseks kasutatakse html-i. See on muudetud mootoriga jinja2 (saab võrrelda django). BuildBot omab muutujaid, mille väärtused sisestatakse mallisse sõnumi sisu koostamise protsessis. Need muutujad on kirjutatud {{ topeltpainutud sulgudes }}. Näiteks, kokkuvõte näitab teostatavate operatsioonide staatust, st success või failure. Ja projects kuvab yourProject. Nii et juhtivate käskude abil jinja2, muutujad BuildBot-a ja stringide vormindamise vahenditega pythonis saab luua üsna informatiivse sõnumi.

MailNotifier sisaldab järgmisi argumendid.

fromaddr – aadress, kust kõik saavad edastada postitusi.

sendToInterestedUsers=True saadab sõnumi omanikule ja kasutajale, kes selle tegi commit.

lookup — Suffiks, mille tuleb lisada nimesid kasutajatelt, kes saavad postitusi. Nii admin et kasutaja saab postituse aadressile admin@your.domain.

relayhost määrab hostinime, kus server on avatud smtp, a smptPort määrab sadama numbri, mida kuulab smtp serverilt.

mode="warning" ütleb, et postitusi tuleks teha ainult juhul, kui vähemalt üks samm build-a on lõppenud staatusega failure või warning. Juhul kui status on success, postitusi tegema ei pea.

extraRecipients sisaldab nimekirja isikutest, kellele tuleks postitada peale omaniku ja isiku, kes selle tegi commit.

messageFormatter on objekt, mis määrab sõnumi vormingu, selle mall ja muutujate kogumi, mis on saadaval jinja2. Sellised parameetrid nagu wantProperties=True ja wantSteps=True määravad selle saadaval olevate muutujate kogumi.

s['services']=[sendMessageToAll] annab nimekirja teenustest, mille seas on ka meie reporter.

Me tegime seda! Minu õnnitlused

Oleme loonud oma konfiguratsiooni ja näinud selle funktsionaalsust, milleks ta on võimeline. BuildBotArvan, et sellest piisab, et mõista, kas see tööriist on teie projekti loomiseks vajalik. Kas see huvitab teid? Kas see tuleb teile kasuks? Kas sellega on mugav töötada? Siis ei ole mul põhjendamatult seda artiklit kirjutada.

Ja veel. Sooviksin, et professionaalne kogukond, kes kasutab BuildBot, laieneks, käsiraamatud tõlgitaks ja näidisprojekte saaks veelgi rohkem.

Aitäh kõigile tähelepanu eest. Edu.

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster