Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Diesmal zu Gast bei mir Lars Kempe, QE Lead der Firma Dolby. Ja Dolby ist uns doch allen ein Begriff. Ob Surround System oder Kinomusik, immer wieder taucht das Dolby Logo auf, früher auf den Kassetten, wer sich noch erinnern kann. Ja und mit Lars habe ich über deren CI Pipeline gesprochen.
Und er erklärt uns ganz genau wie sie ihre CI Pipeline aufgebaut haben, damit sie möglichst kurze Laufzeit haben, maximal 10 Minuten. Wie die Tests selektiert werden, wie die Durchführung funktioniert, wie die Abdeckung gemessen wird und wie das alles in ihren Prozess integriert ist. Sehr spannend, weil es wirklich mal einen tiefen Einblick gibt, wie man so etwas machen kann. Und es würde mich freuen, wenn sich der eine oder andere davon auch inspiriert fühlt.
In diesem Sinne viel Spaß bei der Folge. Hallo Lars, schön, dass du da bist. Ja, freut mich, dass du da bist. Ja, wir haben ja mal ganz kurz die Vorgeschichte, wir hätten uns ja eigentlich schon am German Testing Day unterhalten sollen, aber da gab es E-Mail-Verluste auf dem Weg. Ja, passiert halt.
Und wir hatten keinen Termin dort gefunden, aber umso schöner, dass wir das jetzt abholen, weil das Thema finde ich schon sehr interessant und wollte das auch unbedingt hier mal für die Community haben, weil du ja in einem spannenden Umfeld arbeitest. Der WB ist ein Begriff, den kennen viele. Und zum anderen geht es um das Thema CI und wie man damit umgeht, auch was die Laufzeit und alles Mögliche angeht.
Und das ist natürlich immer schön, was ihr da für eine Lösung gefunden habt für euch und das Ganze. Gewinnt. Gut am Laufen zu haben. Genau, und da würde ich einfach mal so reinfangen. Sag mal, was war denn so die Herausforderung oder warum du dich mit dem Thema dann auch so beschäftigt hast? Ich glaube, ich würde mal von eher anfangen. Das Thema treibt uns schon länger rum. Also das ist jetzt nicht, dass es neu aufgekommen ist. Man möchte, glaube ich, schon immer eine schnelle CI haben.
Wir haben immer daran gearbeitet, mit eigenen Methoden, mit eigenen Mitteln die CI schnell zu behalten und trotzdem genügend Tests zu machen. Und trotzdem waren wir nicht glücklich damit. Und in unserem Fall, also in meinem Fall war es jetzt so, dass wir vor drei Jahren ungefähr ein komplett neues Projekt begonnen haben mit der Erfahrung von ganz vielen verschiedenen Leuten aus ehemaligen Projekten, die jetzt in das neue Projekt gestartet sind.
Und da habe ich die Aufgabe bekommen, jetzt auch als QA Lead, also dort zu fungieren. Und da habe ich gesagt, also wenn ich das mache, dann möchte ich es gerne ordentlich machen. Und wir fangen jetzt mit einer schnellen CI von Anfang an an, auch wenn wir jetzt noch nicht so viele Tests oder Code haben, sondern wir machen das gleich richtig und habe dann das Okay von meinem Chef bekommen, ja mal in dem Fall das Tool Team Scale einzusetzen, um dann das automatisiert besser zu machen.
Genau, das war der Anfangspunkt von daher. Ja, ja, also das Ganze auch mal einfach auch besser zu machen. Vielleicht kannst du ein bisschen erzählen, was ist denn so der Umfang, den ihr da so bewegt durch die CI durch, damit wir so ein Gefühl auch haben, worum es denn eigentlich geht, was ihr da so macht. Ja, wie gesagt, bei uns, das neue Projekt war am Anfang echt klein. Also da haben wir wirklich nur ein paar hundert Tests.
Also wir haben eine 100% Testautomatisierung, wir machen Software, also wir bauen letztendlich Libraries, die wir an Kunden verkaufen und das ist wirklich Integrationscode, C-Code und so weiter. In dem Projekt, wo wir gleich angefangen haben, haben wir viele Module von existierenden Projekten gestartet und deswegen konnten wir wirklich mal mit 100 Tests erst mal anfangen.
Die Erfahrung erzeugt aber bei uns, dadurch, dass wir die Testautomatisierung haben, wir nutzen PyTest als Testautomatisierungstool, dass wir ganz schnell in die Parametrisierung reinlaufen und dass dann aus einer Testfunktion bei uns ziemlich schnell ganz viele Testfälle werden können. Beispiel ist, du hast Dolby genannt, passt jetzt vielleicht nicht unbedingt auf mein Projekt, aber ein Beispiel wäre zum Beispiel Lautsprecherkonfiguration.
Wir unterhalten uns hier, ich habe von mir einen MonoSpeaker stehen, was gibt es denn als nächstes dann, was kennst du so als Speaker-Output? Naja, es gibt dann auch natürlich Stereo und Quadro und Dolby und alles rundherum von allen Seiten. Genau, genau, also Stereo hast du schon zwei Lautsprecher-Output. Also den gleichen Input, den gleichen Test jetzt endlich, also bei allen Sachen kann man das machen, aber es gibt genügend Tests, wo man das dann hochskanieren kann.
Dann gibt es 5.1 als Surround, was du kennst, und jetzt kommt Dolby Atmos ins Spiel, wo jetzt noch Höhenkanäle kommen. Sprich, du hast jetzt 5.1, dann kannst du zwei Höhenkanäle haben, vier Höhenkanäle, kannst du 7.1 haben, nochmal mit den gleichen Höhen. Und dann hast du einen Testcase, wo du dann plötzlich aus allen Testfunktionen allein 8-Speaker-Konfigurationen hast, an 8 Testfäden.
Wenn du dann noch einen Lehrer drauf machst, mit verschiedenen Bitraten, wenn man dann DD+ nimmt, oder dass du verschiedene Bitraten hast, verschiedene Frame-Raten, die kommen dann auch noch mit, dann wird das ganz schnell aus einem Testfile, was weiß ich, 50 bis 100 Testcases, das kann schon mal passieren. Und das wollten wir halt optimal gestalten. Und so sind wir auch schon gewachsen. Wie gesagt, wir haben angefangen mit ganz wenigen Tests, und im Moment haben wir so um die 6000 Testfälle.
Aufgrund dieser Parametrisierung sind mehr Features hinzugekommen, usw. Und das können wir jetzt gut abdecken mit dieser schnellen CI, mit dem Tool, was dann automatisch erkennt, welcher Source Code und so getriggert wird. Genau. Kannst du da noch ein bisschen einsteigen? Was ist das Konzept? Weil die 6000 Testfälle klingt für mich schon mal sehr viel. Und wenn ich an meine Kunden denke, die Pipelines mit 6000 Testfällen, das erlebt man oft nicht wieder.
Das läuft dann über Nacht oder so, muss dann immer irgendwie gesplittet und parallel und geht alles nicht. Ja, genau. Wie ist es bei euch umgesetzt? Durch den Source Code und durch die kleinen Funktionen können wir das ziemlich kurz halten. Im Moment ist die Laufzeit, wir nutzen PyTest als Testautomatisierung, da gibt es verschiedene Plugins, wo wir dann diese Tests automatisch parallelisiert laufen lassen können.
Und wir haben im Moment eine Testlaufzeit für die 6000 Fälle, die lassen wir nachts laufen, alle Mann, bei Linux, ich glaube um die anderthalb Stunden oder so. Also das ist easy. Trotzdem ist es zu lang für eine CI. Und CI soll halt wirklich 10 Minuten bleiben. Und damit wir schnell alles haben und in den 10 Minuten müssen alle Backends gebaut werden.
Da fängt es dann an, da hast du Linux, da hast du Windows, da hast du ARM, da hast du 64-Bit, da hast du vielleicht noch Nis und Debug Backends, was gebaut und vielleicht getestet werden muss. Da laufen noch die Unit Tests und dann noch die Tests. Also da ist schon ziemlich viel in den 10 Minuten drin, was ausgeführt werden muss. Vielleicht noch mal kurz zurück, früher hatten wir das Versuch zu Deixel mit Markern bzw. so eine Test Selection, um schnell zu bleiben.
Das Problem an Markern oder Test Selection ist, wenn man das manuell macht, man muss eigentlich sich alle zwei Wochen mal wieder hinsetzen und diese Marker oder Tests anpassen, je nachdem, welcher Code hinzugekommen ist. Weil letztendlich hast du dann immer, ja, du testest irgendwas basismäßig ab, aber ist da wirklich die neuen Sachen getestet oder nicht? Wahrscheinlich nicht, weil du irgendwie zu faul warst, keine Zeit hast, wieder hingeschoben hast.
Ach, da laufen ein paar Tests, das passt schon, wenigstens das Wichtigste. Aber reicht dann das Wichtigste? Für uns nicht mehr. Von daher haben wir dann angefangen, TeamSkill zu nutzen, weil das Gute an dem TeamSkill ist ja, dass das alles weiß. Das weiß, welcher Source Code ist da und welche Tests sind da. Richtig, und das haben wir dann eingesetzt. Wir mussten ja noch ein bisschen dran arbeiten dann, an der Integration, weil TeamSkill für uns nicht die ganze Sachen schon unterstützt hat.
Wir haben PyTest, Python und so weiter, und da gab es noch keine Integration dafür. TeamSkill war sehr auf Java fokussiert am Anfang. Aber das war nicht das Problem. Wir haben dann die API mit den TeamSkill-Leuten, mit Dr. Sven Amann, dem wir gemeinsam einen Vortrag gemacht haben, sehr viel in Kontakt und haben über die API dann TeamSkill gefördert. Und wir haben dann die TeamSkill-Funktionalität nutzen können. Kannst du uns da vielleicht noch ein bisschen weiter...
Das ist ja gar nicht das, was viele... Da muss man auch ein bisschen die Tools challengen. Und das ist ja häufig das Problem. Man kauft ein Tool, das klingt doch alles super. Der Vertrieb sagt POC, alles super, alles geil. Und dann sitzt man da und denkt, oh mein Gott, und jetzt habe ich auf einmal irgend so etwas, was dann nicht dazu passt. Kannst du mal ein bisschen sagen, wie lang hat denn das bei euch gedauert, diese Integration und wie viel Aufwand ist da reingehend?
So ungefähr, dass wir da ein Bild haben. Kann ich versuchen. Genau, also wie gesagt, wir haben angefangen mit PyTest. Das Wichtigste, was auch die Grundfunktionalität des Teams geht, den Source Code, weil es ist Git. Wir waren früher bei uns in der Firma auf Perforce als Source Code Version Kontrollsystem und haben jetzt auf Git umgestellt, nach und nach. Und dadurch, dass wir das Projekt neu hatten, konnten wir gleich auf einer grünen Wiese anfangen und haben halt Git benutzt.
Also das hat funktioniert. Die Git-Integration dauert, wenn du Teamskill kennst, ich glaube, 10 Minuten oder so. Und dann weißt Teamskill, wo dein Source Code liegt, welche Branchen du hast und welche Commits es gab. Und es kommuniziert miteinander. Der größte Schnackpunkt ist jetzt, die Tests reinzubekommen. Weil wir müssen ja wissen, welcher Test coverts welchen Source Code.
Das muss ja Teamskill prinzipiell auch wissen, damit es dann beim nächsten Source Code Änderung dann den Test aussuchen kann, der genau diesen Source Code covert. Genau, und darum Code Coverage in das Spielen. Wir nutzen wie gesagt C-Code. Wir haben Instrumented Binaries, um Code Coverage zu messen. Und wir nutzen Gcov als Toon. Sprich, wir lassen schon nächtlich laufen um uns die komplette Code Coverage anzuschauen.
Das Problem ist aber, bei der kompletten Code Coverage weiß man ja nicht, welcher einzelne Test dort ist. Sprich, man muss eigentlich quasi theoretisch, wenn du es manuell machen würdest, würdest du sagen, okay, erster Test ausführen, Code Coverage abkopieren in ein Log-File oder irgendwo hin, alles löschen, zweiten Test ausführen. Und das mussten wir jetzt quasi in unsere PyTest-Umgebung einbauen. Wiederum war PyTest davon Vorteil, weil PyTest Python gibt es ganz viele Plug-Ins.
Sprich, wir haben uns einfach ein PyTest Plug-In geschrieben in unserem Entwicklungsumgebung bei uns und konnten da auf die PyTest Hooks zugreifen. Sprich, PyTest ruft nach jedem Test, also nachher gibt es ganz viele Hooks, aber was wir nutzen ist, dass nach jedem Test Ausführungen, also wirklich Test Ausführungen, nicht Testfunktionen, ich habe vorhin so erzählt, wir haben ja eine Testfunktion und mit den Lautsprecherkonfigurationen können wir ganz viele Tests daraus machen.
Und pro Lautsprecherkonfiguration, bleiben wir bei den Beispielen quasi, wird dann quasi dieser Hook getriggert, sprich, und unser Source Code ausgeführt. Und dann wussten wir, okay, wir sind jetzt in dem PyTest Plug-In, wir wissen jetzt, der Test war jetzt zu Ende und da hast du alle Informationen. Sprich, PyTest bringt dir, wie war der Test Case, wo lag der, war der Pass/Fail, Skip, je nachdem, hatte der welche Testlaufzeit, hatte der und so weiter. Also diese Informationen hatten wir schon.
Das nächste, was wir brauchen, ist halt dann die Information, welches Source Code gekauert wurde von dem Test-Kind. Das war ein bisschen Gefriemel, würde ich sagen. Da musstest du jetzt quasi die ganzen Log-Files von GCOV auswerten. Musstest ein bisschen reinlesen, aber da gibt es Gott sei Dank auch genügend Informationen. Und wir haben dann gesehen, okay, da ist der Source Code, der gekauert ist, da sind genau die Line Numbers auch, welche gekauert wurden und so weiter.
Das lesen wir jetzt auch aus und schreiben das auch in das Log-File rein. Das Log-File hat dann das Format, was TeamSkill braucht. Das war sehr gut dokumentiert auch, beziehungsweise wenn Fragen kamen, habe ich einfach Sven angerufen oder gemailt und wir haben uns auf Maschine getroffen und er hat dann weitergeholfen. Das war ganz praktisch.
Und da haben wir dann das Log-File zusammengebaut und dann das gesamte Log-File, was dann pro Test-Case die Informationen hatte, wurde dann an TeamSkill hochgeladen. Ich habe dann dafür Gott sei Dank, also ich habe selber erst mal angefangen, damit die Grobstruktur zu machen, hatte dann aber Gott sei Dank einen Studenten, der da ein bisschen mit geholfen hat.
Aber diese Integration, die ich jetzt beschrieben habe, von diesem PyTest-Plugin und so weiter, ein bisschen feinkranular, würde ich sagen, hat so zwei bis drei Wochen gedauert mit allen Tugendwachen. Also das war ein Tick länger als optimal geschätzt, aber insgesamt besser als, ja, was für Probleme es gibt und so was, ein bisschen besser als gedacht, genau. Ja, ja. Und die skaliert ja dann auch mit, ne? Also mit jedem neuen Test und Kurs quasi? Genau, das ist das Gute an der Sache.
Und das ist perfekt, ne? Weil das lassen wir jetzt auch nächtlich laufen, beziehungsweise TeamSkill braucht ja den Update, welche Tests sind neu hinzugekommen und so weiter. Vom Source-Code bekommt ihr das, weil ja die Git-Integration ja funktioniert, sprich bei jedem Git, bei jedem Branch und so weiter, wird es automatisch nach TeamSkill geschrieben, aber das hast du nicht für diese Source-Code-Coverage, ne?
Also wir haben uns jetzt erst mal entschieden, das nächtlich auszuführen, sprich mit jeder Nacht hast du dann die Information, was während des Tages passiert. Ja? Nachteil ist, wenn am Tag viel passiert im Source-Code und so und die CI läuft, weiß natürlich TeamSkill nicht, okay, gibt es da noch einen neuen Test dafür schon, den wir vielleicht parallel gemacht haben?
Wir arbeiten im Scrum, wir arbeiten quasi Entwickler und Tester zusammen in einem Team, also wird das meistens parallel auch entwickelt. Genau, also das kann schon passieren. Manchmal haben wir das dann auch so gestaltet, wenn wir einen Branch längere Zeit oder wenn der größer geworden ist, dann kannst du diese Prozedur einfach auch mal manuell triggern und dann machst du ein Update auf den Branch und dann funktioniert das auch wieder.
Also das ist nicht das große Problem, aber das Wichtigste ist wirklich, genau wie du schon gesagt hast, der neue Source-Code kommt automatisch dazu, die neuen Tests kommen automatisch dazu, sprich am nächsten Tag in der CI weißt du dann genau wieder, was ist und wenn dann jemand den Source-Code ändert wieder und dann werden genau die Tests ausgeführt.
Das heißt, ich habe maximal einen Gap von einem Tag, wo ich die Information jetzt nicht korrekt habe, über Nacht quasi läuft das nach und dann am nächsten Tag stimmt es dann wieder. Exakt. Und dann geht es natürlich weiter. Also ihr müsstet das ja quasi irgendwie in eure Pipeline auch mit integriert haben und läuft das mit. Magst du uns da noch ein bisschen mit reinholen, was eure Erfahrungen waren? Kann ich gerne machen.
Genau, also wie gesagt, diese Source-Code-Commit, also die Grundbedürfnisse, die Teamscape braucht, sind jetzt erledigt. Git-Commit funktioniert. Die Pipeline läuft nachts, um die Tests aufzudaten. Aber was passiert mit CI? Exakt, das nächste Problem. Sprich, wir wissen ja, welcher Commit ist.
Also diese Information bekommen wir von Git und da hat Teamskill natürlich auch wieder das Problem, okay, wir haben jetzt PyTest-Umgebung, kein Java, mussten wir auch wieder selber ein Skript schreiben, um diese Sachen abzufangen. Das ging aber dann doch schneller als gedacht, weil das wirklich eine API-Abfrage nur ist.
Du sendest an Teamskill, okay, das ist meine Commit-ID, die musste man noch ändern, weil Teamskill in der API-Version noch nicht die Commit-ID-Namen genommen hat, sondern die Zeit von der Commit-ID. Also sprich, du musstest da irgendwie, oder es gibt ein Git-Command, das rechnet dir die Commit-ID sofort in die Zeit um. Das ist ein One-Liner, also das geht easy. Aber genau, dann hast du eine API-Abfrage von der Commit-ID, sage ich jetzt mal, um der Einfachheit halber.
Und dann bekommst du von Teamskill halt genau die Tests zurück, die wir vorher hochgeladen haben. Da musste man vielleicht nur insgesamt ein bisschen aufpassen, dass du, man muss ja wissen, wie ruft man die Tests jetzt auf? Was für eine Möglichkeit habe ich? Also sprich, welche Informationen musste ich vorher bei dem nächtlichen Upload in Teamskill speichern, damit ich die jetzt ganz einfach aufrufen kann?
Bei unserem Fall ist es natürlich so, durch die Parametrisierung, dass teilweise von einem Source-Code-Change jetzt nicht nur ein Test zurückkommt, sondern es kommen halt 800 Tests zurück. Weil halt, doch sehr kleine, sehr granular. Ist manchmal auch fragwürdig, warum wir so viele Tests haben. Ja, das sind granule, manchmal auch wieder kleiner. Aber letztendlich kommen manchmal so viele zurück. Und da muss man wissen, genau, wie rufen wir jetzt die Tests auf?
Bei PyTests, wenn man sich ein bisschen auskennt, kann man jetzt Keywords nehmen und dass man dann eine Liste von Test-Cases macht oder ruft man die jetzt einzeln hintereinander auf und so weiter. Also da muss man auch immer kurz gucken. Aber Python, PyTest, Open Source, jeder arbeitet dran, gibt es ein geiles Plug-in für PyTest. Und zwar kann man ein File generieren, ein Text-File mit ganzen Test-Cases. Und das kann man dann per Kommandozeile übergeben.
Und dann ruft PyTest genau diese Tests auf. Da muss man noch wissen, wo man sich befindet. Also sprich im Root-Vorzeichen von PyTest, von unseren Test-Cases. Und genau diesen Pfad hat man schon gespeichert bei den nächtlichen Tests. Und das gleiche auf derselben Ebene dann wieder losläuft. Genau. Sprich, wir haben jetzt, lassen Sie uns sagen, 800 Test-Cases zurückbekommen. Das ist ein JSON-File, das kannst du einfach in Dictionary, in Python umwandeln.
Und da haben wir auch die Test-Execution-Zeit, weil wir wollen ja nie die 800 Tests ausführen, sondern unsere Limitation ist 5 Minuten Testausführungszeit. Wie gesagt, 10 Minuten CI, 5 Minuten Testausführungszeit, weil muss ja noch gebaut werden, muss das Test-Environment aufgesetzt werden, Unit-Tests und so weiter. Also maximal 5 Minuten Testausführungszeit.
Genau, also konnten wir dann sehen, ok, aufgrund der Tests, die TeamSkill schon priorisiert sendet, also TeamSkill macht schon eine Priorisierung von den Test-Cases, wie nah ist der am Source-Code dran, wie oft ist der gefehlt worden, wie neu ist der Test-Case und so weiter. Also das gibt TeamSkill. Da fangen wir jetzt einfach an, am Anfang von TeamSkill und haben einfach die Testlaufzeiten aufsummiert und nach 5 Minuten gecuttet und gesagt, ok, das reicht uns als Test.
TeamSkill hat mittlerweile eine API-Funktion hinzugefügt auf unsere Request und unsere Zusammenarbeit, dass wir jetzt auch die Zeit mitgeben können und TeamSkill sendet genau die Tests zurück, die genau in die mitgegebene Zeit passt. Das finde ich ein ganz spannendes Konzept, auch da wirklich da nochmal auf die Zeit zu schauen, wirklich das dann auch als Regel zu nehmen, weil sonst hat man vielleicht das Problem, dass es wieder voll läuft alles und dann ins schlechteste Fall wieder 6000 Tests.
Ja, genau, wenn es ein großes Code-Change ist, kann das passieren, aber das wollen wir nicht. Also Zeit ist ein ganz wichtiges Kriterium. Genau, und das haben wir jetzt eingebaut und das läuft jetzt ganz automatisch mit, sprich nach dem Build, bzw. wir konnten bei uns das automatisieren statt parallelisieren, während der Build läuft, läuft die Installierung der Test-Environment schon und die Abfrage von TeamSkill.
Wenn der Build fertig ist, können wir dann einfach mit dem PyTest-Command und dem Text-File die Anzahl der Tests hier jetzt einfach ausführen und dann haben wir das Ganze in 5 Minuten Ausführungszeit plus dann den ganzen Kladder Radatsch ringsherum, wo wir dann bei ungefähr 10 Minuten landen. Ja, sehr spannend. Ihr habt ja echt eine harte Regel auch implementiert, dass es quasi ja echt mehr als 10 Minuten, dann wäre es vielleicht mal 11 oder so was, wenn das dann doch ein bisschen länger läuft.
Du kannst ja auf die Execution der Testfälle jetzt, da hast du ja keinen Einfluss. Wenn der mal länger geht dann als das letzte Mal, dann ist es ja so. Richtig, sollte aber hoffentlich nicht so oft vorkommen. Nee, also ist ja eher dann ein Indiz, dass man da vielleicht noch mal drauf schaut, warum läuft der jetzt länger. Das finde ich total spannend, nämlich gerade auch diese ganze Integration, die du auch beschreibst, wie leicht so was von der Hand zu gehen.
Weil das ist häufig genau das dann der Knackpunkt, wie kriegt man denn eigentlich so was dann noch sauber hin. Ja, bei uns ist auch der Vorteil, wir sind schon klein. Dolby ist zwar bekannt, wir sind ein weltweites Unternehmen, aber wir sind relativ wenig Angestellte und dadurch müssen wir alles ein bisschen machen.
Hat seine Vorteile, ich als QA Lead kenne den Source Code und ich sitze auch noch da am Programmieren und muss aber auch nebenbei die QA Lead Tätigkeit machen, was manchmal auch nicht so einfach ist, aber jeder kennt quasi schon das System, der kennt sich ein bisschen mit der Umgebung aus und so weiter.
Das ist praktisch, wenn ich in großen Unternehmen von manchen höre, die dann quasi einen Test Architekt haben, der dann quasi nur sich um die Architektur kümmert und dann die Implementation, das hat auch seine Vorteile. Das muss bei solchen Sachen natürlich sein, aber in dem Fall war es echt hilfreich, sich da schnell auszukennen und einfach mal teilweise auch mal zwei Stunden zusammen per Programming machen oder so was, dann geht das auch.
Jetzt müssen wir natürlich der Vollständigkeit halber noch, die ID läuft dann durch, so im Guten Fall ist es das dann und im Schlechtfall, wie geht es dann weiter, wenn die Brieft, wie kümmert ihr euch dann darum? Du kriegst eine Information, also der CI, der den Commit getriggert hat, bekommt eine Mail, beziehungsweise sieht dann in GitLab den Status und dann muss sich dann darum kümmern, warum ging die jetzt fehl, was war das Problem?
Der Entwickler schaut dann rein, guckt dann den Test an, manchmal erkennt er es und sagt, meistens erkennt er es, wie gesagt, das ist ein kleines Team von 5, 6 Leuten, nur ein ansonsten Scrum und dann kann er das handeln und updaten und neu starten und ansonsten schauen wir dann gemeinsam rein. Also ja, das muss schon grün bleiben. Ja, ja, ja, das ist auch wichtig, dass der Prozess dann auch sauber gelegt wird. Exakt, exakt.
Wenn du jetzt so in die Zukunft schaust, dann habt ihr jetzt schon einen sehr, sehr guten Prozess, von meiner Sicht, wie du erzählst, bist du ja auch sehr zufrieden damit. Gibt es denn irgendwas, wo du sagst, ach da, da müssen wir noch besser werden oder wollt ihr jetzt vielleicht auf 7 Minuten runter oder vielleicht noch irgendwas parallelisieren oder sonst irgendwas? Habt ihr da so eine Idee, wie es da für euch noch weitergeht?
Wir sind gerade dabei, die Merge Requests besser zu gestalten, weil quasi die CI passt uns und das läuft jetzt seit anderthalb Jahren stabil ohne große Änderungen durch. Aber gerade Merge Requests haben wir manchmal den Bedarf, einfach mehr laufen zu lassen oder quasi andere Projekte, die Teamskill noch nicht nutzen, quasi Teamskill einzubauen und dann quasi ihre Tests zu optimieren und sowas.
Also da sind wir dabei, das in teilweise anderen Projekten auszurollen und davon zu profitieren, dass das schnell geht. Ja, sehr spannend. Sorry, mein Bildschirm weg, deswegen. Also ja, in dem Fall sollte es so gehen. Aber sonst bin ich nicht zufrieden, dass ein Tool das einfach funktioniert. Ja, eine Frage habe ich noch und zwar kommt es gerade bei mir noch, mit dieser ganzen Selektion und sowas, das hat ja dann auch Auswirkungen auf Testdaten, die ihr vielleicht braucht.
Wie ist denn das bei euch gelöst? Wie habt ihr denn das gemacht? Sind die beiden Test-Submitter dabei und das ist kein Thema oder wie geht ihr denn damit um? Du meinst so Test-Log-Fi ist so was in der Richtung? Also Testdaten, die man dann braucht, um die Tests durchzuführen, vielleicht irgendwelche Files oder sonst irgendetwas oder irgendwelche Daten aufbereitung. Oder habt ihr das vielleicht auch gar nicht in dem Umfeld? Also die Input-Files, die liegen komplett dazu.
Also wir brauchen jetzt nichts. Also der Test holt dann quasi, wir brauchen Input-Files, wir brauchen W-Files, Audio ist 80 Prozent der Tests, es wird Audio benötigt bei uns und die Files liegen irgendwo damit rum beziehungsweise werden dann vom Test live geholt. Da muss man ein bisschen auf die Länge achten. Wenn du jetzt ein PCM-Files vier Minuten dekodierst, dann dauert das auch meistens vier Minuten. Und das, genau. Aber ne, sonst passt das. Okay. Ja, sehr schön.
Lars, vielen, vielen Dank für diese Einblicke. Gerne. Dass man wirklich auch mal so deep dive, wie sowas aussehen kann in der Praxis. Das finde ich auch total spannend, hier auch mal sowas zu bringen. Wie kann so eine Integration auch wirklich funktionieren? Das ist natürlich auch das, was, glaube ich, auch den vielen Hörerinnen und Hörern von Podcast dann auch einfach mal wieder eine Inspiration geben kann.
Vielleicht auch mal, zehn Minuten, was für eine geile Zeit, das wollen wir auch haben mit unserer CI-Pipeline. Vielleicht auch mal in diese Richtung zu denken. Genau, ja, vielen lieben Dank, Lars. Schön, dass du hier im Podcast warst. Und ich drücke euch die Daumen, dass ihr weiterhin so schnell eure Dinge umgesetzt bekommt und so gut auch weiter testen könnt. Ja. Und ja, ich freue mich, wenn wir uns das nächste Mal wieder mal in echt sehen auch.
Ja, vielen herzlichen Dank für die Einladung, dass ich das erzählen durfte. Und wir sehen uns auf alle Fälle auf dem QS-Tag. Ach ja, genau, sehr schön. Ist ja bald. Ja, dann, schönen Tag noch und schöne Zeit. Mach's gut. Danke, gleichfalls. Ciao, Petit. Ciao.