Jetzt geht's ab. Ich gehe auf den auf den zugefrorenen See. Ja, man wirft vielleicht erstmal einen Stein oder Haut mit einem Fußheim. Drauf oder so weißt du da auch erstmal ein Loch ins Eis mit einem fetten Stein und dann kannst du drauf. Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Herzlich Willkommen zur neuen Folge des Codium Buddies Podcasts. Schön, dass du wieder
eingeschaltet hast. Deine Gastgeber sind wieder am Start und zwar meine Wenigkeit, der Tino und mir gegenüber, der fantastische Fabi, den ich jetzt begrüßen mag, Fabi. Grüße dich, halli Hallo Tino, wie geht's? Was geht ab? Vor mir ist auch gut, es wäre schön, aber es ist leider nur ein spirituell auf dem Bildschirm, leider nicht im selben Raum, das ist richtig.
Irgendwann vielleicht mal. Irgendwann mal ja, ab und zu haben wir auch schon mal gehabt, tatsächlich ne ja auch schon mal ne Folge zusammen in einem Raum aufgenommen, ist nur leider die Seltenheit, meistens machen wir es ja digital. Die Entfernung, die Entfernung, die Entfernung, ja sag mal wie geht es dir? Mir geht es gut soweit alles am Start immer noch alles fit, sehr gut, sehr gut, das ist sehr gut,
das ist auch sehr wichtig. Ich, bevor wir mit dem Thema einsteigen, hab ich mal so ne grundlegende Frage an dich und zwar geht es jetzt schon wieder so los, dass man so sieht. Ah die Vorbereitungen steigen und waren alle schon wieder so gespannt. Nee, Weihnachten noch nicht, das ist ja schon seit Juli oder so wo du die Weihnachtsmänner kaufen kannst. Kurz nach Ostern 1 los, genau was ich meine ist der Halloween Trend, es ist ja bald Halloween.
Und da wollte ich mal wissen, bist du eigentlich so ein Halloween Typ? Also Halloween im Sinne von feierst du das? Gehst du so auf Halloween Partys oder oder rennst du von der Haustür zu Haustür und sammelt Süßigkeiten ein? Gegenfrage, Wann ist denn Halloween eigentlich? Das ist am 31, also wie du vielleicht schon merkst. Ich bin jetzt nicht ganz so auf der Höhe davon. Ja gut, nur weil das dato nicht weiß, kann es ja sein, dass du aber trotzdem da Bock drauf.
Hast ich geh natürlich immer noch durch die Straßen und sammel Süßigkeiten ein, ist doch klar, also. Find ich voll geil. Ah das wär witzig.
Stell dir mal vor du machst es klingelt, du machst die Haustür auf und hast schon so ein bisschen Süßigkeiten in der Hand, weil du weißt okay jetzt werden wieder kleine Kinder kommen, die freuen sich über Süßigkeiten und dann stehst du auf einmal du da Mitte 30 ja ich hätte echt Bock auf einen Snickers, ja. Und wenn es keinen gibt, gibt es Saures. Nein, aber gibt es Saures?
Ich habe das tatsächlich mal gehabt, irgendwann, da war ich so im, Ich glaube, das war schon so, Grundschulalter, roundabout und ich bin mir nicht ganz sicher, ich würde jetzt sagen, Grundschulalter und da habe ich mit einem Kumpel mich getroffen und Halloween war aber an einem Weiß, nicht an einem Donnerstag oder irgendeinem Wochentag, ich glaube, Donnerstag kommt hin, weil am Freitag war nicht frei so und.
Dann war es aber so, dass wir gesagt haben, wir treffen uns trotzdem am Freitag und dann sind wir einen Tag später noch mal alle Häuser bei ihm in der Siedlung abgeklappert und haben immer gesagt, wir alle so hä, was macht ihr denn hier? Das war doch gestern wir so, ja, entschuldigung, wir haben uns verlaufen. Aber die Ausbeute war gut, also was kleiner, schlecht, kleiner Life.
Einen Tag später funktioniert noch ja sehr gut, bei mir war das eher so, ich hab das als kleiner Junge auch gemacht mit Freunden und dann gab es irgendwann so diesen Wendepunkt, dass ein Jahr später. Du vor der Tür stehst und dich die Leute dann schon so angucken.
Junge geh Arbeit vorbei, geh arbeiten, Kauf dir deine eigenen Süßigkeiten und weißt du, dann stehst du da mit 20 nein, aber dann stehst du halt trotzdem noch kleiner Junge da und denkst dir so okay krass, die Zeit scheint vorbei zu sein, das ist jetzt echt unangenehm hier zu stehen, aber. Fand ich. Auf jeden Fall. War so ein Wendepunkte beim Leben damals ja krass.
Wie gesagt kann ich nicht nachvollziehen, ich geh immer noch rum, ja ja der kam bei dir noch nicht, aber ich denke mal es ist auch bei dir bald soweit, wenn die Haare grau werden, dann genau dann, dann wirst du eher gefragt ob du Süßigkeiten hast. Haben Sie Süßigkeiten? Nein, und Sie. Und ja, aber so richtig der Hype so Halloween Partys besuchen
habe ich auch schon gemacht. Ist auch witzig mit dem Verkleiden, aber so richtig so richtig catchen tut es mich auch nicht muss ich sagen, also dass ich denke ich muss unbedingt jedes Jahr auf ne Halloween Party gehen und da ich das schon wieder so n bisschen mitkriege wollte ich mal fragen wie das
bei dir so ist. Aber bist du halt jetzt auch nicht so wirklich da am Start. Nee, ich finde auch ne Halloween Party ist eigentlich nur cool, wenn man es richtig durchzieht und die Leute auch richtig Bock haben sich zu also wenn richtig was geht. Weil es ist halt immer so, ey, wir verkleiden uns und als was kommst du? Ich komm als Fabi denkst du so, ach cool. Ja, geil ist ja. Witzig, so weißt du also wenn ich jetzt als. Ich komm, ich steh dieser Ausreden. Ich will mich nicht verkleiden.
Witzige Story bevor wir jetzt mal wirklich ernsthaft mit dem Thema starten, ich war mal auf einer Allgemeinkostümparty, es war ne Geburtstagsfeier mit mit irgendeinem Motto und das war aber ne WG. Und dann dacht ich mir, gut, es gibt n Motto Ich verkleid mich keine Ahnung, weiß nicht mehr als was, aber komm da an und der restlichen WG wurde das gar nicht mitgeteilt, das heißt der eine Mitbewohner hat seinen
Leuten gesagt. Ja ist ne Kostümparty und die anderen beiden haben das nicht kommuniziert und ich war so einer der ersten von Team Verkleidung und kommt rein und alle gucken mich an. Was stimmt denn mit dem nicht? Aber warum ist der verkleidet ein supergeiler Moment. Ah das das werde ich glaube ich auch nie in meinem Leben
vergessen. Erinnert stehst du da, gefühlt keine Ahnung, ich weiß nicht mehr, sagen wir mal, weiß ich nicht als Polizist kaue oder irgendeine irgendwas halt ne und alle sind aber komplett normal gekleidet also super wirklich fantastischer Moment gewesen. Also ich würde sagen da ist wohl die Integration in die Gesamtbasis fehlgeschlagen da absolut und das ist ne super Überleitung zu unserem heutigen Thema, danke, dass du das mal sagst weil ich fand die richtig
schlecht. Ich wollte, ich wollte dich
jetzt nicht hängen lassen. Weißt du, ich greif das jetzt auf, denn kommen wir zum eigentlichen Thema, liebe Zuhörer, liebe Zuhörer, heute gibt es eine neue Def Ops Folge zu unserer Def Ops Reihe und wir haben ja in der letzten Folge schon mal so ne ne Zusammenfassung gegeben welcher Kulturwandel da stattgefunden hat in der Entwicklung und welche Grundlagen es so gibt in im Bereich Def Ops und wollen heute mal quasi mit dem ersten Thema so richtig starten.
Und zwar haben wir uns da entschieden, für Continuous Integration und das soll heute unser heutiges Thema sein, Fabi. Finde ich gut. Continuous Integration oder CI sozusagen ne kurz kurz, also ne die Abkürzung dafür, das hört man ja auch öfter. Ja, spannendes Thema auf jeden. Fall genau und du hast ja gerade schon. Angeteasert, da ist die Integration in die Code Basis fehlgeschlagen bei der Kostümparty. Dann erklär doch mal wofür CI oder Continuous Integration
Global betrachtet steht. Genau also CI ne was du meintest, das ist ja im Endeffekt ein Teil der Pipeline, also dieses diese kontinuierliche Integration und die bezieht sich ja. Im Endeffekt auf den Code, der
entwickelt wird. Also es gibt immer irgendwie einen Entwickler oder eine Entwicklerin, die Code entwickelt und dieser Code muss ja irgendwann zwangsläufig in die Code Basis integriert werden, damit halt quasi der neue Code ein neues Feature was auch immer ein Bugfix in die Software in das Gesamtprodukt integriert wird und damit das auch alles reibungslos funktioniert.
Gibt sozusagen dieses diesen CI teil, dass man halt wirklich diese Code Integration in die gesamtcode Basis vornimmt, und zwar halt im optimalen Fall nach Defops und so einer Pipeline auch automatisiert. Und man will ja auch darauf achten, dass man sagt, OK, es soll jetzt nicht, also du kannst natürlich auch einfach, wenn man jetzt so ne git Welt unterwegs
ist. Ich hoffe jetzt kommen alle mit soweit, dass man halt im Endeffekt natürlich sagen kann, OK, ich hab jetzt n git und ich kommitte alles und ich ich push das so fertig Push Force alles rein. Dann ist es auch integriert. So gesehen, es ist auch integriert, aber das. Ist nicht die Integration, die wir hier sozusagen oder die hier mit CI gemeint ist, ne? Genau, denn ein wesentlicher Bestandteil bei der Continuous Integration ist natürlich auch das automatisierte Testen
dahinter. Das heißt, bevor ich meine Änderung, die ich als Entwickler vorgenommen habe, quasi.
Integriere in die Codebasis, dass vorher Tests laufen, die checken, ob meine Änderungen denn auch, sage ich mal, sinnvoll und richtig waren und vor allem auch alles andere, was ich unberührt gelassen habe, trotzdem noch funktioniert und keine Side Effects beispielsweise entstanden sind und man sagen kann, OK, wenn die Tests alle grün sind, dann kann ich es integrieren in die Gesamtbasis und alle Entwickler haben Zugriff darauf. Ja genau.
Das ist ja so der step, dass du halt sagst, OK, ich teste es erstmal, dann gucke ich auch, ob die Software überhaupt noch baut beispielsweise. Und wenn das alles grün ist, dann integrier ich genau. Also wenn du weißt, dass es im Endeffekt funktioniert, also es ist ja auch im Normalfall so, dass wenn du jetzt dir keine Ahnung, wenn du zu Hause irgendwas. Machst oder so ne dann dann, dann checkst du ja auch erst mal kurz. OK, funktioniert das eigentlich was ich mir hier gerade
vorgenommen hab? Ne, also allein schon wenn du ich weiß nicht kennst das von früher so wenn du irgendwie auf den Teich gehen willst, der früher damals war das ja noch so wo die Teiche gefroren waren und du du gehst ja nicht einfach drauf und sagst ja komm hier, jetzt geht es ab, ich gehe auf den auf den zugefrorenen See. Ja, man wirft vielleicht erstmal n Stein oder Haut mit einem Fußheim.
Drauf oder so weißt du dann auch erstmal n Loch ins Eis mit einem fetten Stein und dann kannst du drauf, ja. Aber das war halt im Endeffekt vorher testet ob es funktioniert ne ob es klappen kann und dann kannst du halt auch wirklich deine Aktion durchführen und in dem Fall halt sozusagen erst die Tests bevor du dann wirklich deinen Code in die Codebasis integrierst. So ein Sinnbild ne, warum soll man denn sowas testen? Ne einfach? Meine kleine Ei. Aber die dazu, ja, das passt
doch ganz gut. Also du Integrierst quasi dich als weitere Person auf dem See zu den anderen, die jetzt da Eislaufen machen oder? Keine Ahnung, was auch immer. Ja, gutes Beispiel, fallen dir noch weitere Schritte ein. In dem Fall in dem Fall wäre ich der Initial commit, wenn nicht. Also wenn du der erste wärst, okay. So, und das ist natürlich jetzt nicht alles, was so diese Continuous Integration jetzt mal allgemein betrachtet umfassen
kann. Es gibt natürlich auch noch weitere Schritte, ja, wir haben jetzt, so sag ich mal, die absoluten Basics gesprochen, es kann natürlich auch noch sein, dass man ne statische Codeanalyse laufen lässt oder was auch immer da noch an Checks laufen. Zu kurz erklären, was ne statische Codeanalyse ist. Nur falls das jetzt irgendwie für irgendjemanden unklar ist. Im Ja, im Prinzip nutzt du da Tools, dass du ein gewisses Regelset hast, worauf du ja auch wirklich statisch deinen Code
überprüfst. Das kann sein ja selbst die Zeilenlänge wäre so eine Regel, die du damit definieren kannst. Also wirklich statische Checks, um so einfach schon im Vorfeld Richtlinien auch einhalten zu können. Ja, so kann man sich das jetzt mal vereinfacht vorstellen, gibt
aber halt auch. Verschiedene Normen, da gibt es halt zum Beispiel auch misrat, Shakes und was es da alles gibt am Ende. Das ist aber n Thema für sich würde ich sagen, aber so kann man sich vorstellen, dass du halt quasi feste Regeln auf deinen Code Änderungen anwendest und schaust, ob da noch alles erfüllt ist. Ja. Genau, also klar. Im Endeffekt ist es halt ne ne Frage der Definition, weil du sagst ja du möchtest deinen Code.
Also wenn wir jetzt wirklich auf einer ganz oberen Ebene agieren, würde ich sagen, die Integration automatisch in die Codebasis ist
wichtig und. Rein theoretisch würde ich sagen, ne CI wäre auch ne automatische Integration, wenn du einfach nur sagst OK der Code kommt in die Codebasis, so ganz auf einem reinen oberen Level und dann ist natürlich die Frage wie sicher willst du dir denn sein, dass dein Code auch gut ist und gut funktioniert und dann kannst du natürlich im Optimum, also es sollte es ist eigentlich n Standard, ne Tests sollten also die gehören für mich auch dazu, aber rein
theoretisch kannst du sagen ey wir wollen Tests laufen lassen bevor man den Code integriert in die Codebasis genauso wie du meintest. Diese statische Codeanalyse ist n gutes Beispiel, genauso kann es.
Kann man da ja definieren. Was wollen wir denn checken über diese statische Code Analyse damit wir sagen das passt für uns von der vom Qualitätsanspruch zum Beispiel, das ist ja so ein bisschen definitionssache und genauso wie zum Beispiel, wenn du Tests laufen lässt, kannst du ja auch so eine sogenannte Coverage überprüfen, ne, also eine Code coverage, das heißt welcher Code ist denn eigentlich abgetestet ne? Also einfach das ist ja auch so eine Art Metrik die man nutzen kann.
Können wir auch noch mal näher drauf eingehen, aber jetzt nicht unbedingt in dieser Folge. Aber es sind ja dann auch wieder ist ja auch wieder die Frage, ob jemand sagt, Ja Code Coverage, nicht Code doch Code coverage 100% also müssen es sein oder 90. 100% Reich hab ich grad versprochen, Jahrzehnt werden besser. Ja, aber weißt du, dass du zum Beispiel sagst, ja OK, 90 sind auch OK oder was auch immer?
Also das ist ja mal ne Frage von der Definition für sich selber fürs eigene Projekt. Genau. Und wenn man dann aber sagt, OK, das sind meine Parameter nach diesen Parameter, nach diesen Checks, nach diesen Metriken, gucke ich, dass zum Beispiel der der Code auch integriert wird in die Codebasis. Genau, weil das hast du ja schon
schon schön gesagt. Erhöht denn einfach die Codequalität. In der Codebasis, das heißt die Änderungen entsprechend dann deiner gewünschten Qualität am Ende und auch wie du schon gesagt hast, ist es natürlich absolut richtig, dass das Projektspezifisch ist.
Auch zum Beispiel noch mal ganz kurz die statische Codeanalyse, das sind ja festgelegte Regeln aus dem Projekt heraus, sag ich mal, auf die man sich committed hat und dann sollen die natürlich gecheckt werden, aber die müssen nicht in jedem Projekt gleich sein, da gibt es jetzt kein. Sagen wir mal ein globales richtig oder falsch und genauso kann ja auch die sämtlichen Tests, die man laufen lassen laufen lässt, 123 quasi variieren.
Also beispielsweise du hast nur Unit Tests laufen, dann laufen erstmal die Unit Tests, du hast vielleicht noch System Tests, dann laufen die Unit Tests, dann die System Tests und da hast du halt vielleicht mehrere Instanzen, also stages bis diese Integration am Ende denn durchgeführt wird beispielsweise. Und aber am Ende zahlt es halt
alles ins Gleiche ein zu sagen. Ich möchte kontinuierlich, das heißt regelmäßig Änderung in meine Gesamtcodebasis einpflegen und das automatisiert mit Gewissen. Checks, um einfach meine Codequalität zu erhalten. Genau, genau was und das ist nämlich ja, was ich dazu sagen muss, ist, dass ich tatsächlich meistens bisher so gearbeitet hab, dass wenn man jetzt davon ausgeht und du sagst, alle Checks sind gepasst, ne, also Check.
Und dann würdest du sagen, OK, du hast zum Beispiel, sagen wir mal, Du hast n Branch, auf dem wird alles ausgeführt und danach wenn es passt, wird automatisiert dieser Branch in die Codebasis integriert. Ne also in dem in den Main Branch oder so und ich hab aber bisher immer so gearbeitet, dass sozusagen erst die Integration in den Main Branch passiert ist. Also du wirklich gesagt hast, wirklich Pushe auf Main und danach liefen alle Tests los und alles was wir gerade besprochen
haben. Es ist natürlich immer die Frage, wie das auch wiederum passt. Und in dem Fall fand ich, war das an sich OK.
Man könnte sich ja natürlich jetzt hinstellen und sagen, ja gut, aber was ist denn, wenn du jetzt zum Beispiel was pusht, Feierabend machst und die Tests laufen rot und irgendjemand morgen am nächsten Tag zieht sich den aktuellen Stand und hat rote Tests. Ist natürlich nicht die feine Art und das sollte also, wenn man das so macht, wie ich es gerade beschrieben habe, wie ich auch oft bisher gearbeitet habe, muss ich ganz ehrlich sagen, dann muss man natürlich ein paar
Regeln aufstellen, zum Beispiel du pusht was, guckst, dass deine Pipeline auch grün gelaufen ist und nur wenn das der Fall ist, kannst du sozusagen auch in Ruhe Feierabend machen, oder du pusht es halt am nächsten Tag. Wichtig an der Stelle ist natürlich, dass andere aus dem Team jetzt keinen nicht lauffähigen oder? Also nicht lauffähigen stand kriegen oder ein Stand, wo die Tests rot sind.
Darauf muss man dann natürlich achten, ist aber noch ein kleiner Unterschied zwischen zum Beispiel die Art und Weise, zum Beispiel auch wie man arbeitet, also das wäre jetzt so trunk based, aber darüber können wir auch mal wann anders quatschen. Ja, also genau das ist halt auch projektabhängig und auch wie viele Entwickler es gibt, weil in deiner Arbeitsmethode noch als Anmerkung lässt du ja oder bist du in der Lage deine.
Testumgebung Lokal laufen zu lassen und du lässt sie laufen ne und hast im Prinzip für dich als Teil von CI lokal die Tests laufen lassen und die Software gebaut und siehst okay es
funktioniert. Ich kann es jetzt integrieren und die Wahrscheinlichkeit ist jetzt sehr sehr hoch, dass die Tests da auch grün sind, weil ich die gleichen Tests lokal laufen lassen habe, wenn das nicht möglich ist, sollte man so. Diesen Ansatz wechseln und sagen, OK, ich bin jetzt zum Beispiel in der Git Welt auf einem extra Branch, da laufen die Tests und wenn das Grün ist und alles gecheckt ist, erfolgt die Integration.
Also das ist halt auch immer ein bisschen projektabhängig und deswegen finde ich es auch voll OK wenn du sagst in der Regel hat das ausgereicht so zu arbeiten, weil du es halt viel lokal einfach schon überprüft hast sozusagen, und da gibt es natürlich auch andere Möglichkeiten. Du kannst auch diese lokalen Überprüfung automatisiert laufen lassen, ist aber dann wirklich ein anderes Thema jetzt.
Ja. Ja, auf jeden Fall. Aber wie gesagt, das wollte ich nur noch mal sagen, dass es im Endeffekt gibt es immer so eine, sozusagen diese Theorie und die Praxis hinterher, und es ist durchaus möglich, dass man auch ein bisschen davon abweicht, aber der Grundgedanke sollte halt eben da sein, ne, dass eben bestimmte Checks automatisiert passieren und nichts quasi irgendwann in die lauffähige Anwendung oder die benutzte Endanwendung sozusagen gelangt,
ne was nicht da hin soll. Also nur noch mal so als Kleine, als kleiner Realitätscheck aus meiner Sicht. Ja, man muss dazu auch sagen, und da kommen wir nämlich auch gleich zu einem wesentlichen Unterschied, ob man mit CI oder nicht arbeitet. Also sag ich mal mehr so in der traditionellen Softwareentwicklung noch ist.
Dass, wenn du von Änderungen jetzt sprichst in deiner Arbeitsweise muss man ja auch anmerken, dass es sich um kleine Änderungen handelt, weil kontinuierliches integrieren, das sind jetzt keine riesen Changes auf allen Ebenen, die du nach 5 Wochen reinhaust, sondern eher auf Daily Basis. Also du nimmst dir was, du bearbeitest es und integrierst es und das möglichst an einem Tag, also weißt du wirklich
kleine Änderungen. Und dann hast du natürlich auch, selbst wenn dann doch noch ein Fehler passiert, einen sehr guten Überblick, wo also wodurch es auftreten muss. Jetzt also du kannst es sehr stark eingrenzen und schnell fixen und dann lässt du die das einfach noch mal laufen, im Prinzip also nur mal noch mal als Anmerkung, weil das ist nämlich der große Vorteil gegenüber der traditionellen Softwareentwicklung, also der Vorteil von CI, dass du dadurch.
Dann nicht so lange Release Zyklen hast und Release im Sinne von auch wirklich jetzt Änderungen in den Code reinbringen. Nennen wir es mal Changes, also sozusagen. Genau, genau. Weil wenn du jetzt das nicht machst, dieses kontinuierliche und sagst, ich arbeite jetzt 56 Wochen an meinem Thema, weil ich nehme jetzt ein riesen Ticket, also ein riesen Feature was überall Änderungen hat und ich ziehe mir den Stand Tag x wo ich anfange und 5 Wochen später komme ich wieder und möchte das
jetzt integrieren. Wow, das ist echt nicht cool. Also das kann halt, je nachdem wie viele Leute darauf arbeiten, wenn du alleine bist, klar, kein Thema, brauchen wir nicht drüber reden, aber wenn jetzt mehrere Entwickler auf dieser Codebasis arbeiten, wirst du halt einfach einen erhöhten Integrationsaufwand einfach haben. Ja, das ist auch eine Sache, die spielt. Darauf finde ich. Oder zumindest nach meiner Erfahrung her spielt das auch Hand in Hand.
Also das, was ich eben gerade beschrieben habe, zielt ja auch wirklich darauf ab, dass man zum Beispiel Aufgaben innerhalb von ein einem Tag roundabout im Durchschnitt lösen kann, also dass du Pakete hast, die du anfängst und abschließen kannst. Innerhalb von einem Tag, sagen wir mal vielleicht 2 Tage, aber wirklich. Wenn es wirklich mal hart auf hart kommt, sollte es nicht länger als ne Woche dauern.
Wie lange man an so an so etwas arbeitet, weil wie du schon meintest, du hast sonst einfach unglaublich hohe Integrationsprobleme, weil du halt sagen wir mal wenn man jetzt im Fachjargon bleibt, halt starke Merch Konflikte hast im Worst Case. Es kann natürlich sein, dass es nicht so ist, aber die Wahrscheinlichkeit steigt einfach enorm. Ja, und das jeden Tag eigentlich
uns also wirklich stark. Also wirklich, das ist super wahrscheinlich dann, wenn du mehrere Tage quasi nicht integrierst und man kann sich ja theoretisch auch einfach überlegen, also wenn du zum Beispiel, sagen wir mal 50 Zeilen Code schreibst, die du dann in die neue Codebasis integrierst und es fliegt ein Fehler zum Beispiel in deinen automatisierten Checks, wie lange glaubst du, dauert es, wenn man zum Beispiel einen Fehler innerhalb von 50 Zeilen
hat, du? Sozusagen diesen Fehler zu finden in der Automatisierung und zu sagen, Oh, da ist es, das muss ich jetzt noch mal kurz anpassen, weil ich muss ja das dafür sorgen, dass die Continuous Integration erfolgreich wird, ne im Verhältnis zu du machst. Du arbeitest über einen Monat an, weiß ich nicht 5000 Zeilen und versuchst dann den Fehler zu finden. Ne, das ist halt dann immer ein bisschen die Frage. Also es wird sicherlich deutlich länger dauern, den Fehler in
5000 Zeilen zu finden. Gerade wenn du sozusagen dich daran erinnern musst. Was habe ich vor einem Monat denn vielleicht gemacht? Worst Case, das ist der Fehler da. Das ist das die absolute Hölle dann am Ende, zumal ja die Anwendung an sich auch stark weiterentwickelt hat, weil wenn ich jetzt wochenlang mich einschließe, sozusagen und an meinem Stand weiterentwickel und es gibt mehrere. Developer im Team? Dann werden die ja auch in der Zeit entwickeln.
Das heißt, die Software dreht sich sozusagen weiter von der von dem vom Stand her und das musst du ja alles wieder integrieren oder überhaupt dafür sorgen, dass deine Änderungen noch mit dem zusammenspielen, was andere in der Zeit entwickelt haben. Und das ist denn auch am Ende diese sogenannte Integration hell.
Weil das frisst richtig Zeit und sorgt auch dafür, dass Bugs eingebaut werden, weil du angenommen, du integrierst das jetzt für dich, du ziehst dir jetzt noch einen neuen Stand, Haus Deine Änderungen, Merch das zusammen und du hast eigentlich überhaupt kein gutes Gefühl oder eine Gewährleistung, ob das jetzt hier alles noch wirklich so ist, wie es sein soll.
Wenn du Glück hast, hat das Projekt eine sehr hohe Testabdeckung, also wirklich gute Tests und die signalisieren die ob noch alles geht oder nicht, aber. Aber trotzdem hast du da einfach eine steigende, also über die Zeit eine sehr hohe Wahrscheinlichkeit, dass da, wie soll ich sagen, es zu Problemen kommen kann, um es mal milde auszudrücken. Ja, auf jeden Fall. Also deswegen würde ich halt auf also definitiv auch sagen, dass
es es ist. Auf jeden Fall ratsam, gerade in diesem ganzen ci Kontext kleine Änderungen zu machen. Also wenn man nach wenn man eine Ci Pipeline hat, ist es einfach ratsam. Klar. Kleine Changes, kleine Commits, also der Umfang eines Commits sollte halt klein sein und das ist nicht nur eine gute Practice, sondern ich würde sogar fast sagen, das ist sogar
fast ein Must have. Also aus meiner Erfahrung her weißt du. Ja, weil du dann einfach dieses CI Vorteile. Bestmöglich ausnutzen kannst ne also weil du ja genau in den umgekehrten, also alle Nachteile die wir genannt haben werden ja durch CI dann zu Vorteilen, wenn du es halt kontinuierlich und in regelmäßigen Abständen integrierst, weil du hast wie gesagt dann ne kleine kleine Zyklen, ne, du hast weniger integrationsaufwand.
Du wirst weniger Probleme haben und auch frühzeitig Fehler erkennen in deiner Software und dadurch hast du ja die Möglichkeit, weil wir gesagt haben, das Ganze macht man ja unter dem Aspekt eine hohe Codequalität in der Basis zu haben oder im Projekt und genau die kannst du dann einfach besser gewährleisten und einhalten. Ja richtig, und deswegen macht es halt einfach Sinn mit CI auch wirklich, denn kontinuierlich das zu machen, ja definitiv.
Ein. Also das sind natürlich alles wirklich schöne Sachen, wo man sagen kann, okay, dass das ist. Wir wissen, jetzt würde ich jetzt mal abschließend sagen, im Sinne von, wir wissen jetzt, wieso das gut ist und was es ist. Im groben und ganzen aber hast du vielleicht auch schon mal so ein paar Probleme gehabt. Also ich finde es ja immer gut, wenn man sagt, das ist eine tolle Sache, aber meistens hast du ja trotzdem irgendwie
Herausforderungen, die die. Die nicht ausbleiben bei bei solchen Sachen weißt du also, es ist ja nicht immer nur alles Gold was glänzt. Ja, also natürlich hast du auch typische Probleme oder sagen wir mal Herausforderungen bei CI und da geht es ja schon los, dass um dieses. Also frequente committen sag ich mal, was wir jetzt gerade besprochen haben, was so n fast schon must have ist wie du gesagt hast. Um das überhaupt umsetzen zu können, muss natürlich deine gesamte übergeordnete Struktur
auch passen. Also ich kann ja also mal angenommen wir man arbeitet jetzt agil, Scrum, Kanban, gehen wir noch mal in die Welt. Und du kriegst einfach Tickets vorgesetzt, die nicht quasi eine Länge von einem Tag haben, sondern von 2 Wochen, weil die so geschnitten sind, also geschnitten von in diesem Ticket ist jetzt ein Feature abgebildet und das ist einfach super umfangreich, dann ist es halt schwierig zu sagen okay, wo mache ich jetzt meine
Integration, wenn ich sage ich möchte einmal am Tag integrieren, dann muss ich ja irgendwie gedanklich, das sind Teilprobleme schneiden, irgendwie was integrieren, was lauffähig ist und. Und da kommst du halt auch in Struggle. Überhaupt dieses Frequente, also hochfrequente Committen umzusetzen. Ja, das und das ist nicht immer gegeben, also da, da spielt auch
ganz viel. Quasi die Grundeinstellung im Projekt mit rein und wie wie deine übergeordneten Gegebenheiten sind, das muss man ja auch mal ganz klar sagen, weil du hast vorhin so schön gesagt, Realitätscheck und ich glaub das kennen wir beide auch sehr gut, dass das nicht immer gegeben ist, dass du sagst, ich hab jetzt n Ticket und das hat n Funktionsumfang von maximalen Tag super ich nehm mir das morgens, ich setz das um. Integrier ist die Pipeline
läuft, CI ist durchgelaufen und alles ist super und am Ende des Tages ist dieses Feature integriert. In der Codebasis ist ja auch die Theorie und in der Praxis, wie gesagt läuft es halt nicht immer so. Ja das muss man auch wirklich ganz klar sagen ich. Hatte das auch schon gehabt, dass man halt wirklich auch gut nach diesem Prinzip gearbeitet hat und gut die Aufgaben so geschnitten waren, dass sie halt wirklich kleinteilig waren und
trotzdem, manchmal kommt man. Zumindest ne dem was ich erlebt hab, nicht drumherum, dass es doch immer mal ne Aufgabe gibt, die dann doch umfangreicher ist. Und ich find immer, je mehr Leute im Team committen, desto kritischer wird es eigentlich ne also ich sag mal so, wenn man jetzt sagt man man hat wirklich nur eine Partei die committed ne wenn man jetzt sagt OK eine Person arbeitet an einem Projekt oder 2 im Pair Programming beispielsweise ist es noch nicht ganz so schlimm weil du halt
nicht verschiedene. Parallelentwicklungen hast aber, je mehr Parallelentwicklung stattfinden, desto schlimmer wird es eigentlich. Und da hatten wir auch schon
mal. In der Vergangenheit hatte ich das mal, dass dann auch wirklich ein sehr, sehr großer Impact im Code zwingend notwendig war, der auch eine gewisse Zeit erfordert hat und das dann aber zu integrieren, Eieiei, das ist dann also manchmal kommst du nicht drumherum, dass es irgendwann auch einfach mal passiert, also das ist auch noch mal wieder ne dieser Realitätscheck, klar. Du hast den Punkt, dass du sagst, mach das so und vielleicht funktioniert es auch oftmals gut.
Manchmal kommt man nicht ganz drumherum, also auch wenn man sehr, sehr stark versucht, es hinzukriegen. Ja. Aber Ausnahme, alles gut. Ich finde auch ein Punkt, was definitiv eine Herausforderung ist, den du gerade genannt hast, ist, wenn jetzt wirklich. In hoher Frequenz committed wird also quasi Änderungen eingepflegt werden mit vielen Entwicklern und man sich dann
vorstellt. Ich habe jetzt aber ein Projekt, wo die Bildzeit der Software ziemlich hoch ist, weil es einfach vielleicht ein Riesenprojekt ist und es dauert einfach die Software zu bauen oder auch zum Beispiel die Tests laufen zu lassen, dass die Testumgebung schon so umfangreich ist. Ich sage jetzt nicht bewusst langsam gehen wir davon aus, sie ist schon. Sehr gut umgesetzt wirst du trotzdem ja irgendwann zu einem Punkt kommen, wo beispielsweise Systemtests einfach Zeit
benötigen. Ja und definitiv dann, dann hast du natürlich trotzdem am Ende Probleme in Richtung jetzt integrieren wir und entweder die Pipeline ist geblockt weil jemand integriert und du kannst quasi gerade nicht integrieren und musst dann auf einen Stand integrieren, den du noch nicht kanntest. Ich hoffe du weißt wie ich das meine. Oder es läuft parallel und dann kann halt auch viel Chaos entstehen.
Wenn du jetzt sag ich mal mehrere Agents hättest zum Beispiel, also da kommen ja irgendwann Probleme auf dich zu, dass du ne gewisse Ungenauigkeit, ne Ungenauigkeit ist das falsche Wort, ne Ungewissheit reinbekommst und dann kann es halt auch mal knallen, aber dafür ist ja auch wiederum die Stage da, also zu sagen wir machen einen Continuous Integration und lassen die ganzen Tests laufen,
weil du dann einfach erkennst. Verdammt, hier ist die Integration fehlgeschlagen, wie du meintest und dann fixed man das und integriert erneut die Korrektur und dann ist wieder grün. Aber ich find das auch, dafür ist ja CI da das. Ist auf jeden Fall n sehr sehr guter Punkt, den du auch genau das hab ich 1 zu 1 mal so erlebt, natürlich mit dem wie ich das vorher meinte. Also es wurde erst sozusagen der Code wurde auf in in die Main
Branch Gemerged und auf. Auf dem Moment, wo der Code in den Main Branch Gemergt wurde, lief die Pipeline los, also die Tests liefen los und so weiter ne die ganzen Checks eben und da war es zum Beispiel so, dass die System Tests die wir hatten, die waren es waren schon mittlerweile einige und das war auch vielleicht nicht gerade das schnellste Test Framework, was wir verwendet hatten, auf jeden Fall die Pipeline lief auch schon mindestens eine halbe Stunde, was wirklich auch ganz
schön lange gedauert hat, also Pipelines sollten können. Kürzer laufen im Normalfall möglich logischerweise, aber es
war halt schon. Also es kommt natürlich wieder darauf an, wie lange braucht deine Pipeline und wie hochfrequent wird committed, weil wenn du einmal am Tag einen Push machst oder einen Commit machst, dann ist es nicht schlimm, aber wenn du zum Beispiel wirklich mehrmals am Tag vielleicht einmal die Stunde mehrmals in einer Stunde commits machst und jedes Mal die Pipeline läuft.
Dann hast du also dann hatten wir auch schon mal den Moment, dass du hast ja immer so Stages, zum Beispiel, du sagst, du hast Stage 1, sind jetzt zum Beispiel Unit Test Stage 2 sind System Tests und irgendwo bricht der bricht die Integration ab oder zumindest diese Checks Fehlerfall genau die Pipeline meldet rot und sagt Ich kann hier nicht weitermachen und dann war es zum Beispiel so, dass irgendeine andere Partei hat gepusht und wir haben auch gepusht, sagen wir mal 3 Minuten
hintereinander, man spricht sich ja nicht ab. Dafür gibt es ja die Pipeline und dann sind zum Beispiel die Systemtests rot gelaufen und wir wussten aber hinterher nicht, welcher Commit hat denn jetzt also auf den ersten Blick, man muss da n bisschen in den Logs gucken und so weiter was dauert halt, es ist es frisst n bisschen Zeit, aber am Ende war dann erstmal nicht auf den ersten Blick klar, welche Änderungen hat denn jetzt eigentlich diesen diesen Fehler
hervorgerufen? Und das ist dann natürlich da ist sind dann auch ein bisschen Herausforderungen, die auftreten können, und das ist auch ein sehr, sehr wichtiger Punkt, dass man auch wirklich daran denkt und sagt, klar, meine Pipeline läuft vielleicht nicht lange, aber lange ist auch immer die Frage, wie sind die Umstände da, das wollte ich halt auch noch mal irgendwie klarstellen, und dann ist, was mir auch noch einfällt, um jetzt auf den nächsten Herausforderungspunkt
zu kommen, der mir einfällt, sind flaky. Tests Ah ja, gutes Beispiel, also Gute. Gute Herausforderung, nicht Beispiel, Das hat uns schon mal
richtig die Nerven geraubt. Aber also flaky Tests sind ja zum Beispiel, also das sind ja Tests, die sag ich jetzt mal im groben und ganzen richtig funktionieren, also von der Sache her eigentlich das richtige abbilden, aber unter bestimmten Wechselwirkungen mit anderen Tests oder Wechselwirkungen mit anderen Dingen, was auch immer, manchmal rot und manchmal grün laufen, so und. Das ist halt kann durchaus schwierig sein, weil sagen wir mal, diese Situation, die wir gerade hatten.
Einer hat also eine Partei, hat flaky Tests und das heißt so was wie zum Beispiel du lässt lokal, lässt du die deine Tests laufen und das ist grün, die andere Partei lässt auch die Tests laufen, auch lokal Grün, beide pushen, die Pipeline läuft
hintereinander los, kurz. Kurz hintereinander so, dann hast du erstmal Unit Test von von Team a sozusagen oder von Partei A und Unit Test von Partei B, dann unit, dann die System Test von Partei A und dann noch mal die System Tests die durchlaufen diese gleiche Stage von Partei B. Ja. Und jetzt ist aber von einer Partei sind flaky Tests dabei und dann weißt du nämlich gar
nicht mehr okay wie. Wer hat denn jetzt gerade was committed und und unter welchen Bedingungen dann also unter welchen Bedingungen ist denn jetzt diese Pipeline rot gelaufen? Jeder testet bei sich lokal vielleicht und im Best Case, also im Worst Case sozusagen sind auf beiden lokalen Ständen wieder alle Tests grün und beide Parteien denken sich so, wo kommt denn jetzt der Fehler her, du du siehst es weder auf der Pipeline noch siehst du es
lokal. Klar kannst du es dann öfter laufen lassen, aber das ist halt natürlich es ist einfach schwieriger und langwieriger das zu finden. Ja, du kannst. Du kannst ja auch davon ausgehen. Wenn du jetzt also flaky Test noch mal allgemein ne, das kann ja dir schon richtig in die Suppe spucken und selbst wenn du alleine nur integrierst, gehen wir mal davon aus, die Tests sind flaky, weil du irgendwelche Vorbedingungen für deine Tests hast oder vielleicht irgendwie.
Systeme angebunden sind, die zum Beispiel Zeitabhängig sind. Dass du sagst, OK, ich hab timeouts drin oder so und du sorgst einfach nicht dafür, immer die gleichen Gegebenheiten für deinen Test zu haben, so n ähnliches Problem hatten wir ja mal durch Side Effects in der Testumgebung und dann klappt es und sag ich mal jede vierten Durchlauf oder jeder dritte Durchlauf läuft n Test rot weil dann Timeout entsteht.
Beispielsweise. Und dann hast du ja nicht mal unbedingt viele oder mehrere integrieren und dann werden die Tests flaky, weil Änderungen reinkommen, die Site Effects verursachen, sondern du hast vergraben, irgendwo versteckt Dinge, die Site Effects auslösen und die wären nur bei jedem 3.4. Durchlauf sichtbar und das kann passieren. Wir haben das erlebt und. Und dann ist es ja schon.
Du kannst dich hinstellen und sagen, Na ja, gut, dann ist die Pipeline, läuft halt bei jedem vierten Mal rot, dann starten wir es einfach noch mal. Aber das frisst ja un also unendlich Zeit plus du musst immer wieder gucken was ist da passiert und dann stellst du dich ja nicht hin und sagst Ah das ist flaky Test XY wir lassen es einfach noch mal laufen, also
deswegen sollte man sowas. Mitkriegen, unbedingt fixen, das wird sonst richtig übel, irgendwann ja, vor allem, wir lassen es noch mal laufen, ist ja die Frage, wie lange läuft zum Beispiel gerade deine Pipeline richtig und dann sind wir wieder bei der Dauer der Pipeline, weil wenn du sagst, ach komm, wir lassen es noch mal laufen, musst aber schnell was integrieren und die Pipeline läuft aber ne Stunde oder was hast du gesagt ne halbe Stunde da geht halt Zeit ins Land dann
ich hatte. Auch schon ne Pipeline, die lief über 2 Stunden, das war gar nicht cool, hat auch super behindert und da merkst du spätestens an dem Punkt, dass es n richtiger wie nennt man das? Pain in the ass also das ist, das geht gar nicht, ne und da muss man halt was ändern und das ist aber auch also ne andere Story, aber es ist anstrengend die Pipeline zu optimieren oder kann anstrengend sein, sagen wir mal so, es ist durchaus ne Möglichkeit, dass es anstrengend
werden. Kann aber gerade so als Def Ops Team. Was mich da zum Beispiel motiviert bei dem Thema ist, wenn man sich einfach nur vor Augen führt wie viele. Nutzer verwenden diese Pipeline oder integrieren über diese Pipeline.
Und wieviel Zeit kannst du jedem einzelnen Developer dann ersparen, wenn du kleine Optimierung einbaust und wenn einfach nur übertrieben gesagt, die Pipeline ein 2 Minuten schneller ist, dann sind das ja das das das multipliziert sich ja über die Entwicklerinnen und Entwickler und das finde ich ist halt immer ein Grund zu sagen okay wenn wir noch ob also ob. Optimierungspotenzial haben? Dann lohnt es sich immer die Zeit da reinzustecken, auch wenn es vielleicht anstrengend ist
oder wirklich auch kann. Sehr, sehr schwer aus sein, da das letzte Rauszuquetschen an Performance halt. Ne, aber es lohnt sich am Ende definitiv.
Das stimmt und ein ein Punkt würde ich noch gerne sagen, bevor wir jetzt quasi dann bald zum Ende kommen, aber was auch noch eine wichtige Herausforderung ist, ist zum Beispiel, dass man die Umgebung. In auf der Pipeline mit der Umgebung, die man lokal Nutzer Entwicklung gleich hält, weil wenn du zum Beispiel unterschiedliche Abhängigkeiten vielleicht lokal hast und du aber zum Beispiel irgendwie noch andere Skripte hast um irgendwelche Abhängigkeiten auf
der Pipeline, auf der auf der Building Machine was auch immer dazu installieren, also wenn irgendwie deine lokale und die remote, wenn ich es jetzt einfach mal Umgebung unterschiedlich sind. Das ist definitiv nicht ratsam, weil man sollte immer gucken, dass sozusagen die lokale Entwicklungsumgebung unabhängig mehr oder weniger ist, von der wo auch die Pipeline läuft, also dass man sich darum sozusagen nicht kümmern muss. Diese Art von Unabhängigkeit meine ich. Ja, ist halt auch wichtig.
Wenn du jetzt beispielsweise so End TO End Test laufen lässt oder so, dass du halt auch die gleichen sage ich mal mogs hast. Also dass du sagst ich, ich bilde halt meine gleiche Umgebung ab, weil du kannst ja nicht immer gegen echte Drittanbietersysteme gehen, sondern dann wirst du wahrscheinlich irgendwelche Dummies dafür haben und dass du da einfach gleiche Umgebung schaffst. Genau das ist natürlich auch immer zusätzlich ne Herausforderung, das Ganze aufzusetzen.
Aber zahlt sich am Ende oder sobald es läuft sag ich mal recht schnell wieder aus. Und genau also du kommst schnell an den Punkt wo du sagst Gott sei Dank haben wir das.
Gemacht? Ja, auf jeden Fall. Aber wenn wir jetzt an der an dem Punkt sind und sagen, OK klar, soweit können wir jetzt sozusagen den Code integrieren, wir wissen, was die Herausforderungen sind, worauf man vielleicht auch achten sollte, das ist ja der Punkt, wo wir den Code. Bereit haben, wo wir sagen Okay neue Änderungen sind in der Codebasis drin. Sie sind jetzt theoretisch bereit, damit weiterzumachen. Genau, und da kommen wir natürlich zu der Frage, wann
entscheidet man jetzt? Es sind genug Änderungen eingeflossen und jetzt wollen wir quasi eine neue Version der Software an beispielsweise den Kunden ausrollen. Genau, ich denke da möchtest du hin, gedanklich genau. Also es ist. Im Endeffekt kommt ja dann sozusagen noch ein der nächste Step auf die Pipeline, den wir
dann. Dann in der folgenden in einer der nächsten Folgen von von unserem Podcast bzw von der defops Reihe behandeln wollen und da geht es dann im Endeffekt um Continuous Delivery, Continuous Deployment. Das sind ja auch 2 Dinge die gerne mal als Synonym von CD benutzt werden und da wollen wir dann auf jeden Fall darauf eingehen was das ist und was vielleicht auch die Unterschiede
sind genau. Genau, und das wird auf jeden Fall auch noch n richtig spannender Punkt, weil da kann man auch ne Menge zu erläutern und erzählen, weil es auch n sehr wichtiger Bestandteil der Pipeline am Ende ist.
Aber ich würd gern noch mal die Folge zusammenfassen, Fabi, also wir haben ja jetzt über Continuous Integration gesprochen und wir haben ja gesagt, OK, was sind jetzt so die Vorteile, wenn man Continuous Integration quasi umsetzt und ich sage mal auch lebt, weil wir haben ja gesagt, man muss natürlich dann auch kontinuierlich integrieren. Dann sind natürlich die Vorteile, dass man frühzeitig
Fehler erkennen kann. Man hat natürlich ein wenig Integrationsprobleme, weil man einfach regelmäßig integriert und man verkürzt natürlich die Zyklen, das heißt, wie schnell kommen Änderungen rein, der Zyklus wird geringer und auch hinblicklich, was du meintest mit CD wird man natürlich dadurch auch die Release Zyklen, also jetzt wirklich im Sinne von Release verkleinern. Weil ich halt einfach regelmäßige auch Updates rausgeben kann.
Logischerweise, weil wenn ich nur alle paar Monate integriere, kann in der Zeit auch kein Update entstehen. Ja genau genau und das Ganze spielt natürlich in das globale Ziel rein zu sagen, wir möchten eine hohe Codequalität in unserem Produkt oder in unserem Projekt haben und wir Sorgen mit unseren Tests und sämtlichen Tools die noch laufen, also die Checks, dass man einfach eine hohe Codequalität gewährleisten
kann. Genau und eine hohe Automatisierung logischerweise, weil wir wollen natürlich nicht alles das, was wir gesprochen haben, manuell. Jedes Mal checken, sondern es soll dann automatisch passieren. Weil, angenommen, man macht es manuell, wird es die Frequenz der Commits auf jeden Fall wieder drastisch senken.
Ein Commit dauert definitiv. Nach der Entwicklung dauert der Commit vielleicht ein paar Sekunden, aber diese ganzen Checks manuell zu machen, würde vielleicht mehrere Stunden dauern, unter Umständen. Genau und noch einen kleinen Aufruf am Ende. Liebe Zuhörer, liebe Zuhörer, sollst du vielleicht noch nicht so die Berührungspunkte mit den DEF Ops Thema oder mit Pipelines gehabt haben, möchten wir dich an der Stelle natürlich auch motivieren, mal eine eigene
kleine Pipeline zu bauen und auch quasi Continuous Integration in deinen eigenen Projekten zu leben. Und dabei spielt es keine Rolle, ob du alleine bist. Wie groß das Projekt ist, einfach nur mit dieser Arbeitsweise sich vertraut machen und die Vorteile darin sehen und ich denke das sollte auf jeden Fall für jeden förderlich sein, der das. Sich noch nicht angeschaut hat, weil es einfach in der heutigen Softwareentwicklung gang und gäbe ist, mit solchen Pipelines zu arbeiten.
Und ja, fabi, magst du vielleicht noch so ein 2 Tools nennen, womit man das umsetzen kann, also Tutorials findet man ja auf jeden Fall an jeder Ecke, sage ich mal. Ja, also du kannst dafür zum Beispiel. Berühmte Plattformen wie zum Beispiel Github nehmen, da gibt es so eine github Actions, das da kann, das kann man dafür benutzen, ist ja auch ein gutes Beispiel.
Es gibt auch andere Tools wie zum Beispiel Jenkins oder Bamboo, sowas kann man theoretisch auch auf AWS oder Azure in irgendwelchen Cloud Services umsetzen, es gibt auf jeden Fall eine Menge Möglichkeiten Tools zu verwenden, Concurse ist zum Beispiel auch ein Tool was man nutzen kann, was ist auch Open Source glaube ich, aber am Ende ist es ja auch so, dass es es sind. Lösungen, die bestehen, aber rein theoretisch sind das ja nur vorgefertigte Lösungen, was nicht bedeutet, dass es ohne
sowas nicht geht. Also man kann sich ja auch eigene Bashskripte was auch immer zusammenbasteln, die genau das tun. Es ist natürlich einfacher Lösungen zu nutzen, die schon existieren. Nur gerade so für die ersten. Schritte genau, nur was halt wichtig ist, ist, wenn man jetzt zum Beispiel sagt. Mal angenommen, das und das Tool X kann ich nicht verwenden, bedeutet das noch lange nicht, dass CI nicht möglich ist.
Das ist immer noch mal ein wichtiger Punkt oder ein wichtiger Reminder an der Stelle. Genau, Tino Fabi, Ich bin durch. Ich auch. Ich denke, wir haben es ausführlich besprochen, das hat mir auf jeden Fall wieder ne Menge Freude gemacht und ich find das Thema auch super geil, deswegen schön, dass wir darüber gesprochen haben, auf jeden Fall.
Ich freu mich jetzt schon auf die CD Folge auf jeden Fall alles klar in dem Sinne würde ich die Folge einmal abschließen und auf jeden Fall auch an dich liebe Zuhörerin lieber Zuhörer appellieren und sagen, wenn du jetzt sagst Ey, der Podcast ist cool, der bringt. Mir richtig Mehrwert, das ist ne ne tolle Sache und mir macht es voll Spaß diesen 2 Quatschköpfen
zuzuhören. Dann hast du auf jeden Fall die Möglichkeit und zu supporten, zum entweder mit einer kleinen Spende, das wäre super cool oder auch einfach mit Feedback. Ne. Also Feedback funktioniert auch sehr sehr gut über die Podcast Mail einfach die Mail schnappen, links zur Mail und zum Spenden zum Spenden Link ist in den Show Notes definitiv verlinkt, da kommst du dahin und ansonsten lass gerne ein Like da, wenn dir die Folge gefallen hat, oder?
Und wir würden uns auch mega darüber freuen, wenn du den Podcast an 2 deiner Freunde oder Freundinnen empfehlst. Das wäre natürlich eine absolut geniale Sache. In dem Sinne würde ich sagen, sind wir raus für heute und hören uns beim nächsten Mal wieder in diesem Sinne deine Coding Buddies gemeinsam besser.