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.