Unic spricht über die Softwarequalität bei Fooby
Magazin

Die Softwarequalität nachhaltig steigern – Oliver Burkhalter im Interview zu FOOBY

Das Projekt FOOBY gilt als Vorzeigeprojekt für einen neuen Standard in der Softwareentwicklung bei Coop. Oliver Burkhalter, Senior Application Engineer, setzt seit 13 Jahren bei Unic Software-Projekte um. Bei FOOBY hatte er die technische Verantwortung vonseiten Unic inne. Er erzählt im Interview, welche Technologien und Prozesse zur Steigerung der Softwarequalität eingeführt wurden und wie die Zusammenarbeit mit Coop verlief.

Ein neuer Softwareentwicklungsprozess entsteht

Oliver, wie ist es überhaupt dazu gekommen, dass Coop auf der Grundlage dieses Projekts einen neuen Softwareentwicklungsstandard erarbeiten wollte? Welche Rolle hat Unic dabei gespielt?

Coop hat uns angefragt, dass wir sie im Bereich der AEM-Entwicklung unterstützen. Dabei zeigten sich diverse Probleme, die nicht rein AEM-spezifisch waren. Es gab zum Beispiel Probleme mit Modulen, die sich gegenseitig überschrieben. So kam das Bedürfnis auf, die «Integrations-Probleme» zwischen diesen Modulen zu reduzieren und somit die Qualität der gelieferten Artefakte zu erhöhen, um dadurch einen stabileren Betrieb zu erhalten.

Bei Coop wuchs dann die Idee, im Rahmen des neuen Projekts FOOBY auch gleich einen neuen Softwareentwicklungsprozess zu erarbeiten, der dann exemplarisch für andere neue AEM-Projekte eingesetzt wird. Wir als Unic durften Coop auf diesem Weg mit unserer Expertise und Erfahrung begleiten. Wir unterstützten sie bei der Umsetzung dieses neuen Softwareentwicklungsprozesses.

Wie seid ihr beim Aufsetzen des neuen Entwicklungsprozesses vorgegangen? Wie habt ihr euch organisatorisch aufgestellt?

Wir haben gemeinsam geprüft, was an Softwareentwicklungswerkzeugen und -Techniken bereits im Einsatz war, und haben danach den SOLL-Zustand skizziert. Danach haben wir die einzelnen Arbeiten (automatische Tests, Continuous Integration, Continuous Delivery & Deployment) Schritt für Schritt im FOOBY-Projekt umgesetzt.

Da wir uns dafür entschieden haben, nach Scrum vorzugehen, konnten wir auch in regelmässigen Abständen evaluieren, was gut funktionierte und was weniger gut funktionierte, und entsprechende Stellen anpassen.

Was war das Ziel des neuen Prozesses?

Die Qualität der Software-Artefakte zu erhöhen und den Softwareentwicklungsprozess so zu gestalten, dass die Software in entsprechender Qualität in Betrieb genommen werden kann.

Entwickler von Unic und von Coop haben gleichzeitig an der Applikation gearbeitet. Wie war für dich persönlich die Zusammenarbeit im gemeinsamen Team?

Es waren nicht nur Team-Mitglieder von Unic und Coop dabei. Wir waren ein Firmen-übergreifendes, cross-funktionales Team. Zudem hatten wir Schnittstellen zu diversen Umsystemen, weshalb noch weitere Personen am Projekt beteiligt waren.

Die Arbeit im Dev-Team war super, und es machte mir grosse Freude, mit so unterschiedlichen Personen zusammenzuarbeiten. Wir brauchten zwar einige Sprints, bis wir ein wenig «warm» wurden, was aber normal ist bei einem neuen Team. Die regelmässigen Retrospektive-Meetings von Scrum haben uns dabei geholfen, immer mehr zusammenzuwachsen.

Ich hatte das Gefühl, es herrschte eine gute Team-Atmosphäre: Man war bereit, einander zu helfen, auch wenn es Arbeiten gab, die nicht zwingend im eigenen «Arbeitsgebiet» lagen. Das war ein gutes, beruhigendes Gefühl. Denn ca. 3 Monate vor dem geplanten Live-Gang haben meine Frau und ich unsere Tochter bekommen. Da war ich froh, dass das Team Vollgas gegeben hat und ich meinen Vaterschaftsurlaub geniessen konnte.

Warum automatisierte Tests so wichtig sind

Kommen wir zu den technischen Aspekten: Für das Engineering habt ihr automatisierte Unit-Tests sowie Integrationstests auf Basis von ScalaWebTest eingeführt. Warum, was sind die Vorteile und wie haben sich die Testing-Technologien bewährt?

Der Hauptgrund für die allgemeine Einführung von automatisierten Tests war, dass wir die Qualität der Software-Artefakte erhöhen und uns gegenseitig absichern wollten. Die Tests berücksichtigten beispielsweise Abhängigkeiten zwischen den verschiedenen Komponenten im System.

Die Einführung von automatisierten Tests hat folgende Vorteile:

  • Das Schreiben von automatisierten Tests zwingt einen Entwickler dazu, Software zu bauen, die leicht testbar ist. So baut man bereits robustere Software im Kern.
  • Mit automatisierten Tests können wir die Integration von anderen Modulen sicherstellen.
  • Die Verwendung von sogenannten «Mocks» für Umsysteme – das sind simulierte Umsysteme – ermöglichte uns eine Implementierung, die auf klaren Schnittstellen basiert. Sie machte uns zudem unabhängiger: So konnten wir im Zug ohne Internetzugang weiterarbeiten, da man keine Verbindung zu einem Umsystem brauchte.

Für die Unit-Tests haben wir bekannte Technologien gewählt, wie zum Beispiel JUnit, Mockito, AssertJ oder auch SoapUI für das Mocken von Umsystemen. Zusätzlich setzen wir auch noch AEM/Sling-spezifische Mocks ein.

Für die Integrations-Tests haben wir uns für ScalaWebTest entschieden. Dies ermöglichte uns, sehr ausdrucksstarke Tests zu schreiben. Da ScalaWebTest auf dem bekannten Testing-Framework ScalaTest basiert, sind wir auch gut gerüstet für die Zukunft. ScalaTest wird aktiv von einer grossen Community weiterentwickelt. Es erlaubt, auch andere Stile von Tests zu schreiben, was es sehr flexibel macht. Es ist schön integriert mit dem Selenium Testing-Framework, respektive es bindet auf eine einfache Art und Weise die WebDriver-API ein.

Das Schreiben von automatisierten Tests zwingt einen Entwickler dazu, Software zu bauen, die leicht testbar ist. So baut man bereits robustere Software im Kern.

Für die Endkunden muss das System laufen und brauchbar sein

Wie habt ihr Continuous Integration (CI) und Continuous Delivery&Deployment konkret umgesetzt?

Continuous Integration und Continuous Delivery&Deployment sind grundsätzliche Techniken, aber auch grundlegende Denkweisen, die die Idee verfolgen, Software in möglichst hoher Qualität und möglichst schnell (Business-getrieben) an den Endkunden zu bringen. Software bringt ja nur dann einen Mehrwert, wenn sie die Bedürfnisse der Endkunden entsprechend beachtet und sich ihnen so auch zugänglich macht. Sprich: Das System läuft und ist brauchbar. Mit nur ein paar Skizzen oder klickbaren Prototypen erhalten die Endkunden noch keine funktionsfähige Software, die ihre Probleme löst.

Für CI und Continuous Delivery haben wir Apache Maven als Build-Tool eingesetzt. Dieses Tool verwaltet das Bauen, das Testen, das Paketieren und das Bereitstellen der Software.

Continuous Deployment haben wir streng genommen nicht umgesetzt. Continuous Deployment würde bedeuten, dass bereits kurz nach einem Code-Commit alle nötigen Tests automatisch durchlaufen würden, auch Acceptance und Performance Tests. Der neue Code würde dann automatisch live gestellt, sodass die Endkunden nach wenigen Minuten auf die neusten Funktionen zugreifen könnten. Wir haben aber noch einige Zwischenarbeiten umgesetzt. So können wir zum Beispiel automatisch per Skripts die Software auf die verschiedenen Umgebungen deployen lassen.

Stichwort Modularisierung: Wie modular habt ihr das Fooby-Projekt umgesetzt?

Hmmmm...noch schwierig zu sagen. Es gibt verschiedene Ebenen der Modularisierung:

  • Auf System-Ebene haben wir verschiedene Daten von Umsystemen eingebunden, zum Beispiel Enterprise Search, Rezepte-Services oder die zentrale Authentisierungs-Infrastruktur. Diese Anforderungen wollten wir nicht in AEM lösen.
  • Auf Produkte-Ebene haben wir die nötige Trennung zwischen dem Logik-Teil (OSGi-Services, Models etc.) und dem Anzeigen-Teil (Templates, Components) gemacht.
  • Auf Code-Ebene haben wir versucht, den Code möglichst nach Features zu gruppieren, zum Beispiel auf Package-Level oder auf OSGi-Bundle-Level. So haben wir die ganze Thematik der Enterprise-Search-Anbindung in ein eigenes OSGi-Bundle ausgelagert, sodass dieses einfach von anderen Projekten eingesetzt werden kann. Das heisst, andere Projekte konnten und können davon profitieren, dass wir dieses Problem hier bereits gelöst haben.
Software bringt ja nur dann einen Mehrwert, wenn sie die Bedürfnisse der Endkunden entsprechend beachtet und sich ihnen so auch zugänglich macht.

Software zu bauen, ist eine zutiefst «soziale Kunst»

Wie weit seit ihr gekommen und was wollt ihr noch erreichen?

Ich denke, den Hauptteil konnten wir umsetzen. Wir als Entwickler haben jetzt einen neuen Softwareentwicklungsprozess, der vollständig integriert ist: mit dem Ausführen automatischer Tests, mit dem Bauen und dem Bereitstellen von Release-Paketen sowie dem halb-automatisierten Deployen. Vor allem der Teil mit den automatischen Tests war ein Kern der Umsetzung. Es ist ein Prozess sowie ein ständiges Lernen, wie man gute Tests schreiben kann.

Schlussendlich geht es immer darum, gut verständliche und testbare Software zu schreiben, die nachhaltig wartbar ist und anpassungsfähig bleibt. Und das geht nur über Coden, Coden, Coden...Lernen, Lernen, Lernen und wieder Coden, Coden, Coden...

Wie schon angetönt, könnten wir das Deployment noch vollständig automatisieren. Das heisst, ein stabiles Deployment per Knopfdruch sollte durch einen Product-Owner oder einen System-Engineer (Betrieb) möglich sein. Da sind wir noch nicht so weit. Zum Beispiel fehlen da noch die Acceptance-Tests von der Fachabteilung (soweit möglich automatisiert), automatische Performance-Tests oder automatische Rollbacks bei einem fehlerhaften Deployment.

Es ist auch immer ein Abwägen zwischen den Kosten, eine Produktions-nahe Umgebung aufrechtzuerhalten, und den Kosten, eventuell mehrmals deployen zu müssen, wenn etwas nicht korrekt funktioniert. Des Weiteren war noch die Deployment-Stabilität mit AEM eine Herausforderung. Hier müsste man je nachdem nochmal schauen, wie sich das «file-basierte» Deployment in AEM bewährt hat.

Ein persönliches Anliegen von mir war, dass wir Software «mit mehr Liebe» entwickeln lernen, ganz im Sinne «Love your code and teammates!». Und das betraf nicht nur die fachlichen und technischen Aspekte, sondern auch, oder sogar vor allem, die organisatorischen und sozialen Aspekte. Software zu bauen, zu konstruieren und zu entwickeln, ist eine zutiefst «soziale Kunst». Ich denke, das haben wir im Team erreicht und das darf sich gerne weiterverbreiten.

 

Fooby Touchpoint Integration

Unic als Technologie-Partner bei fooby.ch sorgte mit der technischen Implementierung auf dem Adobe Experience Manager (AEM) für die reibungslose User Journey.