Agile Entwicklung mit FirstSpirit: External Sync

Veröffentlicht am 24.05.2019

In modernen IT-Projekten setzt man auf agile Methoden, die es einem erlauben zügig auf neue Anforderungen des Marktes zu reagieren. Um diese Arbeitsabläufe mit FirstSpirit zu verwenden gibt es seit einiger Zeit External Sync. Damit kann man die proprietären Daten im CMS unter die Kontrolle eines VCS wie Git bringen und kann somit alle Vorteile einer verteilten Entwicklung und Continuous Integration genießen. In diesem Blogbeitrag wollen wir ein typisches Entwicklungsszenario mit seinen Problemen vorstellen, wie wir das in der Vergangenheit gelöst haben und wie schnell man so etwas aufsetzen kann.

Dr. Max Möllers

CEO and Project Management

Szenario

klassische Deployment Pipeline

Nehmen wir der Einfachheit halber an, dass FirstSpirit eine einzelne Website mit statischem HTML + JS + CSS generiert. Integrationen in Shops, Portale, SPAs oder auch Multi-site Szenarien funktionieren analog, machen die Erklärung jedoch nur unnötig länger.

Es gibt 3 FirstSpirit-Server: D(evelopment), Q(uality Assurance), und P(roduction). Auf diesen Umgebungen wird wie folgt gearbeitet:

  • Auf der D erstellen die Entwickler neue Templates oder Hotfixes.

  • Auf der Q können die Redakteure neue Entwicklungsstände begutachten und abnehmen.

  • Auf der P wird der eigentliche Content gepflegt und alle Templates sind komplett abgenommen. Hiervon wird regelmäßig zum Webserver generiert.

Änderungen an Templates werden von D nach Q nach P geschoben. Kleinere Änderungen können zwar als einzelne Pakete migriert werden, bei größeren Änderungen muss jedoch der gesamte Templatestand abgeglichen werden. Die Entwickler müssen sich somit koordinieren und werden somit nur in Intervallen, z.B. alle 4 Wochen, Änderungen auf Q/P transferieren. Insbesondere Hotfixes sind hier problematisch, da man den Hotfix entweder direkt auf der P entwickelt, oder auf D/Q Templateänderungen zurückrollen muss um die P Umgebung darzustellen.

All diese Probleme lassen sich mit External Sync umgehen.

External Sync

Git Flow Diagram

External Sync erlaubt es die FirstSpirit Objekte (z.B. Templates), die im proprietären Repository liegen, in eine Ordnerstruktur mit Flat-Files zu exportieren und von dort aus auch in den FirstSpirit Server zu importieren. Man nutzt dazu ein flexibles Command Line-Werkzeug, dass den Server über die öffentliche API steuert: FirstSpirit Dev Tools

Der Export des TemplateStores z.B. besteht aus einem Ordner mit allen Seitentemplates, Abschnittstemplates, etc. , welche wiederum durch menschenlesbare XML Dateien dargestellt werden.

Auf diesem Export kann man nun eine Versionskontrolle mit Git aufsetzen und sich für den jeweiligen Fall passende Branchingstrategien ausdenken. Für unser Szenario nehmen wir an, dass sich die Entwickler für den Git Flow entscheiden.

Nun soll die P Umgebung immer dem "master" branch (türkis) entsprechen, D entspricht dem "develop" branch (gelb) und auf die Q werden immer Releasekandidaten (grün) zur Abnahme gestellt. Was heisst das konkret?

Nehmen wir an, dass ein neues Template auf D entwickelt wurde und fertig ist zur Abnahme. Der Entwickler exportiert nun mit ExternalSync den neuen Templatestand in einen Git Ordner, aktualisiert den lokalen Zustand und schickt das Update in das gemeinsame Git-Repository.

fs-cli -h fs-d.customer.com -port 4242 -c HTTP -p "DevProject" -u userA -pwd mypwd export
git commit && git push

Damit die Redakteure das neue Feature testen können, lassen wir den “Release Candidate” Branch auf den letzten Commit des “develop” Branch zeigen. Danach wird auf der Q Umgebung die Änderung abgeholt mit:

git pull 
fs-cli -h fs-q.customer.com -port 4242 -c HTTP -p "DevProject" -u userA -pwd mypwd import

Jetzt sehen die Redakteure die Änderungen, können diese austesten und final abnehmen. Nach Abnahme kann dann analog die Änderung auf die P transportiert werden.

Wir nutzen nun External Sync, aber der Entwicklungsprozess sieht noch nicht viel anders aus als unser klassisches Setup.

Verteilte Entwicklung

Deployment pipeline FirstSpirit

Ein großer Vorteil des neuen Setups ist, dass die Entwickler nun parallel an verschiedenen Features arbeiten können ohne sich gegenseitig einzuschränken oder Releases zu verhindern. Jeder Entwickler installiert sich lokal einen FirstSpirit Server und erstellt im Git einen Feature Branch auf dem er sein Feature entwickelt (in der Git Flow Grafik rosa). Sobald das Feature ausgereift ist kann es auf den “develop” Branch (auf der D beheimatet) gemerged werden. Dieses Feature kann dann isoliert oder mit weiteren neuen Features zusammen auf die Q gebracht werden zwecks Testing durch die Redakteure und dann final auf dem “master” Branch / der P landen. Zusätzlich ist ein Arbeiten auf einem lokalen Server deutlich performanter als auf einem (u.U. weit entfernten) remote Server.

Der einzige Nachteil der verteilten Entwicklung ist dass für jeden lokalen Server eine Lizenz vorhanden sein muss. Im Lizenzmodell werden diese lokalen Server jedoch deutlich anders behandelt als ein “echter” weiterer Server (z.B. von D+P auf D+Q+P). Von den Kosten her werden diese eher als zusätzliche Nutzer berechnet. Unsere bisherigen Erfahrungen mit dem Vertrieb sind dort sehr positiv und die geringen Mehrkosten waren bisher kein Argument gegen den Einsatz der verteilten Entwicklung. Etwaige zukünftige Änderungen des Lizenzmodells durch die e-Spirit AG müssen natürlich dann neu bewertet werden.

Hotfix

Ein weiterer Vorteil ist, dass die Entwickler schnell auf Probleme in der Produktionsumgebung reagieren können. Tritt ein Problem auf, kann der Entwickler mittels Git sich den Stand des “master” Branchs / der P holen, das Problem lokal nachstellen und einen Hotfix erstellen (rot in Grafik). Dieser kann danach auf den “master” Branch / die P angewandt werden und landet zusätzlich mittels Merge auf dem “develop” Branch / der D Umgebung.

Wir sind somit durchgehend releasefähig und müssen nicht bis zum Sprintende oder ähnliches warten, damit ein Fix live gehen kann.

Continuous Integration

Viele der manuellen Schritte auf der Kommandozeile können auch automatisiert werden. Hilfreich ist es z.B. wenn der Zustand von D und von Q immer dem “develop” bzw. “release candidate” Branch entspricht. Man nimmt dazu ein Continuous Integration (CI) Tool wie z.B. Jenkins oder Bamboo und lässt es auf Änderungen im Git warten.

Sobald also ein Entwickler seine Änderungen auf den “develop” Branch anwendet, wird die Änderung automatisch auf den D Server ausgecheckt und mittels fs-cli importiert.

Bei der P kann man analog verfahren, es hat sich jedoch in der Praxis bewährt, die Änderungen zwar mittels Jenkins oder Bamboo übernehmen zu können, aber diesen Prozess manuell zu starten. Ansonsten könnten unbeabsichtigt Änderungen auf der P landen. Man denke da an einen Praktikanten der sich mit seinen Git Befehlen vertut und somit nicht abgenommenen Code live setzt.

Externe Compiler

Ein weiteres verbessertes Szenario ist der Einsatz von externen Präprozessoren wie z.B. SCSS für die CSS Erstellung. Hier kann der Entwickler wie bisher sein Layout mittels SCSS spezifizieren und dann mittels fs-cli das aktualisierte CSS in FirstSpirit importieren. Auch Minifier für eigene JavaScript-Dateien lassen sich so einbinden ohne dass man die neuen Versionen immer wieder manuell über den FirstSpirit SiteArchitect einbinden muss.

Umsetzung in der Praxis

Wir haben jetzt gesehen, dass der Einsatz von ExternalSync den Entwicklungsprozess deutlich beschleunigt, mehr Kontrolle über die verschiedenen Entwicklungsstände gibt und viel Automatisierungspotential bietet. Aber wie lange dauert es denn eine bestehenden Prozess umzusetzen?

Nach unser Erfahrung kann man die ersten Schritte sehr schnell machen, da man nur das Kommandozeilentool braucht und ein Git-Repository. An einem Nachmittag hat man sich eingelesen und passende Skripte geschrieben, sodass man einfach im- und exportieren kann. Als nächstes muss sich das Team Gedanken machen wie es zusammenarbeiten möchte und welchem Workflow die Codeänderungen folgen sollen. Meist nutzt das Team schon so etwas wie den hier erwähnten GIT Flow für andere Komponenten wie z.B. die Modulentwicklung. Es gibt dann wenig Erklärungs- und Umsetzungsbedarf. Als letztes kommt die Continuous Integration, die je nach Komfortgrad ein paar Tage Arbeit darstellen kann.

Insgesamt hat man somit nach 2 Wochen reiner Arbeit einen massiv verbesserten Entwicklungsprozess, der sich schnellstens bezahlt macht. In unseren Projekten hat es noch kein Kunde bereut diesen Weg gegangen zu sein.

facebook icon twitter icon xing icon linkedin icon
© 2019 aboutcontent GmbH