Latest / Coding Buddies | Tech & Dev-Mindset / DevOps #3 - Vertrauen gewinnen durch Continuous Integration

Transcript

DevOps #3 - Vertrauen gewinnen durch Continuous Integration · Coding Buddies | Tech & Dev-Mindset

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