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!

Tickets und weitere Informationen finden Sie auf der Event-Webseite des Shopware Community Day.

"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!".