(Kép forrása a
Helló!
A nevem Evgeny Cherkin, programozó vagyok a bányászati cég Polymetal.
bármely nagyobb projekt elkezdésekor azon kezd el gondolkodni az ember, hogy: "Milyen szoftverek a legjobbak a karbantartásához?". Az IT-projekt egy új verzió kiadása előtt számos lépést jár végig. Jó dolog, ha ezen lépések láncolata automatizált. Az automatizált folyamat, amely a legújabb verzió kiadását jelenti, azt hívjuk folyamatos integrációnak. A BuildBot jó segítőtársnak bizonyult számunkra ennek a folyamatnak a megvalósításában.
Ebben a cikkben áttekintést szeretnék nyújtani a lehetőségeiről A BuildBot. Mire képes ez a szoftver? Hogyan lehet hozzáférni és hogyan alakítsunk ki hatékony MUNKAPARTNERI VISZONYOKAT? A mi tapasztalatunkat alkalmazhatja ön is, létrehozva a saját gépén egy építési és tesztelési szolgáltatást a projektjéhez.
Tartalom
Tartalom
1. Miért a BuildBot?
Korábban a habr-e-n találkoztam cikkekkel a megvalósításról folyamatos integrációnak a A BuildBotsegítségével. számomra a leginformatívabbnak tűnt. Van egy másik példa — . Ezeket a cikkeket megfűszerezhetjük , és egy kiegészítő, angol nyelven. Így egy jó kiindulópontot kapunk. Ha elolvassa ezeket a cikkeket, biztosan azonnal valamit szeretne csinálni a A BuildBot márkájával.
Álljon meg! Használta egyáltalán valaki a saját projektjeiben? Kiderül, hogy igen, alkalmazták a saját feladataikban. Kaphatunk a Google kódarchívumaiban. A BuildBot Mi tehát az emberek logikája, akik használják
Buildbot-ot CruiseControl? Ведь есть другие инструменты: . Így válaszolok. A legtöbb feladathoz és Jenkinsvalóban elegendő lesz. A maga részéről, Jenkins — sokkal rugalmasabb, miközben itt a feladatokat éppúgy megoldják, mint a A BuildBot . Ön dönti el. De mivel egy fejlődő célprojekthez keresünk eszközt, miért ne válasszunk olyat, amely lehetővé teszi, hogy az egyszerű lépésektől kiindulva egy interaktív és egyedi felhasználói felülettel rendelkező építési rendszert kapjunk. JenkinsÖn dönti el. De mivel egy fejlődő célprojekthez keresünk eszközt, miért ne választanánk egyet, amely lehetővé teszi, hogy egyszerű lépésekből egy interaktív és egyedi felületű rendszert hozzunk létre?
A python-ral kapcsolatos projektjeik vannak, felmerül a kérdés: "Miért ne választhatnánk olyan integrációs rendszert, amely érthető felületet kínál a projektben használt nyelv szempontjából?" És itt az ideje bemutatni az előnyöket A BuildBot.
Tehát, itt van a "szerszámsorunk". Én négy jellemzőt határoztam meg A BuildBot:
- Ez egy GPL licenc alatt álló nyílt forráskódú keretrendszer
- Ez a python használata konfiguráló és a szükséges lépések leírására
- Ez a lehetőség, hogy választ kapjunk arról a gépről, amelyen a build folyamat zajlik
- Ez végül a minimum követelmények a hosztra. A telepítéshez pythonra és twistedre van szükség, nincs szükség virtuális gépre vagy java gépre.
2. A BuildMaster vezető koncepciója
A feladatok elosztásának középpontjában áll BuildMaster. Ez egy szolgáltatás, amely:
- figyeli a projekt forrásfájljainak változásait
- küld utasításokat, amelyeket a Worker szolgáltatásnak végre kell hajtania a projekt felépítése és tesztelése érdekében
- értesíti a felhasználókat a végrehajtott műveletek eredményéről
BuildMaster konfigurálható egy master.cfgfájl segítségével. Ez a fájl az gyökérkönyvtárban található BuildMaster. Később megmutatom, hogyan jön létre ez a gyökér. Maga a fájl master.cfg tartalmaz egy python - szkriptet, amely hívásokat használ A BuildBot.
A következő legfontosabb objektum A BuildBot a következő neve: Worker. Ez a szolgáltatás más hoszton, más operációs rendszeren is futtatható, de lehet azon is, ahol BuildMaster. Szintén létezhet egy külön készített virtuális környezetben a saját csomagjaival és változóival. Ezek a virtuális környezetek python segédprogramokkal, mint például vertualenv, venv.
BuildMaster utasításokat ad mindegyiknek, amelyeket az végrehajt. Tehát azt kapjuk, hogy a projekt felépítési és tesztelési folyamata folyhat egy Worker-en Windows irányításával és egy másik Worker-en Linux alatt. WorkerA Checkout
a projekt forráskódjain történik minden -en. WorkerTehát kezdjük. A hosztnak az Ubuntu 18.04-et fogom használni. Ezen fogok elhelyezni egy
3. Telepítés
-t és egy BuildMaster-t. De először telepítem a python3.7-t: Workersudo apt-get update sudo apt-get install python3.7
Akiknek python3.7.2-re van szükségük a 3.7.1 helyett, az alábbiak szerint járhatnak el:
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
A következő lépés a
Twisted telepítése Twited és A BuildBot, valamint csomagok, amelyek lehetővé teszik a további funkciók használatát A 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. Első lépések
Ideje létrehozni BuildMaster. Ez a mappában lesz /home/habr/master.
mkdir master
buildbot create-master master # Itt hozzuk létreKövetkező lépés. Hozzunk létre Worker. Ez a mappában lesz /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Amikor elindítjuk Worker, alapértelmezés szerint létrehoz egy /home/habr/worker mappát a projekt nevével, amely a master.cfg. És a projekt nevét viselő mappában létrehozza a build, és abba fogja elvégezni a checkout. A munkakönyvtár Worker-a a /home/habr/yourProject/build.
„Arany” kulcsot
Most pedig elérkeztünk ahhoz, amiért írtam az előző bekezdést: a szkripthez Master kérni fogja Worker-a, hogy ezt a könyvtárat távolról hajtsa végre, nem lesz végrehajtva, mivel a szkriptnek nincs jogosultsága a futtatásra. A helyzet megoldásához szükség lesz a --umask=0o22, ami megtiltja az írást ebbe a könyvtárba, azonban a futtatási jogosultságokat megőrzi. Éppen erre van szükségünk.
BuildMaster és Worker kapcsolatot létesítenek egymással. Előfordul, hogy a kapcsolat megszakad, és Worker egy ideig vár válaszra az BuildMaster-a. Ha nem jön válasz, a kapcsolat újraindul. A kulcs --keepalive=60 éppen arra szolgál, hogy megadja az időtartamot, amely elteltével connect újraindul.
5. Konfiguráció. Lépésről lépésre recept
Konfiguráció BuildMaster azon a gépen történik, ahol végrehajtottuk a parancsot create-master. Esetünkben ez a könyvtár /home/habr/master. A konfigurációs fájl master.cfg még nem létezik, de a parancs már létrehozta a fájlt master.cmg.sample. Át kell neveznünk master.cfg.sample be. master.cfg
mv master.cfg.sample master.cfgMegnyitjuk ezt a master.cfg. És megnézzük, miből áll. Ezután megpróbálunk létrehozni a saját konfigurációs fájlunkat.
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 — az alapértelmezett konfigurációs fájl szótár. Kérjük, hogy ezt mindenképpen használja a konfigurációs fájlban. A kód kényelmesebb használhatósága érdekében bevezetésre került az alias. «c». A nevek be. c[«keyFromDist»] rögzített elemek az interakcióhoz BuildMaster. Minden kulcs számára a megfelelő objektum kerül hozzáadásra értékként.
5.2 munkavállalók
c['workers'] = [worker.Worker("example-worker", "pass")]Ezúttal megadjuk BuildMaster-a listát a Worker-król. Magát Worker korábban hoztuk létre , megadva you-worker-name és password. Most ezeket kell helyettesítenünk example-worker és pass .
5.3 change_source
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
A "change_source" kulcson a c szótárból hozzáférhetünk a listához, ahová a projekt forráskód-ellenőrzéséhez szükséges objektumot kell elhelyezni. A példában egy Git tároló kerül használatra, amelyet bizonyos időközönként kérdezünk le. Az első argumentum az Ön tárolójának elérési útja.
workdir
az a mappa elérési útját jelenti, ahol a -n belül a helyi tároló verzióját tárolja a Workerkörnyezetileg, az elérési út alapján. /home/habr/worker/yourProject/build a git tárolja a helyi tároló verzióját.
branch tartalmazza a tárolóban figyelni kívánt specifikus ágat.
pollInterval tartalmazza a másodpercek számát, amely után BuildMaster kérdezi a tárolót változásokra.
Több módszer is létezik a projekt tárolóban történt változások nyomon követésére.
A legjobb módszer a Polling, ami azt jelenti, hogy BuildMaster időszakonként lekérdezi a tárolót a szerveren. Abban az esetben, ha commit a tárolóban végrehajtott változások bejegyzésre kerültek, akkor BuildMaster egy bizonyos késleltetéssel létrehoz egy belső objektumot Change és elküldi azt az eseménykezelőnek Scheduler, amely elindítja a projekt összeállítási és tesztelési lépéseit a(z) Worker-n. Ezek között a lépések között szerepelni fog az update a tárolón. Pontosan itt fog létrejönni a tároló helyi másolata. A folyamat részletei a következő két szakaszban lesznek feltárva WorkerMég elegánsabb módszer a tároló változásainak nyomon követésére, ha közvetlenül üzeneteket küldünk a szerverről, ahol a tároló található, a(z) ( és ).
-nek a projekt forráskódjainak megváltozásáról. Ebben az esetben, amint a fejlesztő létrehozza a BuildMaster, a projekt tárolóját üzenetet küld a(z) commit-nek. A harmadik fél pedig ezt a változást egy BuildMasterPBChangeSource objektum létrehozásával fogja elfogni. Ezután ez az objektum továbbításra kerül a(z), ami aktiválja a projekt összeállítási és tesztelési lépéseit. Ennek a módszernek fontos eleme a Schedulerhook -szkriptek kezelése a tárolóban. A(z)-ban, amely az események feldolgozásáért felelős, meg kell hívni a -szkriptek kezelése a tárolóban. A(z)sendchange commitsegédprogramot, és meg kell adni a hálózati címet -nek. A hálózati portot is meg kell adni, amely figyelni fog a(z) , ami egyébként szerves része BuildMaster-nek. Ez a módszer adminisztrátori jogosultságokat igényel a(z) objektum létrehozásával fogja elfogni. Ezután ez az objektum továbbításra kerül a(z). objektum létrehozásával fogja elfogni. Ezután ez az objektum továbbításra kerül a(z)szerveren, ahol a projekt tárolója található. Először le kell menteni a tároló biztonsági mentését. BuildMasterc['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"])) adminschedulers
5.4 ütemezők
– egy elem, amely aktiválja a teljes összeállítási és tesztelési folyamat láncolatát.
Azok a változások, amelyeket rögzítettek , átalakultak a(z)
-ban lévő munka során egy objektummá, és most minden egyes a c szótárból hozzáférhetünk a listához, ahová a projekt forráskód-ellenőrzéséhez szükséges objektumot kell elhelyezni. A példában egy Git tároló kerül használatra, amelyet bizonyos időközönként kérdezünk le.Sheduler A BuildBotezen alapjára épít kérdéseket a projekt összeállítási folyamatának elindítására. Azonban azt is meghatározza, mikor továbbítja ezeket a kérdéseket a sorba. Az objektum Change Builder a kérdések sorát tárolja, és nyomon követi az aktuális összeállítás állapotát a különböző -ban. Ez létezik a -ban és a Worker-ban. Ő küld már a(z) Ez létezik a -ból egy konkrét BuildMasterlépés-sorozatot, amelyet végre kell hajtani. WorkerLátjuk, hogy a jelenlegi példában ilyenből BuildMaster2 darab készül. Ráadásul mindegyiknek megvan a saját típusa. WorkerSingleBranchScheduler build — egy sor lépés, amelyet végre kell hajtani.
Látjuk, hogy a jelenlegi példában ilyenek Azok a változások, amelyeket rögzítettek 2 darab készül. Ráadásul mindegyik saját típussal rendelkezik.
SingleBranchScheduler – az egyik legnépszerűbb ütemezési osztály. Figyeli az egyik ágat, és rögzített változás esetén aktiválódik. Amikor változásokat észlel, elhalaszthatja a kérés elküldését az építési folyamathoz (elhalaszthatja egy megadott időtartamra, amelyet külön paraméter határoz meg treeStableTimer). A name ütemezés neve adható meg, amely megjelenik a A BuildBot-webfelületen. A ChangeFilter paraméter határozza meg a szűrőt, amelyen áthaladva a változások az ágon arra ösztönzik az ütemezést, hogy kérdést küldjön az építkezéshez. A builderNames meghatározza a nevet Torrentek:-nak, amelyet később adunk meg. A név esetünkben megegyezik a projekt nevével: yourProject.
ForceScheduler egy meglehetősen egyszerű dolog. Ez a típusú ütemezés egy kattintásra aktiválódik a A BuildBot-webfelületen. A paraméterek ugyanazt a célt szolgálják, mint a SingleBranchScheduler.
P.S. #3. Hogy hasznos lehet
Periodikus — ez egy olyan ütemezés, amely meghatározott időközönként aktiválódik. A hívása körülbelül így néz ki
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 határozza meg a periódus időtartamát másodpercekben.
BuildFactory konkrétan létrehozza a build, amelyet utána Torrentek: küld el a Worker. A BuildFactory meghatározza azokat a lépéseket, amelyeket végre kell hajtani Worker-ra. A lépések az addStep
metódus hívásával kerülnek hozzáadásra. Az első hozzáadott lépés ebben a példában — git clean -d -f -f –x, majd git checkout. Ezek a műveletek benne vannak a methodparaméterben, amely egyértelműen nincs megadva, de sugallja az alapértelmezett értéket fresh. A paraméter mode='incremental' arra utal, hogy a könyvtárból, ahová a chechouttörténik, az ott nem található fájlok érintetlenek maradnak.
A második hozzáadott lépés — egy szkript hívása trial a hello paraméterrel Workeroldalon keresztül /home/habr/worker/yourProject/build c könyvtárból Workera PATHONPATH=… környezeti változóval. Így saját szkripteket írhatsz, és végrehajthatod azokat a -a lépésen keresztülutil.ShellCommand chechout. Ezeket az adatokat közvetlenül a repóba lehet helyezni. Akkor a /home/habr/worker/yourProject/build–ben ezek bekerülnek
- Worker . Azonban itt van két „de”: —umask checkout-a.
- Mikor git pushannak érdekében, hogy ne blokkolja a végrehajtás jogát a -ben ezeket a szkripteket kötelezően meg kell adni azexecutable chechout-e jogok a Git szkript futtatására nem vesztek el.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Arról, hogy mi az, Ez létezik a már beszéltünk . Most részletesebben elmondom, hogyan hozhatjuk létre. BuilderConfig egy konstruktor Torrentek:. Ezekből a konstruktórkból c[‘builders’] több is megadható, mivel ez egy objektumok listája Torrentek: típusú. Most egy kicsit átírjuk a példát, A BuildBot, hogy közelebb kerüljön a feladatunkhoz.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Most a paramétereket fogom elmondani. BuilderConfig.
name megnevezi Torrentek:-a. Itt ezt adtuk neki. yourProject. Ez azt jelenti, hogy a Worker-en létrejön ez a bizonyos útvonal, /home/habr/worker/yourProject/build. a kérdések sorát tárolja, és nyomon követi az aktuális összeállítás állapotát a különböző kikeresi Torrentek: éppen ezen a néven.
workernames tartalmaz egy listát Worker-ról. Mindegyiknek fel kell venni a c[‘workers’].
factory — konkrét build, amellyel társítva van. Torrentek:. Ez meg fogja hívni az objektumot, build Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Worker hogy végrehajtsa az összes lépést, ami benne van build-a.
6. Példa saját konfigurációnkra
Itt van a projekt példa architektúrája, amelyet javaslok megvalósítani A BuildBot
.
A verziókezelő rendszerként svn-t fogunk használni. Magának a tárolónak egy felhőben kell lennie. Itt van ennek a felhőnek az elérhetősége: . A felhő alatt svn itt van egy felhasználónév: user, passwd: password. A szkriptek, amelyek a lépéseket jelentik build-a szintén a ágban fognak található lenni, svnkülön mappában buildbot/worker_linux. Ezek a szkriptek ugyanott vannak tárolva, executable.
BuildMaster és Worker egy hoston működnek, project.host .BuildMaster a fájlokat a mappában tárolja, /home/habr/master. Worker ugyanezen az úton tárol. /home/habr/worker. A folyamatok BuildMaster-a és Worker-a közötti kapcsolat a 4000-es porton keresztül történik a A BuildBot-a protokollal, azaz ‘pb’
protokoll.
A célprojekt teljesen python-ban van megírva. A feladat nyomon követni a változásait, létrehozni egy executable fájlt, generálni dokumentációt és tesztelést végezni. Hiba esetén az összes fejlesztőnek üzenetet kell küldeni az e-mail címére arról, hogy van egy sikertelen művelet. A BuildBot A webes megjelenítést project.host80-as porton fogjuk csatlakoztatni a . Az Apatch telepítése nem kötelező. A könyvtárban található twisted A BuildBot már tartalmaz web szervert,
amit használni fog. A BuildBot Belső célú információk tárolásához sqlite-ot fogunk használni..
A levelezéshez szükség van egy hostra, smtp.your.domain — engedélyezett a levelek küldése a projectHost@your.domain nélkül, hogy hitelesítés szükséges. Ezen a hoston asmtp protokoll is a 1025-ös porton figyel.
A folyamat során két érintett fél van: admin és user. admin adminisztrátor A BuildBot. user a végrehajtó személy commit-k.
Az Exacutable fájl létrehozása a következővel: pyinstaller. A dokumentáció létrehozásához: doxygen.
Ehhez az architektúrához írtam egy ilyet 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>A felépített kiadás státusza: {{ summary }}</h4>
<p>A használt szolgáltatás a felépítéshez: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>A kezelőfelület megtekintéséhez kattintson ide: {{ buildbot_url }}</p>
<p>A felépítés eredményének megtekintéséhez kattintson ide: {{ build_url }}</p>
<p>A WinSCP segítségével csatlakozhat a szerverhez az ip:xxx.xx.xxx.xx címen. Bejelentkezve a habr/password néven, letöltheti a felépített executable fájlt a ~ /worker/yourProject/build/dist könyvtárból.</p>
<p><b>A felépítést Buildbot végezte</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'] = "A felépítési folyamat"
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"
}
Először is szükséges BuildMaster-a és Worker-a. Ezután be kell illeszteni ezt a fájlt master.cfg be. /home/habr/master.
A következő lépésben a szolgáltatást kell elindítani BuildMaster-a
sudo buildbot start /home/habr/master
Ezután el kell indítani a szolgáltatást Worker-a
buildbot-worker start /home/habr/worker
Kész! Most CruiseControl figyelni fogja a változásokat és reagálni fog a commit-ra a svn, végrehajtva a fenti architektúrával a projekt build és teszt lépéseit.
Az alábbiakban néhány jellemzőt ismertetek a fenti master.cfg-fájlban.
6.1 Az én master.cfg-m felé
A saját írásom során master.cfg sok hiba fog elkövetődni, így szükség lesz a log-fájlok olvasására. Az a BuildMaster-e c abszolút elérési úttal /home/habr/master/twistd.log, valamint a Worker-a abszolút elérési úttal /home/habr/worker/twistd.log. A hibák olvasása és javítása során a szolgáltatás újraindítására is szükség lesz BuildMaster-a. Így kell ezt csinálni:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Munkavégzés svn-nel
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)
Először nézzük meg a svn_poller. Ez ugyanaz a felület, amely rendszeresen lekéri a tárolót percenként. Ebben az esetben svn_poller csak az ágához fordul trunk.A rejtélyes paraméter split_file=util.svn.split_file_alwaystrunk meghatározza a szabályokat: hogyan kell a mappastruktúrát svn ágakra bontani. Ez az, ami relatív elérési útvonalakat javasol. Cserébe split_file_alwaystrunk egyszerűsíti a folyamatot, mivel azt mondja, hogy a tároló csak trunk..
A Scheduler meg van határozva ChangeFilter, amely látja None és asszociálja azzal az ággal trunk. az előírt asszociáció révén split_file_alwaystrunk. A változásokra reagálva elindítja trunk.c névvel Torrentek: properties yourProject.
itt szükséges ahhoz, hogy az adminisztrátor értesítést kapjon a build és tesztelési eredményekről, mint a folyamat tulajdonosa. Lépés
teljes törlést tud végezni bármely fájlra, amely a helyi tárolóban található build-a checkout -a. Aztán teljes Workerkészít. svn update. A módot a paraméter határozza meg mode=full, method=fresh. A paraméter haltOnTailure arra utal, hogy ha svn update hiba történik, akkor a teljes összesítési és tesztelési folyamatot meg kell állítani, mivel a további lépéseknek nincs értelme.
6.3 Megérkezett egy levél: a riporterek felhatalmazva nyilatkozni
reporters – ez egy értesítési szolgáltatás, amely e-mailt küld.
template_html=u'''
<h4>A felépített kiadás státusza: {{ summary }}</h4>
<p>A használt szolgáltatás a felépítéshez: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>A kezelőfelület megtekintéséhez kattintson ide: {{ buildbot_url }}</p>
<p>A felépítés eredményének megtekintéséhez kattintson ide: {{ build_url }}</p>
<p>A WinSCP segítségével csatlakozhat a szerverhez az ip:xxx.xx.xxx.xx címen. Bejelentkezve a habr/password néven, letöltheti a felépített executable fájlt a ~ /worker/yourProject/build/dist könyvtárból.</p>
<p><b>A felépítést Buildbot végezte</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]
Képes üzeneteket küldeni .
MailNotifier e-mailt használ az értesítések küldésére.
template_html meghatározza a szövegmintát az értesítések számára. A HTML-t használják a formázáshoz. A motor módosítva van (összehasonlítható a django). A BuildBot van egy változó készlete, amelynek értékei a minta során kerülnek behelyettesítésre az üzenet szövegének előállítása közben. Ezek a változók {{ dupla kapcsos zárójelek }} között vannak. Például, summary mutatja az elvégzett műveletek állapotát, azaz success vagy failure. A projects ki fogja írni yourProject. Így az irányító parancsok, a jinja2, a változók A BuildBot-a és a python sztringformázási eszközök révén egy igazán informatív üzenetet hozhatunk létre.
MailNotifier tartalmazza a következő argumentumokat.
fromaddr – az a cím, ahonnan az összes értesítést küldjük.
sendToInterestedUsers=True küldi az üzenetet a tulajdonosnak és annak a felhasználónak, aki a commit.
lookup – a felhasználónevekhez hozzáadandó suffix, akik értesítést fognak kapni. Tehát admin a felhasználó az admin@your.domain címre fog értesítést kapni.
relayhost meghatározza a host nevét, ahol a szerver be van állítva smtp, a smptPort megadja a port számát, amelyet a smtp szerver figyel.
mode=«warning» arra utal, hogy az értesítést csak abban az esetben kell küldeni, ha legalább egy lépés build-a, amelynek statisztikája failure vagy warning volt. Success esetén az értesítést nem kell küldeni.
extraRecipients tartalmazza azokat az embereket, akikkel az értesítést a tulajdonos és a végrehajtó személy mellett el kell küldeni. commit.
messageFormatter egy objektum, amely meghatározza az üzenet formátumát, a mintát és a változók készletét, amelyek elérhetőek a jinja2. Olyan paraméterek, mint wantProperties=True és wantSteps=True meghatározzák ezt az elérhető változók készletét.
s[‘services’]=[sendMessageToAll] megadja a szolgáltatások listáját, közöttük a mi reporterünket.
Megcsináltuk! Gratulálok
Saját konfigurációnkat létrehoztuk, és láttuk a funkciókat, amelyekre képes. A BuildBotEz elégséges ahhoz, hogy megértsük, szükség van-e erre az eszközre a projekt létrehozásához. Érdekel téged? Hasznos lenne számodra? Könnyű vele dolgozni? Akkor nem írtam hiába ezt a cikket.
És még egy dolog. Szeretném, ha a szakmai közösség, amely ezt használja A BuildBot, szélesebb lett, a kézikönyvek fordítása megtörtént, és egyre több példa készült.
Köszönöm mindenkinek a figyelmet. Sok sikert.
Forrás: habr.com
