(Bild von from
Hallo!
Mein Name ist Eugeni Tscherkin, ich bin Programmierer im Team von Entwicklern in einem Bergbauunternehmen Polymetal.
Wenn man mit einem großen Projekt beginnt, fragt man sich: „Welche Software eignet sich am besten für deren Verwaltung?“. Ein IT-Projekt durchläuft vor der Veröffentlichung einer neuen Version eine Reihe von Phasen. Es ist von Vorteil, wenn dieser Prozess automatisiert ist. Der automatisierte Prozess zur Veröffentlichung einer neuen Version eines IT-Projekts wird Kontinuierliche Integration. BuildBot eine gute Unterstützung, die diesen Prozess umsetzt.
In diesem Artikel möchte ich einen Überblick über die Möglichkeiten BuildBot. Was kann diese Software? Wie nähert man sich ihr und wie gestaltet man eine normale EFFIZIENTE ARBEITSBEZIEHUNG? Unsere Erfahrungen können Sie auf Ihrem eigenen System anwenden, indem Sie einen funktionierenden Build- und Testdienst für Ihr Projekt auf Ihrem Rechner erstellen.
Inhalt
Inhalt
1. Warum BuildBot?
Früher habe ich auf habr-e Artikel über die Implementierung gesehen Kontinuierliche Integration unter Verwendung von BuildBot. Zum Beispiel, schien mir am informativsten. Es gibt ein weiteres Beispiel - . Diese Artikel können ergänzt werden mit , und nebenbei, in englischer Sprache. Zusammen ergeben sie einen guten Ausgangspunkt. Nach dem Lesen dieser Artikel möchten Sie sicherlich sofort etwas auf BuildBot machen.
Halt! Hat jemand es überhaupt in seinen Projekten verwendet? Es stellte sich heraus, ja, haben es in ihren Aufgaben angewendet. Man kann es finden die Nutzung BuildBot auch in den Codearchiven von Google.
Was ist also die Logik der Nutzer von Buildbot? Ведь есть другие инструменты: CruiseControl und Jenkins. Ich antworte so: für die meisten Aufgaben Jenkins wird es tatsächlich genug sein. Im Gegenzug BuildBot ist er anpassungsfähiger, wobei die Aufgaben dort ebenso einfach gelöst werden wie in Jenkins. Es liegt an Ihnen, zu wählen. Aber da wir nach einem Werkzeug für ein sich entwickelndes Zielprojekt suchen, warum nicht das wählen, das es ermöglicht, aus einfachen Schritten ein Build-System zu erhalten, das Interaktivität und ein einzigartiges Interface bietet.
Bei denen, deren Zielprojekt in Python geschrieben ist, stellt sich die Frage: „Warum nicht ein Integrationssystem wählen, das eine verständliche Schnittstelle in Bezug auf die im Projekt verwendete Sprache bietet?“ Es ist an der Zeit, die Vorteile vorzustellen. BuildBot.
Also, unser „Instrumentenquartett“. Ich habe für mich selbst eine Gruppe von vier Merkmalen definiert. BuildBot:
- Das ist ein Open-Source-Framework unter der GPL-Lizenz.
- Es ist die Nutzung von Python als Konfigurations- und Beschreibungstool für die erforderlichen Aktionen.
- Es bietet die Möglichkeit, eine Antwort von der Maschine zu erhalten, auf der die Erstellung stattfindet.
- Es gibt schließlich minimale Anforderungen an den Host. Um es einzurichten, sind Python und Twisted erforderlich, und es sind keine virtuelle Maschine oder Java-Maschine nötig.
2. Konzept unter der Leitung von BuildMaster
Zentral in der Architektur der Aufgabenverteilung steht BuildMaster. Er stellt einen Dienst dar, der:
- Änderungen im Quellbaum des Projekts überwacht. Befehle sendet, die der Worker-Dienst zur Erstellung und Testung des Projekts auszuführen hat.
- die Benutzer über die Ergebnisse der ausgeführten Aktionen informiert. über eine Datei konfiguriert wird
- . Diese Datei befindet sich im Stammverzeichnis . Später zeige ich, wie dieses Stammverzeichnis erstellt wird. Die Datei selbst
BuildMaster beinhaltet ein Python-Skript, das Aufrufe verwendet. master.cfgDer nächstwichtigere Objekt BuildMasterträgt den Namen master.cfg . Dieser Dienst kann auf einem anderen Host mit einem anderen Betriebssystem oder auf dem gleichen, wo BuildBot.
bestehen. Er kann auch in einer speziell vorbereiteten virtuellen Umgebung mit eigenen Paketen und Variablen existieren. Diese virtuellen Umgebungen können mithilfe von Python-Utilities wie BuildBot virtualenv, venv Arbeiterbefehle an jeden BuildMaster- senden, und dieser führt sie dann aus. Das heißt, der Prozess der Erstellung und Testung des Projekts kann auf - unter Windows und auf einem anderen Worker unter Linux durchgeführt werden..
BuildMaster Checkouts Arbeiterder Quellcodes des Projekts erfolgt auf jedem Arbeiter-.
Also, lass uns beginnen. Als Host werde ich Ubuntu 18.04 verwenden. Darauf werde ich einen - und einen Arbeiter- platzieren. Zunächst müssen wir Python 3.7 installieren:
3. Installation
sudo apt-get update sudo apt-get install python3.7 BuildMasterFür diejenigen, die Python 3.7.2 anstelle von 3.7.1 benötigen, können Sie Folgendes tun: Arbeitersudo 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
Als nächster Schritt installieren wir
Twisted
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
Als Nächstes installieren wir Twited und BuildBot, und auch Pakete, die zusätzliche Funktionen aktivieren können, 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. Er wird in unserem Ordner sein /home/habr/master.
mkdir master
buildbot create-master master # Hier erstellen wir es tatsächlichDer nächste Schritt. Erstellen wir Arbeiter. Er wird in unserem Ordner sein /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Wenn Sie Arbeiter, wird standardmäßig in /home/habr/worker ein Ordner mit dem Namen des Projekts, das in master.cfgangegeben ist, erstellt. Und im Ordner mit dem Namen des Projekts wird er ein Verzeichnis erstellen build, in das dann checkout. Das Arbeitsverzeichnis für Arbeiter-a wird das Verzeichnis /home/habr/yourProject/build.
„Goldener“ Schlüssel
Und jetzt das, weshalb ich den vorherigen Absatz geschrieben habe: Ein Skript, das Master von Arbeiter-a verlangt, dies in diesem Verzeichnis auszuführen, wird nicht ausgeführt, da das Skript keine Berechtigung zum Ausführen hat. Um die Situation zu beheben, benötigen wir den Schlüssel —umask=0o22, der die Schreibberechtigung für dieses Verzeichnis verweigert, aber die Ausführungsberechtigungen lässt. Das brauchen wir nur.
BuildMaster und Arbeiter stellen eine Verbindung zueinander her. Manchmal wird sie unterbrochen und Arbeiter 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 da, um die Zeit anzugeben, nach der connect neu gestartet wird.
5. Konfiguration. Schritt-für-Schritt-Rezept
Konfiguration BuildMaster wird auf der Maschine durchgeführt, auf der wir den Befehl create-masterausgeführt haben. In unserem Fall ist das das Verzeichnis /home/habr/master. Die Konfigurationsdatei master.cfg existiert noch nicht, aber der Befehl hat bereits die Datei master.cmg.sampleerstellt. Sie müssen sie in master.cfg.sample in master.cfg
mv master.cfg.sample master.cfgÖffnen wir diese master.cfg. Und analysieren wir, 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 — Basis Wörterbuch der Konfigurationsdatei. Es muss unbedingt in der Konfigurationsdatei verwendet werden. Zur besseren Handhabung im Konfigurationscode wird ein Alias eingeführt. „c“client/ in c[«keyFromDist»] sind feste Elemente für die Interaktion mit BuildMaster. Zu jedem Schlüssel wird als Wert das entsprechende Objekt eingefügt.
5.2 workers
c['workers'] = [worker.Worker("example-worker", "pass")]Diesmal geben wir an BuildMaster- eine Liste von Arbeiter-en. Der Arbeiter wir erstellt haben , indem wir you-worker-name und passwort. Jetzt müssen wir sie anstelle von example-worker und 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))
Über den Schlüssel change_source des Wörterbuchs c greifen wir auf die Liste zu, in die das Objekt, das das Repository mit dem Quellcode des Projekts befragen soll, eingefügt werden muss. Im Beispiel wird ein Git-Repository verwendet, das in bestimmten Zeitabständen befragt wird.
Das erste Argument ist der Pfad zu Ihrem Repository.
workdir stellt den Pfad zum Ordner dar, der auf der Arbeiter-ebene relativ zum Pfad /home/habr/worker/yourProject/build von Git die lokale Version des Repositories speichert.
branch enthält den spezifischen Branch im Repository, dem gefolgt werden soll.
pollInterval gibt die Anzahl der Sekunden an, nach deren Ablauf BuildMaster das Repository auf Änderungen befragt werden soll.
Es gibt mehrere Methoden, um Änderungen im Repository des Projekts zu verfolgen.
Die einfachste Methode ist die Abfrage, die impliziert, dass BuildMaster periodisch den Server mit dem Repository ab. Falls commit Änderungen im Repository vorgenommen wurden, dann BuildMaster wird mit einer gewissen Verzögerung ein internes Objekt Change erstellt und an den Ereignishandler gesendet Scheduler, der dann die Schritte zum Bauen und Testen des Projekts anstößt auf Arbeiter-e. Unter diesen Schritten wird angegeben update des Repositorys. Genau auf Arbeiter-e wird eine lokale Kopie des Repositorys erstellt. Einzelheiten zu diesem Prozess 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 wird, an BuildMaster-u über die Änderung des Quellcodes des Projekts. In diesem Fall wird, sobald der Entwickler etwas ändert, der Server mit dem Repository des Projekts eine Nachricht senden commit-u. Dieser wird die Nachricht dann abfangen und ein Objekt erstellen BuildMasterPBChangeSource . Anschließend wird dieses Objekt an, das die Schritte zum Bauen des Projekts und zu dessen Testen aktiviert. Ein wichtiger Teil dieser Methode ist die Arbeit mit Scheduler-Skripten des Servers im Repository. Im Skript hook-a, das für die Verarbeitung von Aktionen bei hook-e zuständig ist, muss das Utility commitsendchange aufgerufen werden und die Netzwerkadresse angegeben werden -a. Auch der Netzwerkport, der auf BuildMaster, by the way, Teil von . Anschließend wird dieses Objekt an. . Anschließend wird dieses Objekt an-a. Diese Methode erfordert Rechte BuildMaster-a auf dem Server, wo sich das Repository des Projekts befindet. Zuvor muss ein Backup des Repositorys erstellt werden. adminc['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"]))
5.4 shedulers
schedulers
– ist ein Element, das den Trigger bildet, der die gesamte Kette des Bauens und Testens des Projekts auslöst. Die Änderungen, die erfasst wurden
, wurden im Laufe der Arbeit change_source-a in ein Objekt BuildBotumgewandelt und jetzt erstellt jedes Change Sheduler auf dessen Grundlage Anfragen zum Startprozess des Projekts. Allerdings bestimmt er auch, wann diese Anfragen weiter in die Warteschlange übergeben werden. Das Objekt Builder hält eine Warteschlange von Anfragen und verfolgt den Status des aktuellen Builds auf einem separaten -e. Arbeiterexistiert sowohl auf hält eine Warteschlange von Anfragen und verfolgt den Status des aktuellen Builds auf einem separaten -e als auch auf BuildMaster-e. Es sendet auch von Arbeiter-a an BuildMaster-a bereits spezifische Arbeiter— eine Reihe von Schritten, die ausgeführt werden sollen. build Wir sehen, dass im aktuellen Beispiel solche
2 Stück erzeugt werden. Jede hat ihren eigenen Typ. – ist ein Element, das den Trigger bildet, der die gesamte Kette des Bauens und Testens des Projekts auslöst. SingleBranchScheduler
SingleBranchScheduler – eine der beliebtesten Zeitpläne. Es überwacht einen Zweig und wird bei einer festgestellten Änderung in diesem aktiv. Wenn es Änderungen sieht, kann es die Anfrage zum Erstellen verzögern (verzögern um den in dem speziellen Parameter angegebenen Zeitraum) treeStableTimer). In name wird der Name des Zeitplans angegeben, der im BuildBot-Web-Interface angezeigt wird. In ChangeFilter wird ein Filter festgelegt, bei dem Änderungen im Zweig den Zeitplan veranlassen, eine Anfrage zum Erstellen zu senden. In builderNames wird der Name builder-a angegeben, den wir etwas später festlegen werden. Der Name wird in unserem Fall derselbe sein wie der Name des Projekts: yourProject.
ForceScheduler ist eine ziemlich einfache Sache. Diese Art von Zeitplan wird durch einen Mausklick über BuildBot-Web-Interface aktiviert. Die Parameter haben dieselbe Bedeutung wie in SingleBranchScheduler.
P.S. Nr. 3. Könnte nützlich sein
Periodic – ist ein Zeitplan, der mit einer bestimmten, festgelegten zeitlichen Periodizität ausgelöst wird. Ein Aufruf sieht etwa 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": "."}))
periodicBuildTimer legt die Zeitdauer dieser Periodizität in Sekunden fest.
BuildFactory erstellt ein konkretes build, das später builder an das Arbeiter. In BuildFactory schickt, in dem die Schritte angegeben sind, die ausgeführt werden sollen Arbeiter-a. Die Schritte werden durch den Aufruf der Methode addStep
hinzugefügt. Der erste hinzugefügte Schritt in diesem Beispiel ist git clean -d -f -f –x, dann git checkout. Diese Aktionen sind im Parameter methodfestgelegt, der nicht explizit angegeben ist, aber den Standardwert fresh. Der Parameter mode='incremental' zeigt an, dass Dateien aus dem Verzeichnis, in das der checkoutdurchgeführt wird, dabei nicht im Repository vorhandene Dateien unbeeinflusst bleiben.
Der zweite hinzugefügte Schritt ist der Aufruf des Skripts trial mit Parameter hello auf der Seite Arbeiter-a aus dem Verzeichnis /home/habr/worker/yourProject/build c mit der Umgebungsvariable PATHONPATH=… So können Sie Ihre Skripte schreiben und auf der Seite Arbeiter-a über den Schritt util.ShellCommandausführen. Diese Skripte können direkt im Repository abgelegt werden. Dann werden sie bei checkout-a in das /home/habr/worker/yourProject/buildeingefügt. Es gibt jedoch zwei „Aber“:
- Arbeiter muss mit dem Schlüssel erstellt werden, damit er nach checkout-a.
- Bei git push-a diese Skripte keine Ausführungsrechte blockiert. Nach müssen Sie die Eigenschaftexecutable checkoutangeben, damit beim -a die Ausführungsrechte des Skripts nicht verloren gehen.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Was ist hält eine Warteschlange von Anfragen und verfolgt den Status des aktuellen Builds auf einem separaten wurde erzählt . Jetzt erzähle ich ausführlicher, wie man es erstellt. BuilderConfig ist ein Konstruktor builder. Solche Konstruktoren in c[‘builders’] kann man mehrere angeben, da es sich um eine Liste von Objekten handelt builder . Jetzt schreiben wir das Beispiel etwas um BuildBot, sodass es näher an unserer Aufgabe ist.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Jetzt erzähle ich von den Parametern BuilderConfig.
name bestimmt den Namen builder-a. Hier haben wir ihn genannt yourProject. Das bedeutet, dass auf Arbeiter-e dieser spezifische Pfad erstellt wird /home/habr/worker/yourProject/build. auf dessen Grundlage Anfragen zum Startprozess des Projekts. Allerdings bestimmt er auch, wann diese Anfragen weiter in die Warteschlange übergeben werden. Das Objekt findet builder gerade nach diesem Namen.
workernames beinhaltet eine Liste Arbeiter-en. Jeder von ihnen muss hinzugefügt werden zu c[‘workers’].
factory — konkret build, mit dem es assoziiert ist builder. Es wird ein Objekt senden build auf Arbeiter um alle Schritte auszuführen, die Bestandteil dieses build-a.
6. Beispiel einer eigenen Konfiguration
Hier ist die Architektur des Beispielprojekts, das ich vorschlage umzusetzen BuildBot
.
Als Versionskontrollsystem werden wir svnverwenden. Das Repository wird in einer Art Cloud sein. Hier ist die Adresse dieser Cloud . In der Cloud unter svn gibt es ein Benutzerkonto username: Benutzer, passwd: passwort. Die Skripte, die Schritte darstellen build-a werden ebenfalls im Branch liegen svn, in einem separaten Ordner buildbot/worker_linux. Diese Skripte liegen im Repository mit der gespeicherten Eigenschaft executable.
BuildMaster und Arbeiter arbeiten auf einem Host project.host .BuildMaster speichert seine Dateien im Ordner /home/habr/master. Arbeiter speichert auch unter folgendem Pfad /home/habr/worker. Die Kommunikation zwischen den Prozessen BuildMaster-a und Arbeiter-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, seine Änderungen zu verfolgen, eine ausführbare Datei zu erstellen, Dokumentation zu generieren und Tests durchzuführen. Im Falle eines Fehlers müssen alle Entwickler eine E-Mail erhalten, in der sie über das fehlgeschlagene Ereignis informiert werden.
Die Webdarstellung BuildBot werden wir auf Port 80 für project.host. Apatch muss nicht installiert werden. In der Bibliothek twisted ist bereits ein Webserver enthalten, BuildBot den er verwendet.
Für die Speicherung von Informationen für interne Zwecke werden wir BuildBot verwenden sqlite.
Für den E-Mail-Versand wird ein Host benötigt smtp.your.domain — auf dem ist der Versand von E-Mails unter der Adresse projectHost@your.domain ohne Authentifizierung erlaubt. Zudem wird auf dem Host ‘smtp ‘ das Protokoll auf Port 1025 angehört.
An dem Prozess sind zwei Personen beteiligt: admin und Benutzer. der Admin verwaltet BuildBot. der Benutzer ist die Person, die durchführt commit-en.
Die ausführbare Datei wird über pyinstallergeneriert. Die Dokumentation wird über doxygen.
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 erstellten Releases: {{ summary }}</h4>
<p>Verwendeter Dienst zur Erstellung: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Um die Verwaltungsoberfläche zu sehen, besuchen Sie den Link: {{ buildbot_url }}</p>
<p>Um das Ergebnis des Builds zu sehen, besuchen Sie den 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 ausführbare Datei aus dem Verzeichnis ~/worker/yourProject/build/dist abzuholen.</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 Bauprozess"
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 Arbeiter-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-a
sudo buildbot start /home/habr/master
Dann starten Sie den Dienst Arbeiter-a
buildbot-worker start /home/habr/worker
Fertig! Jetzt Buildbot wird Änderungen überwachen und auf commit-u reagieren svn, während es die Schritte zum Erstellen und Testen des Projekts mit der oben genannten Architektur ausführt.
Im Folgenden werde ich einige Besonderheiten der oben genannten master.cfg.
6.1 Auf dem Weg zu meinem master.cfg
Beim Schreiben Ihres master.cfg werden viele Fehler auftreten, daher wird das Lesen der Protokolldatei erforderlich sein. Sie wird sowohl unter BuildMaster-e c mit absolutem Pfad /home/habr/master/twistd.log, als auch auf der Seite Arbeiter-a mit absolutem Pfad /home/habr/worker/twistd.log. Bei der Lektüre der Fehler und deren Behebung ist es notwendig, den Dienst neu zu starten BuildMaster-a. So wird das 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)
Zunächst schauen wir uns svn_polleran. Es ist dasselbe Interface, das das Repository einmal pro Minute abfragt. In diesem Fall svn_poller greift nur auf den Branch trunk. Der mysteriöse Parameter split_file=util.svn.split_file_alwaystrunk legt die Regeln fest, wie die Verzeichnisstruktur svn in Branches aufgeteilt wird. Er bietet ihnen auch relative Pfade an. Im Gegenzug split_file_alwaystrunk erleichtert den Prozess, indem es sagt, dass im Repository nur trunk.
Im Scheduler angegeben ChangeFilter, der sieht None und damit einen Branch verknüpft trunk durch die angegebene Assoziation über split_file_alwaystrunk. Reagiert auf Änderungen in trunk, startet builder c mit dem Namen yourProject.
properties wird hier benötigt, damit der Admin Ergebnisse über den Build- und Testprozess als Eigentümer des Prozesses erhält.
Schritt build-a checkout ist in der Lage, alle Dateien in der lokalen Version des Repositorys vollständig zu löschen Arbeiter-a. Und dann ein vollständiges svn update. Der Modus wird über den Parameter mode=full, method=fresh. Der Parameter haltOnFailure zeigt an, dass wenn svn update wird mit einem Fehler ausgeführt, sollte der gesamte Prozess des Bauens und Testens ausgesetzt werden, da weitere Aktionen keinen Sinn machen.
6.3 Sie haben Post: reporters ist befugt zu verkünden
Reporter ist ein Benachrichtigungsdienst per E-Mail.
template_html=u'''
<h4>Status des erstellten Releases: {{ summary }}</h4>
<p>Verwendeter Dienst zur Erstellung: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Um die Verwaltungsoberfläche zu sehen, besuchen Sie den Link: {{ buildbot_url }}</p>
<p>Um das Ergebnis des Builds zu sehen, besuchen Sie den 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 ausführbare Datei aus dem Verzeichnis ~/worker/yourProject/build/dist abzuholen.</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 den Versand von Benachrichtigungen.
template_html legt die Textvorlage für den Versand fest. Für die Gestaltung wird HTML verwendet. Es wird durch die Engine modifiziert (man kann es mit django). BuildBot vergleichen). Diese hat eine Reihe von Variablen, deren Werte im Prozess der Erstellung des Nachrichtentextes in die Vorlage eingefügt werden. Diese Variablen sind in {{ doppelten geschweiften Klammern }} eingefügt. So gibt beispielsweise summary den Status der durchgeführten Operationen aus, also Erfolg oder Fehlgeschlagen. Und projects gibt aus. yourProjectSo kann man mit Steuerbefehlen in jinja2, Variablen BuildBot-a und Python-Zeichenfolgenformatierung eine durchaus informative Nachricht erstellen.
MailNotifier enthält folgende Argumente.
fromaddr – die Adresse, von der aus die Benachrichtigungen versendet werden.
sendToInterestedUsers=True sendet die Nachricht an den Eigentümer und den Benutzer, der die commit.
lookup – ein Suffix, das an die Namen der Benutzer angehängt werden muss, die die Benachrichtigung erhalten. So admin wird der Benutzer die Benachrichtigung an die Adresse admin@your.domain erhalten.
relayhost gibt den Hostnamen an, auf dem der Server geöffnet ist smtp, a smptPort gibt die Portnummer an, die hört smtp Server.
mode=«warning» bedeutet, dass die Benachrichtigung nur gemacht werden soll, wenn mindestens ein Schritt build-a mit dem Status fehlgeschlagen oder Warnung abgeschlossen wurde. Im Falle von Erfolg ist kein Versand erforderlich.
extraRecipients enthält eine Liste von Personen, an die die Benachrichtigung zusätzlich zum Eigentümer und demjenigen, der die commit.
messageFormatter ist ein Objekt, das das Nachrichtenschema, seine Vorlage und eine Reihe von Variablen definiert, die aus jinja2. Solche Parameter wie wantProperties=True und wantSteps=True legen diese Zusammenstellung von verfügbaren Variablen fest.
s[‘services’]=[sendMessageToAll] stellt eine Liste von Diensten zur Verfügung, zu denen unser Reporter.
Wir haben es geschafft! Meine Glückwünsche
Wir haben eine eigene Konfiguration erstellt und die Funktionalität gesehen, die BuildBotbietet. Ich denke, das reicht aus, um zu verstehen, ob dieses Werkzeug für Ihr Projekt benötigt wird. Ist es für Sie interessant? Wird es Ihnen nützlich sein? Ist es einfach zu bedienen? Wenn ja, dann schreibe ich diesen Artikel nicht umsonst.
Und noch etwas. Ich würde mir wünschen, dass die berufliche Gemeinschaft, die BuildBotverwendet, größer wird, Handbücher übersetzt werden und es noch mehr Beispiele gibt.
Vielen Dank für Ihre Aufmerksamkeit. Viel Glück.
Quelle: habr.com
