Moin,
Zuerst vielen Dank für die konstruktive Runde zur Entwicklung der
Architektur, des Build- und Deployment-Prozesses von xRes.
Anbei sende ich Euch das Tafelbild und die wesentlichen Punkte der
Besprechung.
Grundlage des Gespräches waren
* die Konzeption von VBE zur Modularisierung von xRes in "packages"
(letztes Entwickler-Meeting) und
* OHO zur Integration des Composers in den Build-Prozess (siehe
PullRequest in dieser Woche).
Anforderungen einen xRes-Build-und-Deployment-Prozess:
* Wir möchten weiterhin eine Trennung zwischen Build- und Deployment
aufrecht erhalten. Die Speicherung von "Artefakten" nach einem
Build-Prozess einschließlich Qualitätsprüfung (z.B. UnitTests) wird
als Vorteil gesehen.
* Wir möchten xRes in Zukunft nicht mehr kundenspezifisch bauen,
sondern EINE gemeinsame xRes-Version bauen und ausrollen. Alle
kundenspezifischen Daten (aktuell: PDF-Dateien, favicons,
htaccess-Files) sollen in Zukunft über das Config-Deployment (wie
auch Cron-Jobs) ausgerollt und vom xRes aus /var/xres/... geladen
werden. Der Build-Prozess wird damit circa um Faktor 6-8 schneller
werden (der Durchlauf der UnitTests wird nicht analog beschleunigt).
* Wie möchten weiterhin alle externen Abhängigkeiten in unseren
git-Repositories spiegeln und damit die Kontrolle über Versionen,
Erreichbarkeit usw. behalten.
Probleme:
* Die bereits diskutierte Idee der Modularisierung von xRes in
"packages" beinhaltet, viele Code-Bestandteile in jeweils eigene
git-Repositories auszulagern. Das Durchspielen des Workflows zeigte
uns jedoch, dass wir dann für EINE Software-Änderung (im Sinne eines
JIRA-Tickets) evtl. viele PullRequests abzugeben hätten, die NUR
ZUSAMMEN in ein Release gemerged werden dürften. Dies erscheint
aktuell eine deutliche Verkomplizierung unserer Arbeit mit
PullRequests zu sein. Auch Ansätze über git-Tags und Versionierung
aus Branch-Namen heraus haben uns bisher nicht zum Ziel führen können.
* Eine weitere Komplexität, die aus oben genannter Aufspaltung zu
folgen scheint, betrifft das System der Abhängigkeiten: Die
Zuordnung der Abhängigkeit einer Applikation / eines Paketes von
einem anderen Paket soll einerseits von uns Entwicklern aktiv und
gezielt gesteuert werden können => muss aber auf der anderen Seite
mit der Übernahme einer Änderung in eine Release-Version automatisch
oder manuell aktualisiert werden. Wir haben darauf hingewiesen, dass
Builds von testing-Branches oder Verschachtelung von
Sub-Abhängigkeiten diese Steuerung sehr komplex werden lassen.
* Eine Auslagerung von Softwarebestandteilen in viele kleine
git-Repositories erschwert die Aufgabe, einem Build-System einen
Trigger für das Anstoßen eines Build-Prozesses zu geben. Es kann
dazu kommen, dass ein BugFix nur in einem "package" erfolgt und
damit evtl. der Trigger für den Build-Prozess nicht greift. Die
Idee, einen Build durch die Aktualisierung einer zentralen
composer.json zu erzwingen, stellt uns vor Versionsnummern-Konflikte
(wie aktuell bei DB-Migrations).
* Die Modularisierung von xRes in "packages" kann verstanden werden
sowohl als "Kapselung in wiederverwendbares Bibliotheken", als auch
als vollständige Auspaltung in "bundles". Eine Entscheidung darüber
haben wir nicht getroffen, diese "Strategie" sollte aber vor einem
evtl. Umbau einheitlich verstanden sein.
Ideen:
* Das Qualitätsmanagement könnte in Zukunft über einen zentralen
CI-Server erfolgen. Dieser merkt alle Änderungen in
git-Remote-Branches und führt darauf automatisch ein
Qualitätsmanagement aus.
Weiteres Vorgehen:
* Für kommenden Freitag lade ich erneut zu einem Meeting ein, in
welchem wir die Besprechung fortsetzen werden.
* Bis zu diesem Meeting sind alle Entwickler aufgefordert, Ideen
für/gegen oben stehende Probleme zu sammeln. Im Meeting wurde
bereits vorgeschlagen,
o zusätzliche Werkzeuge einzusetzen oder
o die Idee zur Modularisierung von xRes mit Packages anzupassen oder
o unsere aktuellen xRes-Workflows anzupassen oder
o die Modularisierung / Strukturierung von xRes evtl. oder
zusätzlich per Namespaces vorzunehmen.
* Im xRes-Code liegen zum Teil kundenspezifische Daten. Diese sollten
bitte in das build_customer_config überführt werden, damit sie in
Kürze über das "xres-config" Deployment nach /var/xres/ mirgiert und
ausgerollt werden können.
VG SRK
--
Mit freundlichen Grüßen
Stefan Rank-Kunitz
- Lead Developer -
________________________________________________________
TraSo GmbH
Georg-Schumann-Str. 294
D-04159 Leipzig
Tel.: +49 341 355 740 - 43
E-Mail: s.rank-kunitz(a)traso.de
________________________________________________________
Handelsregister: Amtsgericht Leipzig, HRB 21850
