METAWAYS INFOSYSTEMS

Je früher es eine eindeutige Version in einem fest definierten Zustand gibt, desto unkomplizierter werden selbst komplexe Deployments. Gerade in einem agilen Umfeld wie bei Spryker kann ein Build-Server den gewünschten Linksruck erzeugen.

In der Grundkonstellation durchläuft eine Spryker-Veröffentlichung diverse Prozesse: Vom Git über Composer und npm zu webpack oder anderen Frontend-Compilern bis zu Code-Generatoren am Ende der Toolchain. Dieser ganze Prozess ist zeitaufwändig und hat eine Reihe von Abhängigkeiten auf externe Ressourcen. Darüber hinaus sind die Ergebnisse vieler Tools versionsabhängig. Ein Build, der auf einem Tier/Stage erfolgreich war, kann auf einem anderen System fehlschlagen, oder - was noch gemeiner ist – Abweichungen aufweisen, die nicht sofort auffallen.

Es treten dabei immer wieder ähnliche Fragen auf: Haben alle Entwickler und Stages die gleiche Version der Tools? Arbeiten alle auf einem identischen Setup ihrer Entwicklungsumgebung? Wie sieht es auf dem Server aus?Sind die externen Ressourcen verfügbar? Diese Fragen werden obsolet, wenn man einen Build-Server in den Continuous-Delivery-Prozess einbindet.

Warum?

Ein Build-Server ermöglicht kleinteilige, atomare Deploys, da das Release am Stück vorliegt und nicht erst im Rahmen der Veröffentlichung entsteht. Ebenso ist ein unmittelbares Umschalten auf das neueste Release möglich. Dadurch, dass keine weiteren Build-Tools auf Produktiv-Umgebungen mehr eingesetzt werden, entstehen keine neuen Abhängigkeiten während des Deploys auf externe Registrys und die Ergebnisse der Tools selbst. Die eindeutige Version des Build-Artefakts bildet dann die Grundlage für weitere Tests und die  Kundenkommunikation. Identische Setups der weiteren Tiers oder Stages, wie einer Preview-Umgebung und folgend das Produktiv-System, stellen somit sicher, dass Probleme bereits in der Dev-Umgebung dem Entwickler auf die Füße fallen und im frühen Stadium gefixt werden, damit keine neuen Probleme durch den Build-Prozess entstehen können.

Was?

Was der Build-Server letztlich als Artefakt ausspuckt, ist sehr flexibel. Vom tarball über Debian- oder rpm-Pakete, Containern bis hin zu kompletten VMs ist alles möglich.

Aber Achtung: Du musst darauf achten, dass Konfigurationen mit Umgebungsvariablen, wie beispielsweise unterschiedlichen URLs oder Datenbanken verschiedener Stages im Build dynamisch behandelt werden und von außen parametrisiert werden können. Aus dem Grund solltest Du bei folgenden Aspekten auch frühzeitig Verantwortlichkeiten klären:

• Wann ist der Hoster zuständig? (Zugänge, Pfade usw.)
• Was obliegt dem Entwickler (z.B. Schnittstellen zu ERP oder Google Analytics usw.)?

Ihr solltet auch die Configs trennen – die Hoster-Config kommt übers ENV, alles andere ist Teil des Projekts im git! Nur so ist sichergestellt, dass es einen identischen Build für alle Umgebungen geben kann.

Wie?

Die Toolchain des Build-Servers kann vielerlei Gestalt annehmen. Für die Builds sucht ihr euch eure Favoriten aus: Shellscripts, psh (php shell helpers), rocketeer, deployer, capistrano grant, gulp … Die Tools sollten dabei Teil des Projektes sein, damit sie im Repository versioniert oder via versionierter Abhängigkeit auf einem einheitlichen Stand gehalten werden.

Einen Build-Service inklusive Ticketing kann man gut als Agentur-Leistung aufbauen, auch wenn gerade Corporate-Kunden gerne ihre Hand darauf haben wollen, um sich nicht in zu hohe Abhängigkeit zu begeben oder ein Multi-Agency-Setup zu betreiben. Auch da hilft die flexible Build-Pipe sehr, um am Ende unterschiedliche Plattformen wie Jenkins, Bamboo oder Gitlab bespielen zu können.

Fazit

Ein Build-Server ist kein Hexenwerk, erleichtert die tägliche Arbeit in agilen Teams und hebt Continuous-Delivery-Prozesse auf eine neue Stufe. Für Agenturen eröffnet sich ein echter Mehrwert, der vor allem in Verbindung mit einem mehrstufigen Hosting-Konzept zu entspannenden Deployments führt, die sogar Freitag nachmittags keine Bauchschmerzen mehr bereiten. Einfach Build-schön!

Das Positive zuerst: Der API-first-Ansatz ist sehr spannend, weil er eine hohe Flexibilität ermöglicht und Zukunftsfähigkeit verspricht. Reguläre Webshops, mobile Einkaufswelten, IoT, Unterstützung von Voice Assistenten - alles vereint in einem Backend, das die verschiedenen Kanäle bespielt. Hinzu kommen zahlreiche Verbesserungen zur Administration, die auch dem Headless E-Commerce Rechnung tragen.

Shopware 6 setzt auf einen neuen technologischen Unterbau, z.B. mit Symfony als Standard-Framework, Bootstrap 4 und vue.js. In unserer Erfahrung sind das sehr interessante, vielseitige Technologien, die auch in Hinsicht auf das Hosting des Betriebs für ein Mehr an Performance sorgen.

Dieser neue Unterbau birgt aber auch einen Haken des neuen Shopware 6: Die Migration von Shopware 5 auf das neue System ist eine Herausforderung. Sämtliche Plugins müssen für Shopware 6 überprüft, angepasst und im Zweifel neu geschrieben werden, was bei komplexen Shopware 5-Installationen einige Unwägbarkeiten mit sich bringen kann.

Ein Punkt, der aus unserer Sicht leider, keinen Einzug in Shopware 6 erhalten hat, sind geobasierte Datenbanken. Die Möglichkeit, inhaltsgleiche Datenbanken an verschiedenen Geolocations weltweit vorzuhalten, um Anfragen auf der anderen Seite der Weltkugel möglichst schnell beantworten zu können, wäre für uns ein echtes Killer-Feature.

Aber trotzdem ist Shopware 6 auf den ersten Blick ein tolles neues E-Commerce-System, auf das wir uns sehr freuen. Ab Mitte bis Ende des Jahres soll die Entwicklung so weit sein, dass dem Produktiv-Einsatz nichts mehr entgegen steht. Für alle, die sich die 6er Version erstmal angucken wollen, gibt es zwei gute Nachrichten. Zum einen wird Shopware 5 noch weitere fünf Jahre unterstützt, so dass kein Umstiegsdruck entsteht. Zum anderen kann man sich bereits die Entwicklerversion herunterladen und testen. Alle nötigen Informationen gibt es auf der Shopware-Seite.

"Hamburg ist die schönste Stadt der Welt!" sagen viele Einheimische aus voller Überzeugung. Natürlich gibt es auch Schattenseiten, doch durch großes ehrenamtliches Engagement wird an allen Ecken und Ende der Gesellschaft versucht, Not zu lindern.

Ein Beispiel ist die Hamburger Tafel, die sich selber als "Soziallogistiker" beschreibt. 400 Helfer sammeln bei zahlreichen Händlern und Unternehmen überschüssige Lebensmittel ein und bringen sie zu Ausgabestellen für Bedürftige.

In den Anfängen reichte ein Zettelkasten zur Verwaltung der Helfer und Spender, mittlerweile ist die Hamburger Tafel aber so weit gewachsen, dass Software-Unterstützung dringend nötig wurde. Das System zur Verwaltung wurde von unserem Partner SoftwareLoft zur Verfügung gestellt, der dann Metaways fragte, ob wir nicht das Hosting übernehmen könnten.

Da ließen wir uns selbstverständlich nicht lange bitten und jetzt laufen die Verwaltung und die Webseite auf unseren hochverfügbaren Servern - pro bono. Jetzt hoffen wir, dass wir auch ein winziges Stück dazu beitragen, dass mehr Menschen sagen können: "Hamburg ist die schönste Stadt der Welt!".