Der reibungslose Release von Split-Repositories

Mark Scherer
Mark Scherer Senior Software Developer & Release Manager
13. March 2018 in

Technology

Unser Artikel "The challenges of major releases and how we tackle them" beschäftigt sich ausführlich mit unserem Release-Prozess und unseren Atomic Releases. Verfügen Sie über eine größere modulare Codebasis – oder haben Sie vor, Ihre monolithische Struktur in eine solche zu übertragen?

Der folgende kompakte Leitfaden unterstützt Sie dabei. Zudem kann Ihre Codebasis Ihre Pakete ungeteilt freigeben.


Wie verwaltet man mehr als 300 Module?

Unser Ziel ist es eine spezifische Version für jedes Modul zu verwenden. Aus diesem Grund pflegen wir ein Git Repository für jedes Modul, so dass unsere Kunden einen Composer benutzen können, um die für sie relevanten Module und Versionen auszuwählen. Während dieser Vorgang sehr benutzerfreundlich für unsere Kunden ist, stellt dieser Ansatz eine Herausforderung für unsere interne Produktentwicklung dar.


Jeder weiß, wie lange es dauert, selbst bei aktiviertem Cache, hunderte von Composer-Dependencies zu ziehen. Mit stabilen Tags geht das immer noch viel schneller, als unter Verwendung der dev-master Repository-Branches. Die Sicherstellung der Geschwindigkeit beim Ziehen von Composer-Dependencies ist jedoch nur eines der Probleme, das bei einer so hohen Anzahl von Dependencies, die in composer.json angegeben sind, sichtbar wird. Stellen Sie sich vor, Sie wollen Branches wechseln oder auf die Commits eines anderen umstellen.

Größere Änderungen an so vielen separaten Abhängigkeiten würden zudem eine große Anzahl von Pull Requests (PRs) bedeuten, die zusammengeführt und freigegeben werden müssen. Das lässt nur eine Schlussfolgerung zu: es ist nicht sinnvoll.

Unsere Kunden werden in der Regel nur eine kleine Teilmenge der verfügbaren Module verwenden, aber bei der Entwicklung von Spryker-Core müssen natürlich alle Module berücksichtigt werden. Unsere Lösung verwendet einen Git-Subtree-Split-Ansatz und arbeitet mit einem Non-Split-Repository für unsere Core Entwicklung. Dies macht alle Core-Änderungen zu einem einzigen PR und macht die interne Entwicklung wesentlich einfacher und schneller.

Für unseren Demoshop benutzen wir eine modifizierte Instanz mit einem composer.json, dass das private Non-Split Repository benutzt. Es enthält den folgenden Code in seinem composer.json:

"require": {

"spryker/spryker": "dev-master"

}

 

Auf diese Weise erscheinen alle Core Module im vendor Verzeichnis als ein Single Repository. Dort können mehrere Module ganz einfach auf einen Schlag hinzugefügt oder modifiziert werden, wenn wir neue Features veröffentlichen.

 

Los geht’s: Überprüfen und Zusammenführen

Sobald Code-Änderungen in einer Branch des Non-Split Repository geprüft wurden, wird die Freigabe vorbereitet. Dabei werden die geänderten Module und ihre angezielten semantischen Versionen (Patch, Minor, Major) mit Hilfe unserer internen Release-App festgelegt.


Hier ein Beispiel, wie die Release-Übersicht für ein bestimmtes Feature aussehen kann:

Wie Sie sehen, stellen wir zudem sicher, dass geänderte Dependencies zwischen den Modulen dargestellt werden. Wenn z.B. das CartVariant Modul nur unter Anwendung des neuen Minor Releases des Produktmoduls arbeiten kann, weiß das Tool, dass composer.json der Module wie folgt aktualisiert werden muss:

"require": {

...
"spryker/product": "^6.1.0"

},

Zunächst wurde dieser Teil des Release-Prozesses als Validierungs-Tooling implementiert. In einem zweiten Schritt wurde langsam mit mehr Tooling automatisiert. Lesen Sie im weiteren Verlauf dieses Artikels, warum Tooling so wichtig ist. Ist die Freigabe schließlich genehmigt, wird der Main-Core-PR mit dem Projektcode zusammengeführt und das composer.json wird aktualisiert.

 

Doing the Split

Jetzt offenbart sich die Magie unseres Split-Skripts, welches das zusammengeführte, Non-Split Core-Repository nimmt und jedes Modul und alle neuen Commits in die geteilten Repositories aufteilt. In unserem Fall werden „spryker/cart-variant”, „spryker/product” und der neue „spryker/product-checkout-connector” die neuen Commits in ihren Master-Branch geschoben. Das Skript läuft im Hintergrund als Cronjob, und es dauert für alle Module und ihre Commits bis zu einer Minute, sie in ihre Split-Repositories zuzuordnen. Während das Skript nach neuen Commits oder Branches im Non-Split-Repository sucht, erstellt es einen Cache-Ordner und nimmt alle notwendigen Änderungen im Split-Teil vor.

 

Core-Releases in einem Klick

Auf der Release-App überprüft ein Monitor, ob alle Splits ordnungsgemäß aktualisiert wurden und zur Freigabe bereit sind. Es stellt zudem sicher, dass die Berichte des Continuous Integration-Systems für den aktuellen Master grün sind, damit der Freigabe-Prozess fortgesetzt werden kann. An diesem Punkt kann die eigentliche Freigabe mit nur einem Klick erfolgen. Basierend auf dem obigen Template wird auf dem Split-Repository ein „Github-Release“ ausgelöst, das es dann mit der neuen erwarteten Version kennzeichnet und eine automatisierte Release-Note als Inhalt hinzufügt. Gleichzeitig wird durch die Einleitung des Freigabe-Prozesses auch eine interne Freigabe-Zusammenfassung für die Veröffentlichung per E-Mail und in der Spryker Academy erstellt.

Das Listing von unseren releasten Modulen läuft über Packagist. Auf unserer Seite triggert jeder "Tag" ein Update auf Packagist und macht das neue Module für jeden als Composer Package verfügbar.

Spryker_Release-App

Going Public

Erinnern Sie sich, dass wir eine private, angepasste Version des Demoshops benutzen, die das Non-Split-Repository benötigt. Der nächste Schritt besteht darin, die Änderungen in der öffentlichen Version des Demoshops bereitzustellen.

Als letzter Schritt werden die Änderungen aus dem Non-Split-Demoshop in den öffentlichen zusammengeführt. Anschließend werden alle freigegebenen Split-Core-Module aktualisiert.
Die Release-App unterstützt diesen Prozess, indem sie einen Befehl zur Ausführung bereitstellt. In unserem Fall muss composer require "spryker/product-checkout-connector":"^1.0.0" als Kommandozeilenaufruf ausgeführt werden.
Die composer.json des Demoshops enthält das obige Connector-Release als neue Dependency:

"require": {

...
"spryker/cart-variant": "^2.0.1",
"spryker/product": "^6.0.0",
"spryker/product-checkout-connector": "^1.0.0"
...

}

Die beiden anderen Module – da wir der semantischen Versionierung (semver) folgen – benötigen eigentlich kein composer.json-Update. Ein simples composer update "spryker/*" aktualisiert hier automatisch die composer.lock-Datei und stellt sicher, dass die neuen Modulversionen enthalten sind.

An dieser Stelle kann die neue Funktionalität im Demoshop verifiziert werden, die dass das Split-Release abschließt. Ich hoffe, es ist nun klar, warum das bereits erwähnte Release-Management-Tooling so wichtig ist. Die composer.json-Dateien der Module hatten bis jetzt keinen funktionalen Nutzen. Die Release-App stellt sicher, dass diese Dateien vor der Freigabe gültig und vollständig sind und die Splits gekennzeichnet werden. Bei Fehlern müssen zu diesem Zeitpunkt "Patch-Release"-Korrekturen vorgenommen werden, die einen komplett neuen Freigabe-Zyklus auslösen.

 

Hotfix Releases

Ein Anwendungsfall, der nicht auf dem oben genannten Ansatz basiert, ist das Hotfixing älterer Release-Versionen. In diesem Fall muss auf einem Einzel-Repository gearbeitet werden, da die Funktionalität auf Basis neuerer Freigaben von Dependencies direkt im öffentlichen Demoshop verifiziert werden müssen. Aber zum Glück ist dieser Anwendungsfall selten.

Erkenntnisse aus der Entwicklung dieses Split-Prozesses

Subtree-Splitting ermöglicht Single- bis Multi-Repo-Releases und einen schlanken Workflow für hunderte von Git-Repositories bei gleichzeitiger flexibler Nutzung und Aktualisierung auf der Split-Seite. Zusätzliche Automatisierungs- und Validierungs-Werkzeuge sind jedoch unerlässlich. Sie reduzieren menschliche Fehler und Wiederholungen für wiederkehrende Aufgaben und beschleunigen den Prozess weiter.



Noch Fragen?

Haben Sie weitere Fragen oder wollen mit uns den Release Prozess diskutieren, dann besuchen Sie unser Forum.

Kontakt aufnehmen

 



mail-iconVerpassen Sie keine Branchen-News!

Interessiert an weiteren Spryker Updates und den neuesten Artikeln mit Branchentipps und Software-Tricks? Dann melden Sie sich für unseren Newsletter an.

Still got questions?
Ask the author for further information.