Am 27. Mai 2016 16:59:28 MESZ, schrieb Stefan Rank-Kunitz <s.rank-kunitz@traso.de>:

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,
• zusätzliche Werkzeuge einzusetzen oder
• die Idee zur Modularisierung von xRes mit Packages anzupassen oder
• unsere aktuellen xRes-Workflows anzupassen oder
• 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@traso.de
________________________________________________________
Handelsregister: Amtsgericht Leipzig, HRB 21850