Sven: Softwarequalität steht ja schon in deinem Job-Titel, ich muss also nicht fragen, warum du dich damit auseinandersetzt. Was sind oder waren denn hier konkrete Herausforderungen für dich?

Lars: Vor allem, die CI schneller und optimaler zu gestalten, damit man besser damit arbeiten kann. Mein Ziel war schon lange, unsere CI unter 10 Minuten zu bekommen und auch zu halten.

Sven: Warum 10 Minuten?

Lars: Das ist so ein Erfahrungswert aus vergangenen Projekten und in Abstimmung mit den Entwicklern. In 10 Minuten kann man sich gut einen Kaffee holen und wenn man zurückkommt, sind die Ergebnisse da. Man kann direkt weitermachen, das ist optimal.

Sven: Da höre ich raus, dass das in der Vergangenheit nicht (immer) geklappt hat. Woran hing es?

Lars: Das Problem waren die Testlaufzeiten. Einige Zeit geht natürlich auch immer für Kompilierung und so drauf, aber die Testlaufzeit ist das, was ständig steigt. In unserer Domäne explodiert die Anzahl der Tests sehr schnell, weil die meisten Testfälle parametrisiert sind. Da sind Parameter wie das Lautsprechersystem (5.1, 5.1.2, 7.1, …), die Bitrate oder Framerate des Tons und wir müssen wenigstens die paarweisen Kombinationen testen. Damit werden aus 40 Testfunktionen schnell einmal 1300 Testfälle in der Ausführung.

Sven: Und wenn man alle laufen lässt, kann das natürlich länger dauern, auch wenn die einzelnen Tests schnell sind…

Lars: Genau. Je nach Projekt kommen da 3-12 Stunden Testlaufzeit zusammen. Deshalb war schon lange klar, dass wir nur nachts alle Tests laufen lassen können und uns für die CI einen kleinen Teil der Tests auswählen müssen.

Das haben wir zunächst manuell versucht, indem wir wichtige Tests geflaggt haben und nur die in der CI gelaufen sind. Das hatte aber ein paar grundlegende Probleme:

1. Es wurden immer zu viele Tests ausgewählt, die eigentlich unnötig waren, wodurch auch die Laufzeit unnötig hoch war.
2. Die Pflege manueller Flags kann immer einmal vergessen werden. Oft wurden einfach nur neue Tests hinzugefügt, wodurch sich die Laufzeit ständig verlängerte.
3. Wir haben immer nur Testfunktionen ausgewählt (weil das einfacher ist), welche dann mit allen Parameterkombinationen ausgeführt wurden. Das heißt, mit neuen Parametern bzw. Parameteroptionen stieg die Anzahl der ausgeführten Test Cases und damit auch die Laufzeit.

Sven: Also habt ihr euch gefragt, ob man das nicht automatisieren kann…

Lars: Richtig.

Sven: Und da kanntest du ein Tool…

Lars: Naja, nicht ganz… Ich kenne euch ja schon ewig, mindestens seit dem QS-Tag 2016. Und mich hat auch die Test-Impact-Analyse direkt überzeugt. Allerdings hatten wir die technischen Voraussetzungen nicht, weil wir mit unserer Versionskontrolle auf Perforce waren, was Teamscale nicht nativ unterstützt.

Wir haben erst einmal versucht, etwas Vergleichbares intern selbst zu bauen. Da war die Idee einfach Tests, die gelegentlich fehlschlagen, in der CI auszuführen. Aber wie das meistens so ist: Das eigene Tool hat dann nur wenige Features und keiner hat Zeit, es weiterzuentwickeln oder zu pflegen. Und dann hat der ursprüngliche Entwickler auch noch Dolby verlassen und von da an wurde es überhaupt nicht mehr weiterentwickelt.

Sven: Und was hat sich dann geändert?

Lars: Wir haben angefangen, auf Git umzustellen. In 2020. Und ich bin in ein neues, kleines Projekt eingestiegen. Dolby Car Automotive (das ist Dolby ATMOS fürs Auto). Mit einem Team, das 8+ Jahre Vorerfahrung aus anderen Projekten mitgebracht hat und die Schmerzen kannte. Da war mir schnell klar: Das ist die Chance, es anders zu machen!

Sven: Und dafür hast du uns ins Rennen gebracht. Dankeschön!

Lars: Wie gesagt, ich war ja schon lange überzeugt und jetzt hat der Rahmen gepasst, das Problem mal mit einem professionellen Werkzeug anzugehen.

Wobei immer noch ein bisschen was zu tun war, weil ihr pytest nicht direkt unterstützt. Da haben wir die Integration selbst geschrieben. Das ging aber recht fix, auch Dank eurer guten Dokumentation und eurem Support!

Sven: Und was hat sich damit jetzt verbessert?

Lars: Die Testlaufzeit bleibt jetzt zuverlässig unten. Teamscale erfasst ja sogar die einzelnen Testcases, also die konkreten Parametrisierungen unserer Testfunktionen und wählt daraus aus. Das heißt, selbst wenn neue Parameter(optionen) hinzukommen, sprengt uns das nicht mehr die CI-Laufzeit. Und die Testauswahl aktualisiert sich laufend und automatisch und sogar noch passend zu den konkreten Änderungen, die wir machen. Damit sind wir für die Zukunft perfekt aufgestellt.

Und als Bonus können wir jetzt auch noch eure ganzen statischen Checks und Coding Conventions und Clone Detection und das alles nutzen.

Sven: Jetzt hast du ja gesagt, dass ihr mit Dolby Car Automotive quasi auf der grünen Wiese gestartet seid. Hilft euch das, was ihr da jetzt aufgebaut habt, auch für die Bestandsprojekte?

Lars: Auf jeden Fall. Wir haben da ein riesiges Potential. In nächster Zeit werden alle unsere Projekte auf Git umgestellt. Dann können wir diese prinzipiell in Teamscale einbinden. Und bei uns ist C/C++ mit pytest de facto Standard. Das heißt, wir können die Integration, die wir jetzt entwickelt haben, quasi ohne Zusatzaufwand in alle unsere Projekte ausrollen. Dann bekommen wir die Test-Impact-Analyse für alle weiteren Projekte praktisch geschenkt.

Es gibt sogar schon konkrete Anfragen von unseren Standorten in Breslau und Sydney.

Sven: Na dann freue ich mich auf mehr Zusammenarbeit in Zukunft! Gibt es noch etwas, das du sagen möchtest?

Lars: Vielen Dank für das stabile Tool und die gute Zusammenarbeit!