Wer kennt nicht das Problem: es gibt so viele Dinge die es lohnen würde anzusehen oder fertigzustellen, aber es kommt immer etwas dazwischen. Wir haben deshalb ein internes Barcamp als zweiwöchiges Format eingeführt, um in kleinen Teams an Aufgaben oder Projekten zu arbeiten. Ganz wie beim großen Vorbild haben wir gleich morgens eine Session Planung auf Basis einer vorab erstellten Liste von Aufgaben in unserem GitLab. Unser Team voted für die einzelnen Themen und es wird so eine Mischung verschiedenster Themen entweder über den ganzen Tag oder getrennt nach Vor- und Nachmittag angegangen.

In diesem Barcamp waren dabei:

  • Weihnachtsgeschenk für unsere Kunden - wer im Oktober plant hat mehr Zeit
  • Vereinheitlichung unserer 3 Kanban Boards auf ein zentrales Board und ein Abgleich aller Prozesse bei uns
  • Verlinken von Merge-Requests aus GitLab in Redmine Tickets
  • Alle Neos Systeme unserer Kunden auf die aktuellste LTS bringen - sowie ein Plan für zukünftige Updates
  • Ein Tool um automatisiert Screenshots aller Seiten einer Website / Webanwendung anzulegen und auf Unterschiede zu vergleichen

Zum Thema Weihnachtsgeschenk wird hier nichts weiter verraten, nur so viel: es wird wieder zusammen gebacken und unsere Kunden und Partner können sich auf selbstgemachte Leckereien freuen.

Für unser gemeinsames Kanban Board haben wir alle unsere Boards und Prozesse die derzeit im Frontend und Backend-Bereich unterteilt sind unter die Lupe genommen, diese verschmelzen im Rahmen einer Ausrichtung auf digitale Lösungen immer weiter, so dass eine Zusammenführung für uns einen wichtigen Schritt darstellt. Es hat sich herausgestellt, dass Arbeitspakete (Workpackages) eine Unterschiedliche Notwendigkeit für Feedback haben und die Phase der Akzeptanz von uns genauer in eine fachliche Akzeptanz (ist ein Feature so wie besprochen) und Qualitätssicherung bzw. technische Akzeptanz (passt der Anspruch an Qualität und "innere Werte") geteilt werden kann. Auch für Abhängigkeiten und blockierte Tickets, sowie denn (seltenen) Fall an eine hohe Priorisierung als "Eilticket" haben wir Lösungen gefunden.

Als nächstes steht hier die Erarbeitung eines Skill-basierten Ansatzes für das Backlog und die Regeln für das Pull-Prinzip (wer darf wann welche Arbeitspakete in den Prozess ziehen) an, sowie das skizzierte Layout an unser neues 13qm Wand-Whiteboard zu bringen.

Ein grober Entwurf für das neue gemeinsame Kanban Board mit der geplanten Spalten-Einteilung

Für eine Anbindung von Redmine an unser GitLab haben sich Sören, Marcel und Sebastian den Einsatz von Webhooks und die Möglichkeiten zur Automatisierung in Gitlab angesehen. Als kleine Übung in Go wurde eine erste Version eines leichtgewichtigen Servers zur Verarbeitung der Hooks und zum Aufruf der API in Redmine entwickelt. Ein Vorteil der Lösung ist, dass diese mit sehr wenig Ressourcen als Microservice in unserer internen Kubernetes Cloud als Docker Container betrieben werden kann. Ein Docker Image für eine Go Applikation ist dabei durch die direkte Einbindung aller Abhängigkeiten (Stichwort statisches Linking) nur wenige Megabyte groß - sehr zum Vorteil in der Build Pipeline und beim Einsatz vieler kleiner Microservices. Natürlich veröffentlichen wir den Code auch auf Github wenn wir den Service vermutlich zum nächsten Barcamp fertigstellen.

Im Rahmen unserer Arbeit für das Neos Projekt haben wir schon seit Version 1.2 Projekte für Kunden damit umgesetzt. Eine aktive Community kümmert sich dauerhaft um eine Pflege des Systems und eine kontinuierliche Weiterentwicklung (siehe auch die Neos CMS Roadmap). Dabei haben sich in Vergangenheit bei Projekten verschiedene Versionen ab 2.1 angesammelt, die nun auf die aktuellste LTS Version 2.3 gebracht wurden, so dass eine Versorgung mit Security-Fixes noch bis August 2019 im Rahmen unseres Neos-Hostings ohne weiteren Aufwand gegeben ist. Dabei wurde von Christian, Kai und Lars neben einer einheitlichen Benutzung im Composer Manifest (keine Verwendung von dev-master oder unspezifizierten Versionen) auch ein Plan für den Einsatz in Neuprojekten definiert:

  • es wird jeweils die aktuellste, stabile Neos Version (auch nicht LTS) eingesetzt, um dem Kunden und uns bei der Entwicklung die neuesten Funktionen zu bieten
  • danach kümmern wir uns im Rahmen der Betreuung der Seite (Hosting oder Wartungsvertrag) um die Updates auf die jeweils folgende Version bis zur nächsten LTS-Version
  • natürlich sind Security-Updates ohne weiteren Aufwand enthalten
  • updates z.B. auf die darauf folgende LTS-Version werden von uns je nach Umfang des Projekts angeboten

Damit haben wir einen guten Plan um Stabilität, Sicherheit und trotzdem aktuellste Features in Projekten einsetzen zu können.

Das Projekt für einen automatisierten Screenshot-Vergleich haben Christoph und ich am Nachmittag konzipiert und weiterentwickelt. Schon in der Woche davor haben wir anhand der kurierten Liste Awesome Regression Testing verschiedene Tools evaluiert und getestet. Als vielversprechender Kandidat hat sich Spectre als reine Webanwendung mit API herausgestellt, welches wir durch einen Crawler bzw. URLs aus einer Google Sitemap mit einem Script zur Erzeugung von Screenshots aus einem Headless Chrome versorgen wollen.

Beispiel eines Testlaufs in Spectre zwischen einer Live-Version und einem Testsystem

Ein erster Entwicklungsstand ist auf https://github.com/networkteam/stavro veröffentlicht, mit dieser Version können Screenshots auf Basis einer Google Sitemap oder einer Liste von URLs in verschiedenen Auflösungen automatisiert erstellt und zu Spectre als Testergebnis hochgeladen werden. Ein nächster Schritt ist das Deployment in unsere interne Kubernetes Cloud und der Aufbau eines einfachen Interfaces zur Auslösung eines neuen Testlaufs geplant.

Wir werden den aktuellen Stand jedoch jetzt schon für die nächsten großen Updates nutzen, um eine möglichst fehlerfreie Funktion gewährleisten zu können und unsere Tester bei der Arbeit zu unterstützen.

Fazit: Das Barcamp hat neben viel Spaß und dem Wissensgewinn auch viele konkrete Ergebnisse erzielt. In den kurzen Zwischen- und Abschlusspräsentation wird ein guter Einblick in die Ergebnisse der anderen Sessions möglich und über einen Blog-Post sowie eine Veröffentlichung der Ergebnisse wollen wir auch bei den nächsten Barcamps alle anderen an unserer Arbeit teilhaben lassen.