Cornelius Weiss
Cornelius Weiss Team Lead Software Engineering Metaways Infosystems GmbH
29. November 2018 in

Dev Continuous-Delivery

Build-schön!


Ein technischer Einblick in das Thema Continuous Delivery

Das große Ziel von Continuous-Delivery-Prozessen muss es sein, die „Schmerzen“
immer weiter nach links, also an den Anfang der Pipeline, in Richtung der
Entwickler zu verschieben. 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.


Der Prozess

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 Stage erfolgreich war, kann auf einem anderen System fehlschlagen, oder - was noch gemeiner ist – Abweichungen aufweisen, die nicht sofort auffallen.


 *npm ist ein Paketmanager für die JavaScript-Laufzeitumgebung Node. Webpack ist ein Tool, das in erster Linie JavaScript-Dateien in ein modulares Paket schnürt.


 

 

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.

 

build-server_image

 

Wozu dient ein Build-Server?

Ein Build-Server ermöglicht 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.


*Registrys bezeichnet hier die Registrierungsdatenbank und damit die spezielle Konfiguration z.B. eines Servers.


 

Identische Setups der weiteren Tiers oder Stages*, wie einer Preview-Umgebung, stellen somit sicher, dass Probleme bereits in der Dev-Umgebung dem Entwickler auf die Füße fallen und im frühen Stadium gefixt werden können, damit keine neuen Probleme durch den Build-Prozess entstehen können.


*In mehrstufigen Hosting-Umgebungen bezeichnen Tiers bzw. Stages die einzelnen
  Schritte, wie z.B. Development, Staging, Production.

 

 

Was ist zu beachten?

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. 

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 für folgende Aspekte auch frühzeitig die 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.)

Du solltest dabei 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.



Welche Tools kannst Du nutzen?

Die Toolchain des Build-Servers kann vielerlei Gestalt annehmen. Für die Builds suchst Du Deine 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.

 

Was wir gelernt haben

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 entspannten Deployments führt, die sogar Freitag Nachmittag keine Bauchschmerzen mehr bereiten. Einfach Build-schön! In diesem Sinne:

giphy

You may also like:

Build-schön!

Cornelius Weiss
Team Lead Software Engineering Metaways Infosystems GmbH

Get all new updates straight to your inbox