Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

• Sprecher: Dr. Sven Amann
• Konferenz: Frankfurter Entwicklertag 2021
• Datum: Donnerstag, 4. März 2021, 11:30 Uhr

Zusammenfassung

Software-Qualitätssicherung ist eine Feedback-Schleife: Entwickler arbeiten an einem Software-System, und dieses System durchläuft eine Qualitätsbewertung, deren Ergebnisse dann wiederum die Entwickler bei ihrer Arbeit unterstützt. Damit diese Schleife effektiv ist, muss das Feedback nach unserer Erfahrung drei Eigenschaften erfüllen:

1. Es muss schnell kommen, damit die Entwickler unmittelbar in ihrer Arbeit darauf reagieren können.

2. Es muss spezifisch sein, also individuell auf die Arbeit jedes einzelnen Entwicklers zugeschnitten, damit es jeder Einzelne auch konkret umsetzen kann.

3. Es muss explizit sein, also im Entwicklungsprozess verankert und durch konkrete Artefakte ausgedrückt, damit es einen offiziellen Stellenwert hat und im Alltag nicht »hinten runter fällt«.

Quality-Gates, wie sie in vielen Software-Entwicklungsprozessen definiert sind, funktionieren in der Praxis meist nicht wie gewünscht, da sie diese Eigenschaften nicht erfüllen. Ihr Feedback kommt oft viel zu spät im Entwicklungsprozess, sodass der Schmerz dann zu groß ist, um wegen scheinbar wenig kritischer Qualitätsprobleme das ganze System zurück in die Entwicklung zu schieben. Außerdem bewerten Quality-Gates oft das System als Ganzes, statt konkrete Änderungen, sodass es für den einzelnen Entwickler schwer ist, auf das Feedback zu reagieren.

In den letzten Jahren gab es allerdings einige Entwicklungen, die es erlauben, eine viel schlankere und wirksamere Form von Quality-Gates zu etablieren. Diese »Qualitäts-Türchen« werden einerseits erst durch Innovationen wie Infrastructure-as-Code ermöglicht, integrieren andererseits aber seit langem bekannte Methoden wie Code-Reviews. Getrieben wird diese Entwicklung durch den Wunsch nach immer kürzeren Release-Zyklen, den wir in allen Branchen beobachten.

Zentrales Element entsprechender Prozesse sind moderne Versionskontrollsysteme (VCS) wie Git, die Branching und Merging viel besser beherrschen als klassische VCS. Dies ermöglicht die isolierte Arbeit an Features und Bug-Fixes auf Feature-Branches bei gleichzeitigem Erhalt einer jederzeit Release-fähigen Mainline, wodurch wiederum schwer planbare Releases nach Feature-Fertigstellung durch einen harten, ggf. sehr schnellen Release-Takt abgelöst werden können.

Durch die Nutzung von Merge- oder Pull-Requests, wie sie von Code-Collaboration-Platforms wie GitHub, Bitbucket, GitLab und Co. eingeführt wurden, wird der Merge zu einem expliziten Bestandteil im Entwicklungsprozess und zu einem Artefakt, das mit zusätzlichen Informationen angereichert werden kann. Dazu gehören unter anderem Code-Review-Ergebnisse und Kommentare, sowie Ergebnisse aus statischen Analysen und automatisierten Tests. Wenn durch Ansätze wie Infrastructure-as-Code und Virtualisierung alle Teststufen automatisiert werden, ermöglicht eine Test-Gap-Analyse, beispielsweise mit Teamscale, sogar eine automatisierte Qualitätsbewertung der Tests als Teil von Merge-Requests. Damit wird Qualitäts-Feedback schnell, spezifisch und explizit, sodass jeder Merge-Request zu einem Mini-Quality-Gate, einem Qualitäts-Türchen, wird, das Merges nur bei nachgewiesener Qualität erlaubt.

Der Einsatz von Continuous Integration auf allen Commits auf allen Branches beschleunigt das Feedback sogar noch weiter, sodass Entwickler schon lange vor dem Merge wissen, ob ihre Änderungen am Ende durch das Türchen kommen werden. In der Praxis haben wir es üblicherweise mit einer Vielzahl von Branches zu tun und benötigen entsprechende Infrastruktur für den Qualitätsprozess. In der Teamscale-Entwicklung, beispielsweise, haben wir im September 2019 mit ca. 20 Entwicklern an knapp einer Million Zeilen Code gearbeitet. Zum diesem Zeitpunkt hatten wir 178 offene Merge Requests, auf denen jeweils 8.011 automatisierte Tests ausgeführt wurden. Im Schnitt gab es 2 Pushes pro Stunde, die zu 25 Build-Jobs auf 7 Build-Servern führten. Die Maximalwerte lagen jedoch fast um den Faktor 10 höher, d.h. der Einsatz einer entsprechend skalierbaren Cloud-Infrastruktur ist unabdingbar. Wir nutzen dafür die Google Cloud Platform, auf der wir unsere gesamte Build-Infrastruktur zu einem Preis von ca. 500€ im Monat betreiben.

Durch die geschickte Kombination althergebrachter Techniken wie Code-Reviews und innovativen Technologien wie Infastructure-as-Code, können wir inzwischen also effektive und effiziente Qualitäts-Türchen bauen. Dies ermöglicht Qualitäts-Feedback-Schleifen, die bezüglich Umfang und Geschwindigkeit bis vor Kurzem kaum vorstellbar gewesen wären, wodurch Qualitässicherungsverfahren endlich dort im Entwicklungsprozess ankommen, wo sie hingehören, nämlich auf dem zentralen Pfad der Entwicklung und nicht auf einem Nebenschauplatz.

Folien