(Bild von from
Hallo!
Mein Name ist Eugene Tschergin, ich bin Programmierer im Entwicklerteam des Bergbauunternehmens Polymetal.
Wenn man mit einem größeren Projekt beginnt, denkt man oft darüber nach: „Welche Software eignet sich am besten für den Betrieb?“. Ein IT-Projekt durchläuft vor der Veröffentlichung einer neuen Version mehrere Phasen. Es ist von Vorteil, wenn die Abfolge dieser Phasen automatisiert ist. Der automatisierte Prozess zur Veröffentlichung einer neuen Version eines IT-Projekts nennt sich Continuous Integration. BuildBot , der sich als hilfreicher Begleiter zur Umsetzung dieses Prozesses erwiesen hat.
In diesem Artikel möchte ich einen Überblick über die Funktionen BuildBot. Was kann diese Software leisten? Wie geht man am besten damit um und wie kann man eine effektive ARBEITSBEZIEHUNG aufbauen? Erfahrungen, die wir gemacht haben, können Sie ebenfalls umsetzen, indem Sie auf Ihrem Computer einen funktionalen Build- und Testdienst für Ihr Projekt erstellen.
Inhalt
Inhalt
1. Warum BuildBot?
Früher habe ich auf habr-e Artikel über Implementierungen gesehen Continuous Integration geschrieben und verwendet BuildBot. Zum Beispiel, schien mir am informativsten. Es gibt ein anderes Beispiel — . Diese Artikel können mit , und in englischer Sprache ergänzt werden. Damit ergibt sich ein guter Ausgangspunkt. Nach dem Lesen dieser Artikel möchten Sie sicherlich sofort etwas auf BuildBot machen.
Stopp! Hat ihn übrigens jemand in seinen Projekten verwendet? Es stellt sich heraus, ja, haben ihn in ihren Aufgaben genutzt. Man kann ihn auch den Einsatz BuildBot in den Google-Code-Archiven finden.
Wie sieht also die Denkweise der Menschen aus, die Buildbot? Ведь есть другие инструменты: CruiseControl und Jenkinsverwenden? Ich antworte so: Für die meisten Aufgaben Jenkins wird es wirklich ausreichen. Im Gegenzug ist es BuildBot anpassungsfähiger, wobei die Aufgaben dort ebenso einfach gelöst werden wie in Jenkins. Es liegt an Ihnen zu entscheiden. Aber da wir ein Werkzeug für ein sich entwickelndes Zielprojekt suchen, warum nicht das wählen, das es ermöglicht, basierend auf einfachen Schritten, ein Build-System mit Interaktivität und einzigartiger Benutzeroberfläche zu erhalten.
Für diejenigen, deren Zielprojekt in Python geschrieben ist, stellt sich die Frage: „Warum nicht ein Integrationssystem wählen, das eine klare Benutzeroberfläche hinsichtlich der verwendeten Sprache im Projekt bietet?“. Hier ist der beste Zeitpunkt, um die Vorteile vorzustellen. BuildBot.
Also, unser „Instrumenten-Quartett“. Ich habe vier Merkmale für mich definiert. BuildBot:
- Es handelt sich um ein Framework mit offenem Quellcode unter der GPL-Lizenz.
- Es nutzt Python als Konfigurationstool und zur Beschreibung der erforderlichen Aktionen.
- Es bietet die Möglichkeit, Antworten von der Maschine zu erhalten, auf der der Build-Prozess erfolgt.
- Schließlich sind die Anforderungen an den Host minimal. Für die Bereitstellung werden nur Python und Twisted benötigt; eine virtuelle Maschine oder eine Java-Maschine sind nicht erforderlich.
2. Konzept mit BuildMaster im Fokus
Zentral in der Architektur der Aufgabenverteilung steht BuildMaster. Er ist ein Service, der:
- Änderungen im Quellbaum des Projekts überwacht, Befehle an den Worker-Service sendet, die ausgeführt werden müssen, um das Projekt zu bauen und zu testen,
- Benutzer über die Ergebnisse durchgeführter Aktivitäten informiert, und über eine Datei konfiguriert wird.
- Diese Datei befindet sich im Hauptverzeichnis. Benutzern über die Ergebnisse durchgeführter Aktionen
BuildMaster wird über eine Datei konfiguriert master.cfg. Diese Datei befindet sich im Stammverzeichnis BuildMaster. Später zeige ich Ihnen, wie dieses Root erstellt wird. Die Datei selbst master.cfg enthält ein Python-Skript, das Aufrufe verwendet. BuildBot.
Das nächste, am wichtigsten Objekt BuildBot trägt den Namen SharedWorker. Dieser Dienst kann auf einem anderen Host mit einem anderen Betriebssystem oder auch auf dem, wo BuildMasterausgeführt werden. Zudem kann es in einer speziell vorbereiteten virtuellen Umgebung mit eigenen Paketen und Variablen existieren. Diese virtuellen Umgebungen können mit Python-Utilities wie virtualenv, venv.
BuildMaster Befehle an jeden SharedWorker- senden, und dieser führt sie dann aus. Das bedeutet, dass der Prozess des Aufbaus und Testens des Projekts auf SharedWorker- unter Windows und auf einem anderen Worker unter Linux laufen kann.
Checkout des Quellcodes des Projekts erfolgt auf jedem SharedWorker-.
3. Installation
Legen wir los. Als Host werde ich Ubuntu 18.04 verwenden. Darauf werde ich einen BuildMaster- und einen SharedWorker- einrichten. Aber zuerst müssen wir Python 3.7 installieren:
sudo apt-get update
sudo apt-get install python3.7
Für diejenigen, die Python 3.7.2 anstelle von 3.7.1 benötigen, können Sie Folgendes tun:
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
Der nächste Schritt ist die Installation von Twisted und BuildBot, sowie Pakete, die zusätzliche Funktionen ermöglichen. 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. Erste Schritte
Zeit, um zu erstellen BuildMaster. Es wird in unserem Ordner sein /home/habr/master.
mkdir master
buildbot create-master master # Hier erstellen wir esDer nächste Schritt. Lassen Sie uns erstellen SharedWorker. Es wird in unserem Ordner sein /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 IhrWorkerName Passwort
Wenn Sie starten SharedWorker, wird standardmäßig im /home/habr/worker ein Ordner mit dem Projektnamen, der in master.cfg, angegeben ist, erstellt. In diesem Ordner mit dem Projektnamen wird er ein Verzeichnis erstellen build, und darin wird er weiter machen checkout. Das Arbeitsverzeichnis für SharedWorker-a wird das Verzeichnis sein /home/habr/yourProject/build.
„Goldenes“ Schlüsselchen.
Und jetzt zu dem, weshalb ich den vorherigen Absatz geschrieben habe: das Skript, das Master von SharedWorker-a in diesem Verzeichnis fernzugerufen werden muss, wird nicht ausgeführt, da das Skript keine Berechtigung für den Start hat. Um die Situation zu beheben, benötigen wir den Schlüssel —umask=0o22, der die Schreibberechtigung in dieses Verzeichnis einschränkt, aber die Ausführungsrechte belässt. Genau das brauchen wir.
BuildMaster und SharedWorker eine Verbindung zueinander herstellen. Manchmal wird sie unterbrochen und SharedWorker wartet eine Zeit lang auf eine Antwort von BuildMaster-a. Wenn keine Antwort kommt, wird die Verbindung neu gestartet. Der Schlüssel —keepalive=60 ist genau dafür gedacht, um die Zeit anzugeben, nach deren Ablauf verbinden wird neu gestartet.
5. Konfiguration. Schritt-für-Schritt-Rezept
Konfiguration BuildMaster wird auf der Maschine durchgeführt, auf der wir den Befehl ausgeführt haben create-master. In unserem Fall handelt es sich um das Verzeichnis /home/habr/master. Die Konfigurationsdatei master.cfg existiert noch nicht, aber der Befehl hat bereits die Datei erstellt master.cmg.sample. Sie muss umbenannt werden in master.cfg.sample in master.cfg
mv master.cfg.sample master.cfgLassen Sie uns diese master.cfg. Und analysieren, woraus sie besteht. Danach versuchen wir, unsere eigene Konfigurationsdatei zu erstellen.
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 — die grundlegende Konfiguration des Konfigurationsfiles. Sie muss unbedingt im Konfigurationsfile aktiviert werden. Zur vereinfachten Nutzung im Code wird ein Alias für sie eingeführt. «c». Die Namen in c[«keyFromDist»] sind feste Elemente für die Interaktion mit BuildMaster. Für jeden Schlüssel wird als Wert das entsprechende Objekt eingesetzt.
5.2 Arbeiter
c['workers'] = [worker.Worker("example-worker", "pass")]Dieses Mal geben wir an BuildMaster-eine Liste von SharedWorker-n. Wir SharedWorker haben erstellt , indem wir you-worker-name und passwordangegeben haben. Jetzt müssen wir sie anstelle von example-worker und pass .
5.3 quellen_ändern
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Über den Schlüssel change_source des Wörterbuchs c erhalten wir Zugriff auf die Liste, in die das Objekt eingegeben werden muss, das das Repository mit dem Quellcode des Projekts abfragt. Im Beispiel wird ein Git-Repository verwendet, das regelmäßig abgefragt wird.
Das erste Argument ist der Pfad zu Ihrem Repository.
workdir stellt den Pfad zum Ordner dar, in dem auf der SharedWorker-Seite relativ zum Pfad /home/habr/worker/yourProject/build git die lokale Version des Repositories speichern wird.
branch enthält den spezifischen branch im Repository, dem gefolgt werden soll.
pollInterval enthält die Anzahl der Sekunden, nach denen BuildMaster das Repository auf Änderungen abgefragt wird.
Es gibt mehrere Methoden, um Änderungen im Projekt-Repository zu verfolgen.
Die einfachste Methode ist Polling, was bedeutet, dass BuildMaster periodisch der Server mit dem Repository abgefragt wird. Falls commit Änderungen im Repository festgestellt werden, BuildMaster wird mit einer gewissen Verzögerung ein internes Objekt Change erstellt und an den Ereignis-Handler geschickt Scheduler, der dann die Schritte zum Bauen und Testen des Projekts auf SharedWorker-e auslöst. Zu diesen Schritten gehört ebenfalls Aktualisieren des Repositories. Genau auf SharedWorker-e wird eine lokale Kopie des Repositories erstellt. Die Einzelheiten dieses Prozesses werden im Folgenden in den nächsten beiden Abschnitten erläutert. ( und ).
Eine noch elegantere Methode zur Verfolgung von Änderungen im Repository ist das direkte Senden von Nachrichten vom Server, auf dem es gehostet ist, zu BuildMaster-u über Änderungen im Quellcode des Projekts. In diesem Fall wird, sobald ein Entwickler commit, der Server mit dem Repository des Projekts eine Nachricht an BuildMaster-u senden. Dieser wiederum wird es abfangen und ein Objekt PBChangeSourceerstellen. Dieses Objekt wird dann an Scheduler, das die Schritte zum Bauen und Testen des Projekts aktiviert. Ein wichtiger Teil dieser Methode ist die Arbeit mit Hook-Skripten des Servers im Repository. Im Skript Hook-a, das für die Verarbeitung von Aktionen bei commit-e verantwortlich ist, muss das Utility sendchange und die Netzwerkadresse angeben BuildMaster-a. Es muss auch der Netzwerkport angegeben werden, der abgehört wird PBChangeSource. PBChangeSource, übrigens ist Teil von BuildMaster-a. Diese Methode erfordert Berechtigungen admin-a auf dem Server, wo das Projekt-Repository liegt. Zuvor muss ein Backup des Repositories erstellt werden.
5.4 planer
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 – ist ein Element, das als Auslöser fungiert und die gesamte Kette von Build- und Testprozessen des Projekts startet.
Die Änderungen, die erfasst wurden change_source, wurden während der Verarbeitung umgewandelt BuildBot-a in ein Objekt Change und jetzt erstellt jede Sheduler auf deren Basis Anfragen für den Bauprozess des Projekts. Er bestimmt jedoch auch, wann diese Anfragen weiter in die Warteschlange übergeben werden. Das Objekt Builder speichert die Warteschlange der Anfragen und überwacht den Status des aktuellen Builds auf einem separaten SharedWorker-e. Builder existiert sowohl auf BuildMaster-e als auch auf SharedWorker-e. Es sendet mit BuildMaster-a an SharedWorker-a bereits spezifische build — eine Reihe von Schritten, die ausgeführt werden sollen.
Wir sehen, dass in diesem aktuellen Beispiel solche schedulers 2 Stück erstellt werden. Jede hat ihren eigenen Typ.
SingleBranchScheduler – eine der beliebtesten Zeitpläne. Er überwacht einen Branch und wird durch eine festgelegte Änderung darin ausgelöst. Wenn er Änderungen erkennt, kann er den Versand einer Anfrage zum Bauen verzögern (auf einen Zeitraum, der im speziellen Parameter angegeben ist treeStableTimer). Im name wird der Name des Zeitplans festgelegt, der im BuildBot-Web-Interface angezeigt wird. Im ChangeFilter wird der Filter festgelegt, durch den Änderungen im Branch den Zeitplan dazu auffordern, eine Anfrage zum Bauen zu senden. Im builderNames wird der Name builder-a angegeben, den wir gleich festlegen werden. Der Name in unserem Fall wird identisch mit dem Namen des Projekts sein: yourProject.
ForceScheduler ist eine sehr einfache Angelegenheit. Diese Art von Zeitplan wird durch einen Mausklick über BuildBot-Web-Interface ausgelöst. Die Parameter haben denselben Inhalt wie in SingleBranchScheduler.
P.S. Nr. 3. Könnte nützlich sein
Periodic – das ist ein Zeitplan, der mit einer bestimmten, festgelegten zeitlichen Regelmäßigkeit ausgeführt wird. Der Aufruf sieht ungefähr so aus:
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": "."}))
periodischerBuildTimer legt die Zeit für diese Periodizität in Sekunden fest.
BuildFactory erzeugt eine konkrete build, die dann builder gesendet wird an SharedWorkerIn BuildFactory gibt die Schritte an, die ausgeführt werden sollen SharedWorker-u. Schritte werden durch den Aufruf der Methode addStep
Der erste hinzugefügte Schritt in diesem Beispiel ist git clean -d -f -f –x, dann git checkout. Diese Aktionen sind im Parameter enthalten Methode, der nicht explizit angegeben ist, aber einen Standardwert impliziert fresh. Parameter mode=’incremental’ zeigt an, dass Dateien aus dem Verzeichnis, in das das checkout, dabei nicht im Repository vorhanden, unberührt bleiben.
Der zweite hinzugefügte Schritt ist der Aufruf des Skripts trial mit dem Parameter hello auf der Seite SharedWorker-a aus dem Verzeichnis /home/habr/worker/yourProject/build mit der Umgebungsvariable PATHONPATH=... So können Sie Ihre Skripte schreiben und sie auf der Seite SharedWorker-a über den Schritt util.ShellCommand. Diese Skripte können direkt im Repository abgelegt werden. Dann bei checkout-e gelangen sie in /home/habr/worker/yourProject/build. Allerdings gibt es dabei zwei "aber":
- SharedWorker muss mit dem Schlüssel erzeugt werden, damit es die Ausführungsrechte nicht blockiert. checkout-a.
- Mit git push- Bei diesen Skripten muss das Attribut angegeben werden ausführbar, damit später bei checkout- die Ausführungsrechte des Git-Skripts nicht verloren gehen.
5.6 Erbauer
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Was das ist Builder wurde bereits erklärt . Jetzt werde ich genauer darauf eingehen, wie man es erstellt. BuilderConfig ist ein Konstruktor builder. Solche Konstruktoren können in c[‘builders’] mehrere definiert werden, da dies eine Liste von Objekten ist. builder Lassen Sie uns nun das Beispiel leicht umschreiben, um es näher an unsere Aufgabe zu bringen. BuildBotc['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory))
Jetzt werde ich die Parameter erklären
legt den Namen fest BuilderConfig.
name -a. Hier haben wir ihn genannt builder. Das bedeutet, dass auf yourProject- diesem Pfad erstellt wird SharedWorkerer wird /home/habr/worker/yourProject/build. Sheduler genau nach diesem Namen gesucht. builder workernames
enthält eine Liste -e, wobei jeder in SharedWorkerc[‘workers’] factory.
ist ein konkreter , mit dem er assoziiert ist. buildEr wird ein Objekt senden builderzur Ausführung aller Schritte, die Teil dieses build findet man SharedWorker Hier ist die Architektur des Projektbeispiels, welches ich vorschlage, umzusetzen über build-a.
6. Beispiel einer eigenen Konfiguration
Wir werden SVN als Versionskontrollsystem verwenden. BuildBot
.
Als Versionskontrollsystem verwenden wir svn. Das Repository wird sich in einer Cloud befinden. Hier ist die Adresse dieser Cloud . In der Cloud unter svn gibt es einen Benutzeraccount username: Benutzer, passwd: password. Die Skripte, die die Schritte darstellen build-a werden ebenfalls in der Branch svn, in einem separaten Ordner buildbot/worker_linux. Diese Skripte liegen im Repository mit der gespeicherten Eigenschaft executable.
BuildMaster und SharedWorker arbeiten auf demselben Host project.host .BuildMaster speichert seine Dateien im Ordner /home/habr/master. SharedWorker wird auch unter folgendem Pfad gespeichert /home/habr/worker. Die Kommunikation zwischen den Prozessen BuildMaster-a und SharedWorker-a erfolgt über Port 4000 nach dem Protokoll BuildBot-a, das heißt ‘pb’ Protokoll.
Das Zielprojekt ist vollständig in Python geschrieben. Die Aufgabe ist es, Änderungen nachzuverfolgen, eine ausführbare Datei zu erstellen, Dokumentation zu generieren und Tests durchzuführen. Im Falle eines Fehlers muss allen Entwicklern eine E-Mail gesendet werden, dass es eine nicht erfolgreich durchgeführte Aktion gibt.
Web-Darstellung BuildBot werden wir auf Port 80 für project.host. Apatch ist nicht zwingend erforderlich. Im Lieferumfang der Bibliothek twisted ist bereits ein Webserver enthalten, BuildBot der genutzt wird.
Für die Speicherung von internen Informationen für BuildBot den Parameter sqlite.
Für den Versand von E-Mails wird ein Host benötigt smtp.your.domain — dort ist der Versand von E-Mails von projectHost@your.domain ohne Authentifizierung erlaubt. Auch auf dem Host ‘smtp ‘ wird das Protokoll auf Port 1025 überwacht.
Im Prozess sind zwei Personen beteiligt: admin und Benutzer. admin verwaltet BuildBot. user ist die Person, die handelt commit-e.
Die ausführbare Datei wird über pyinstallergeneriert. Die Dokumentation wird über doxygen.
generiert. Für diese Architektur habe ich Folgendes geschrieben: 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>Status des erstellen Releases: {{ summary }}</h4>
<p>Verwendeter Dienst für das Erstellen: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Um die Verwaltungsoberfläche zu sehen, folgen Sie diesem Link: {{ buildbot_url }}</p>
<p>Um das Ergebnis des Builds anzusehen, folgen Sie diesem Link: {{ build_url }}</p>
<p>Mit WinSCP können Sie sich mit dem Server unter ip:xxx.xx.xxx.xx verbinden. Melden Sie sich mit habr/password an, um die erstellte executable Datei aus dem Verzeichnis ~/worker/yourProject/build/dist abzurufen.</p>
<p><b>Der Build wurde über Buildbot durchgeführt.</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'] = "Der Prozess des Bauens"
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"
}
Zunächst müssen Sie BuildMaster-a und SharedWorker-a. Dann fügen Sie diese Datei ein. master.cfg in /home/habr/master.
Der nächste Schritt besteht darin, den Dienst zu starten BuildMaster-
sudo buildbot start /home/habr/master
Dann starten Sie den Dienst SharedWorker-a
buildbot-worker start /home/habr/worker
Fertig! Jetzt Buildbot wird Änderungen verfolgen und auslösen bei commit-e in svn, während Schritte zum Bauen und Testen des Projekts mit der oben genannten Architektur ausgeführt werden.
Im Folgenden werde ich einige Besonderheiten der oben genannten master.cfg.
6.1 Auf dem Weg zu master.cfg
Beim Schreiben meines master.cfg werden einige Fehler auftreten, daher ist das Lesen der Protokolldatei erforderlich. Sie wird sowohl auf BuildMaster-e mit absolutem Pfad /home/habr/master/twistd.log, als auch auf der Seite SharedWorker-a mit absolutem Pfad /home/habr/worker/twistd.loggespeichert. Beim Lesen des Fehlers und dessen Behebung ist es erforderlich, den Dienst neu zu starten BuildMaster-a. So wird es gemacht:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Arbeiten mit 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)
Schauen wir uns zunächst svn_poller. Es handelt sich um die gleiche Schnittstelle, die regelmäßig einmal pro Minute das Repository abfragt. In diesem Fall svn_poller greift nur auf den Branch ’”. Der geheimnisvolle Parameter split_file=util.svn.split_file_alwaystrunk bestimmt die Regeln, wie die Ordnerstruktur svn in Branches aufgeteilt wird. Er bietet relative Pfade an. Im Gegenzug split_file_alwaystrunk vereinfacht den Prozess, indem er angibt, dass im Repository nur ’”.
In Schedulers angegeben wird ChangeFilter, der sieht None und damit den Branch ’” über die festgelegte Zuordnung split_file_alwaystrunk. Reagiert auf Änderungen in ’”, startet er builder c mit dem Namen yourProject.
properties dient dazu, dass der Administrator Informationen über die Ergebnisse der Build- und Testprozesse erhält, so wie es der Prozessinhaber verlangt.
Schritt build-a checkout kann alle Dateien vollständig löschen, die sich in der lokalen Version des Repositories befinden. SharedWorker-a. Und dann ein vollständiges svn update. Der Modus wird über den Parameter mode=full, method=fresh. Parameter haltOnTailure zeigt an, dass wenn svn update ein Fehler auftritt, der gesamte Build- und Testprozess angehalten werden sollte, da weitere Schritte keinen Sinn ergeben.
6.3 Sie haben Post: reporters sind bevollmächtigt zu erklären
reporters sind Dienste zum Versenden von Benachrichtigungen per E-Mail.
template_html=u'''
<h4>Status des erstellen Releases: {{ summary }}</h4>
<p>Verwendeter Dienst für das Erstellen: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Um die Verwaltungsoberfläche zu sehen, folgen Sie diesem Link: {{ buildbot_url }}</p>
<p>Um das Ergebnis des Builds anzusehen, folgen Sie diesem Link: {{ build_url }}</p>
<p>Mit WinSCP können Sie sich mit dem Server unter ip:xxx.xx.xxx.xx verbinden. Melden Sie sich mit habr/password an, um die erstellte executable Datei aus dem Verzeichnis ~/worker/yourProject/build/dist abzurufen.</p>
<p><b>Der Build wurde über Buildbot durchgeführt.</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]
Er kann Nachrichten .
MailNotifier verwendet E-Mail für die Versendung von Benachrichtigungen.
template_html legt die Textvorlage für die Benachrichtigungen fest. Für das Layout wird HTML verwendet. Es wird durch die Engine modifiziert, (vergleichen mit django). BuildBot hat eine Sammlung von Variablen, deren Werte während der Erstellung der Nachrichteninhalte in die Vorlage eingefügt werden. Diese Variablen sind in {{ doppelten geschweiften Klammern }} eingeschlossen. Zum Beispiel, Zusammenfassung zeigt den Status der durchgeführten Operationen an, also success oder failure. Und projects wird ausgegeben. yourProjectSo können durch Steuerbefehle in jinja2, Variablen BuildBot- und Formatierungsressourcen in Python können eine durchaus informative Nachricht erstellen.
MailNotifier enthält die folgenden Argumente.
fromaddr – die Adresse, von der aus die Newsletter versendet wird.
sendToInterestedUsers=True sendet die Nachricht an den Eigentümer und den Benutzer, der commit.
lookup — das Suffix, das zu den Benutzernamen hinzugefügt werden soll, die den Newsletter erhalten. So admin wird der Benutzer den Newsletter an die Adresse admin@your.domain erhalten.
relayhost gibt den Namen des Hosts an, auf dem der Server geöffnet ist smtp, a smptPort gibt die Portnummer an, die abgehört wird smtp Server.
mode=«warning» besagt, dass der Newsletter nur versendet werden soll, wenn mindestens ein Schritt build– der mit dem Status failure oder warning abgeschlossen ist. Bei success ist kein Versand erforderlich.
extraRecipients enthält eine Liste von Personen, an die der Newsletter zusätzlich zum Eigentümer und dem Ausführenden gesendet werden soll. commit.
messageFormatter ist ein Objekt, das das Nachrichtenformat, dessen Vorlage und die verfügbaren Variablen aus definiert. jinja2Solche Parameter wie wantProperties=True und wantSteps=True legen diese Menge verfügbarer Variablen fest.
s[‘services’]=[sendMessageToAll] stellt die Liste von Services bereit, unter denen sich auch unser reporter.
Wir haben es geschafft! Herzlichen Glückwunsch
Wir haben eine eigene Konfiguration erstellt und die Funktionen gesehen, die sie bieten kann. BuildBotDas sollte ausreichen, um zu verstehen, ob dieses Tool für die Entwicklung Ihres Projekts erforderlich ist. Ist es für Sie interessant? Wird es Ihnen nützlich sein? Lässt es sich gut bedienen? Dann habe ich diesen Artikel nicht umsonst geschrieben.
Und noch etwas. Ich würde mir wünschen, dass die professionelle Gemeinschaft, die [Tool-Name] benutzt, wächst, dass Handbücher übersetzt werden und dass es noch mehr Beispiele gibt. BuildBotVielen Dank für Ihre Aufmerksamkeit. Viel Erfolg.
(Image by Computerizer from Pixabay) Hallo! Ich heiße Evgeny Cherkin, ich bin Programmierer im Entwicklungsteam des Bergbauunternehmens Polymetal. Wenn man mit einem größeren Projekt beginnt, denkt man nach: 'Welche Software sollte man für dessen Betreuung verwenden?'. Ein IT-Projekt durchläuft vor der Veröffentlichung einer neuen Version mehrere Phasen. Es ist vorteilhaft, wenn die Abfolge dieser Schritte automatisiert ist. Der automatisierte Prozess der Veröffentlichung einer neuen Version allein ist nicht genug.
Quelle: habr.com
