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!

Damit ist ein weiterer Schritt zur Modernisierung der Oberfläche gelungen.

Neben dem Offensichtlichen gibt es natürlich auch noch mehr Neuigkeiten "unter der Haube". Beispielsweise ist jetzt ein Virenschutz für Dateien integriert und es gibt neue E-Mail-Account-Typen, u.a. für gemeinsame E-Mail-Konten.

Viele weitere Neuerungen sind in diesem Dokument (PDF) zusammengefasst: Tine 2.0 2019.11 Release Notes

"Die Mitgliedschaft in der KVI Initiative bietet für uns die Möglichkeit, auf der einen Seite die Bedürfnisse kirchlicher und sozialwirtschaftlicher Organisationen besser zu verstehen und auf der anderen Seite unsere Erfahrung in digitalen Prozessen und deren Sicherheit einzubringen. Wir freuen uns auf regen Austausch auf Augenhöhe.", so Christian Baumann, Head of Sales and Marketing, Metaways Infosystems GmbH.

„Wir freuen uns, mit der Metaways Infosystems GmbH ein frisches, dynamisches aber auch sehr erfahrenes Technologieunternehmen im Kreis der Mitgliedsunternehmen der KVI Initiative willkommen zu heißen.“, so Peter S. Nowak, Sprecher der KVI Initiative.

Über die Metaways Infosystems GmbH

Seit 2001 bietet Metaways Infosystems individuelle Lösungen für Hosting und Softwareentwicklung. Im Hosting liegt das Hauptaugenmerk auf hochverfügbare, skalierbare Plattformen für den Betrieb moderner Web-Anwendungen im betrieblichen Umfeld. Dabei profitiert Metaways von der hauseigenen Software-Entwicklung, die ihr Wissen, ihre Erfahrung und Werkzeuge für einen sicheren, zuverlässigen und nachhaltigen Software-Betrieb einbringt.

Gemeinsam mit dem Erzbistum Hamburg entwickelt Metaways die Kirchensoftware ecclesias, mit der die Zusammenarbeit, Kommunikation und Organisation in kirchlichen und ehrenamtlichen Strukturen verbessert wird. Bisher konnten die vielen Ehrenamtlichen nur schwer in die bestehenden Strukturen eingebunden werden. Die Software ecclesias ermöglicht nun eine - auch von Privatgeräten – datenschutzkonforme Zusammenarbeit.

Über die KVI Initiative

Die KVI Initiative - Kirche, Verwaltung & Information greift seit ihrer Gründung in 2004 aktuelle und zukunftsweisende Themen auf, um verwaltungsorientierten Führungskräften in Kirche, Diakonie, Caritas sowie in kirchlichen oder kirchennahen Organisationen neue Impulse für ihre tägliche Arbeit zu geben.

Die KVI Initiative erfüllt die Funktion einer produkt-, verbands-, und arbeitsfeldübergreifenden Plattform für den Erfahrungsaustausch der Führungskräfte, stellt einen regelmäßigen Dialog mit Experten und der Wissenschaft her und bildet eine Brückenfunktion zwischen anbietenden Unternehmen und dem Sektor Kirche & Sozialwirtschaft.