Latest / Coding Buddies | Tech & Dev-Mindset / Surfen, Salz und DevOps

Transcript

Surfen, Salz und DevOps · Coding Buddies | Tech & Dev-Mindset

0:00
Was ist denn das für ne Scheiße? Wieso geht das nicht?
0:02
Ich rufe jetzt mal den Support an, weißt du als Entwickler
0:05
Entwicklerin schon? Bereits ja.
0:07
Ey, da ist ein Problem, daran arbeite ich mal.
0:10
Bodies Dein Podcast rund um Softwareentwicklung und
0:13
aktueller Tech News. Herzlich Willkommen.
0:27
Einen wunderschönen guten Tag hier zum Coding Bodies Podcast
0:31
mal wieder. Ich bin dabei der Fabi und Tino
0:34
natürlich auch, ist doch klar. Yeah, Hallo Tino, Na was geht
0:39
ab? Endlich wieder Podcast.
0:41
Es geht mal wieder los. Langes her.
0:43
Lang ist her also für unsere Zuhörerinnen und Zuhörer, nicht
0:48
aber für uns schon. Du warst ja im Urlaub, wir haben
0:51
ja quasi vorgearbeitet, die Podcast folgen aufgenommen und
0:56
letzter Sekunde. Immer wieder Rhythmus letzter
0:59
Sekunde. Ja, wie war dein Urlaub, geht es
1:02
dir gut? Ja, voll tiefenentspannt würde
1:05
ich mal so ein bisschen so redet, dann ist das echt voll
1:08
entspannt. Nee, war geil.
1:13
Ich war surfen, ich hab mal surfen ausprobiert, also so
1:15
richtig so in den Wellen und so. O Yeah, erzähl war geil.
1:19
Geht es war geil sogar. Freundlich.
1:22
Tatsächlich schon ganz geil. Also es war ja am Atlantik.
1:25
Also du hast geile Wellen und so, das geht schon ordentlich
1:27
ab, wenn ich mal kurz erzählen soll und so einen Kurs gemacht,
1:31
weißt du ja. Also also richtig mit dem Surf
1:35
Lehrer so. Ja genau.
1:36
Surf Camp, also 5 Tage so einen Kurs und auch selber mal Board
1:41
ausgeliehen und dann. Surfen und die Wellen am
1:44
Atlantik sind ja meistens ziemlich geil.
1:46
Ist ja nicht so Mittelmeer oder so und teilweise ganz am Ende
1:50
wurden gefühlt über die Zeit wo ich da war einfach immer größer.
1:54
Also am Ende waren es einfach riesen Brecher, da fühlt sich
1:56
irgendwann auch so, es war auf jeden Fall ganz geil, weil der
2:00
Surf Kurs war cool, hat Spaß gemacht, ich konnte auch
2:02
hinterher stehen, ich hab auch richtig ne Welle geritten und
2:05
das war schon geil, hat schon Bock gemacht aber faraway vom so
2:10
richtig geil sein also wenn ihr da manchmal Surfer gesehen hast
2:12
du surferin. Ey, alter Schwede, so geil.
2:15
Sieht richtig cool. Aus ne.
2:17
Ja, aber wie gesagt, also ein paar große Wellen bin ich auch
2:20
gefahren oder geritten oder gesurft wie bei der Sommer nennt
2:23
und. Also ist auf jeden Fall geil.
2:26
Das Schwierigste ist, finde ich, gar nicht mal aufstehen, sondern
2:29
das Timing war ne Welle nimmst hab ich herausgefunden.
2:33
Wenn du zu spät oder zu früh ne Welle nimmst, dann kommst du
2:36
wieder nicht drauf. Oder willst du einfach nur über
2:37
gemäht von diesem, weil da sind so ein paar Feinheiten dabei,
2:42
aber ganz ich hab ein so ein Ding genommen und keine Ahnung,
2:45
ich war super schnell 200 KMH mindestens mindestens es ging so
2:50
ab aber. Ist schon in der Ostsee
2:52
angekommen sind. Ja, wir waren.
2:57
Reicht ja auch aufs Meer raus. Weißt du nicht so?
3:00
Genau herrlich. Aber ich hab, ich hab mal
3:05
gehört, dass eigentlich das auch am Anfang super anstrengend sein
3:08
soll wegen diesem Ganzen raus paddeln, das also auf dem Brett
3:11
liegen und raus paddeln super anstrengend sein soll.
3:14
Ich hab ja selbst noch nie gemacht, aber hast du das auch
3:16
so wahrgenommen oder? Ja, also am Anfang nimmst du
3:19
halt dein Board neben dir und gehst halt so im flachen
3:22
Gewässer. Und wenn du aber dann später so
3:24
ein bisschen nach dem, was ich so am Ende der.
3:27
In der Zeit habe ich dann auch bin ich auch sehr viel
3:29
gepaddelt, wie du gerade meintest und ist anstrengend,
3:33
also für die Schultern und was ich auf jeden Fall gemerkt habe,
3:35
ich voll krass fand war mein Regenbogen hat unglaublich viel
3:37
getan weil du liegst die ganze Zeit auf dem Board mit dem Bauch
3:42
und guckst du nach oben so weißt du vorne bist du oben und dann
3:45
paddelst du oder chillst du so. Und wenn du wartest, halt voll
3:50
oft darauf zu wählen, da so gut weißt du, der verpasste eine und
3:53
denkst dir so scheiße. Schon wieder verpasst?
3:55
Auf jeden Fall tut der Rippen bogen Menschen w muss ich sagen.
3:58
So also das ist ne Sache wo ich mir dachte was geht eigentlich
4:00
ab aber ja es ist auf jeden Fall anstrengend, auch wenn du im
4:04
Wasser bist. Ja, ich glaube, dass das auch
4:09
bisschen lernen durch Schmerz ist.
4:11
Am Anfang wahrscheinlich ne. Also ich stelle mir jetzt, wir
4:13
hatten ja gleich in der allerersten Folge n bisschen
4:16
übers Snowboarden geredet, ich würde sagen, da gibt es schon
4:19
parallelen oder dass das also. Quasi die Lernkurve.
4:23
Schwierig ist also, dass man wirklich eine Weile braucht, bis
4:26
man sagen kann, OK, jetzt o jetzt konnte ich mal aufstehen
4:29
oder jetzt hab ich wirklich mal geschafft, auf einer Welle zu
4:31
reiten, das geht ja wahrscheinlich nicht innerhalb
4:33
von einer halben Stunde würde ich mir das jetzt vorstellen,
4:35
halt ne du. Brauchst für ein paar Tage so,
4:37
aber am Ende kannst du also es ging schneller als ich dachte,
4:41
aber am Ende ist es trotzdem halt sag ich mal die
4:43
Schwierigkeit welche Wellen da sind, also kleinere Wellen und
4:45
so weiter also das ist ein bisschen eine Sache für sich,
4:48
aber ich hätte gedacht, dass es schwieriger zu lernen.
4:52
Und um deine Frage doch mal so wisst ihr das Statement zu
4:56
beantworten? Also Snowboarden lernen tut auf
4:59
jeden Fall trotzdem noch mehr w. Ja, Gott sei Dank.
5:03
Gott sei Dank ist es nicht noch schlimmer, weil dann, weil ich
5:06
eigentlich auch mal das auszuprobieren, zu surfen habe.
5:09
Also ich kanns als Snowboard bitte nicht, nee, also.
5:13
Zusammenzufassen, das macht Mega Bock, kann ich nur jedem
5:16
empfehlen, der irgendwie auch so Board affin ist und Bock drauf
5:19
hat. Also das macht Spaß, ist cool.
5:21
Ist geil, ja. Coole Sache.
5:23
Wenn du Bock hast, die Nase durchzuspülen.
5:26
Ja, was passiert wahrscheinlich? Sehr, sehr viel, ja.
5:32
Ja, schön, dass du auf jeden Fall wieder da bist, dass du gut
5:34
erholt bist, gesund bist, dass du dich nicht verletzt, ist ja
5:37
auch wichtig, ja. Mein neues Lieblingsgetränk ist
5:40
Salzwasser auf jeden Fall das. Muss Wasser ja schön schön Glas
5:43
Salzwasser. Ist auch super eklig, aber
5:47
scheiß drauf also. Auf jeden Fall auf.
5:49
Jeden Fall eine Menge Salzwasser in meinem meinem Mund Magen
5:52
überall. Ich glaub ich wollte halt.
5:54
Ja, ich liebe Salz. Jetzt ja, es ist einfach dein
5:57
Ding. Sehr gut.
5:59
Ja gut, ja, worüber? Wollen wir denn eigentlich heute
6:03
sprechen? Ich mein, wir können jetzt die
6:05
Folge beenden und das nennen, Fabi lernt surfen, das ist.
6:08
Auch nicht schlecht, auf jeden Fall.
6:11
Ja, ja, gut eigentlich. Wichtigen Thema raus.
6:15
Genau, eigentlich. Wollen wir mal ein bisschen YK,
6:18
also was so devops ist, hört man ja öfter mal so in letzter Zeit
6:23
beziehungsweise ist ja auch ein sehr etabliertes Modell.
6:25
Mittlerweile, und das wollen wir beleuchten, weil wir ja auch in
6:30
der PS Team arbeiten, ne genau da.
6:34
Können wir ja natürlich dann auch perfekt Bezug zu unserer
6:37
eigenen Arbeitswelt nehmen, sag ich mal.
6:39
Und auch daran, dass so ein bisschen erläutern, erklären,
6:42
was die Vorteile sind und warum man überhaupt nach diesem Modell
6:45
arbeitet. Ne, genau.
6:47
Ja, ja, also der ist ja im Endeffekt so was.
6:51
Woraus setzt sich das zusammen, wir raus, was ist denn, was ist
6:54
denn der Ops? Dev Ops ja, im Prinzip ist es
6:59
ein zusammengesetztes Wort, also death ist im Prinzip das
7:05
Development Team, also die Entwickler der Software.
7:08
An sich sage ich mal und ob es steht für Operation wenn ich
7:13
mich jetzt nicht. Irre Operation?
7:14
Genau. Operations und ist im Endeffekt
7:17
ja der IT Anteil ne und es geht halt darum, dass quasi die IT
7:25
Leute und die Entwickler an sich.
7:27
Mehr zusammenrücken und näher zusammenarbeiten, um einfach
7:30
eine bessere Infrastruktur auch bereitzustellen oder
7:32
beziehungsweise eine bessere Bereitstellung der Software.
7:35
Weil du kannst es ja theoretisch sogar noch soweit, sag ich mal
7:39
treiben, dass du sagst, OK, die Leute machen beides
7:42
gleichzeitig, also sozusagen Entwicklung der Anwendung und
7:46
gleichzeitig den Betrieb, also die Operations diese Anwendung
7:49
machen, also das sozusagen nicht mal 2 Teams groß, also sozusagen
7:52
nicht mal 2 Rollen das übernehmen, sondern dass eine
7:55
Person beide Rollen übernimmt, weißt du?
7:58
Kannst du ja auch soweit gehen. Also ja genau, also es geht ja
8:02
wirklich darum, dass näher zusammenzuführen.
8:04
Wie nah ist natürlich dann einfach wieder projektabhängig
8:08
jetzt sowohl Entwickler bist als auch quasi die IT Infrastruktur
8:12
bereitstellt. Genau genau weil wir meinten wir
8:15
nehmen Bezug zu unserer Arbeitswelt kann man ja sagen,
8:19
dass wir wirklich beides sind, vielleicht kommst du, bist du
8:22
deswegen jetzt auf diesen Punkt gekommen, also wir entwickeln ja
8:25
sowohl Software als auch die Infrastruktur dahinter Software
8:29
bereitstellen zu können, also das ist quasi die.
8:33
Nächste Form von devops? Genau.
8:37
Also das habe ich jetzt zum Beispiel auch vorher gemacht und
8:40
schön, dass wir jetzt auch weitermachen können, weil es
8:42
halt auch, glaube ich ist ne ganz, ganz coole Sache, so vor
8:45
und Nachteile können wir auch noch mal eingehen, aber auch mal
8:48
so ein bisschen grob abzureißen, so was umfasst denn also
8:52
Development ist irgendwie klar, würde ich jetzt einmal sagen, OK
8:55
was Entwicklung wie Entwicklung und so haben wir auch ne Menge
8:58
darüber gesprochen, wenn wir uns jetzt mal ein bisschen
9:00
Operations Teil konzentrieren, so ne was halt so.
9:03
Sag ich mal. Wichtige Bereiche von der
9:06
Operation sind, das wäre ja mal interessant zu zu beleuchten.
9:12
Ja, also. Prinzip finde ich, sind so die
9:16
Kernpunkte. Sind zum einen die
9:18
Automatisierung dahinter und worauf wir auf jeden Fall
9:23
eingehen sollten, weil es einfach echt überall
9:26
mittlerweile zu lesen ist. Ist so dieses typische Stichwort
9:29
CICD. Genau, ja, das gehört ja quasi
9:33
so ein bisschen. Zusammen genau da mit rein, das
9:35
ist irgendwie Automatisierung ne was mir zum Beispiel auch sehr
9:38
wichtig ist, zum Beispiel so als als zweiten großen Punkt würde
9:42
ich mal sagen, Monitoring und Feedback, dass man halt also
9:46
angenommen, weil wir haben ja zum Beispiel auch mal darüber
9:49
gesprochen, dass man, dass wir Test driven development machen,
9:52
also noch TD arbeiten und man kann jetzt sagen, ja OK, geht ja
9:58
nichts mehr schief, machst ja TD ne, aber das ist ja nun leider
10:01
Gottes auch nicht hundertprozentig so, also es
10:03
schleichen sich immer irgendwie Fehler, es können immer
10:05
unerwartete Punkte, oder? Verhalten der Software auftreten
10:10
und wichtig an der Stelle ist es halt an dieser Stelle halt ein
10:14
gutes Monitoring der Anwendung zu haben und eine gute Feedback
10:17
Schleife zu haben, die im Endeffekt relativ schnell, also
10:21
egal wie das aussehen mag, ne, aber sagen wir mal.
10:25
Ein Fehler wird erkannt und wird innerhalb von kürzester Zeit,
10:28
also sagen wir Minuten an das Entwicklerteam oder an das Team
10:31
hat wieder. Zurückgeführt?
10:32
Ja, da sind wir natürlich wieder beim Stichwort agiles Umfeld,
10:36
ne, wir haben ja auch schon mal über agile Arbeitsweisen
10:39
gesprochen, ja, und da war ja auch der Punkt, dass man
10:42
schnelle Feedback Zyklen haben sollte, um schnell quasi zu
10:47
sehen, ob das jetzt alles läuft oder nicht, hat gesagt ne und
10:51
das spielt natürlich jetzt auch rein, also finde ich.
10:55
Sollten wir auf jeden Fall zweiten Punkt nehmen.
10:57
Also das heißt einmal die ganze automatisierungs Geschichte.
11:00
Was ist eigentlich CICD? Ja, und danach können wir ja
11:03
dann nochmal über Feedback und ja Monitoring reden, das sind
11:06
doch 2 ganz coole Punkte um das ganze Thema mal lockeren
11:10
Einstieg da drin zu haben, oder? Ja, wollen wir noch vielleicht
11:13
noch einen Kurzen, das müssen wir nicht lange beleuchten, aber
11:15
vielleicht noch ganz kurz den dritten Punkt, am Ende dann
11:17
nochmal mit reinnehmen, weil zum Beispiel wenn du jetzt, wenn wir
11:21
also du hattest auch Infrastruktur geredet und
11:24
Infrastruktur. Ist an der Stelle interessant
11:28
und wichtig zu sagen, dass man das Halt als also IAC
11:31
Infrastructure as Code hat. Was genau das ist, können wir
11:35
einmal kurz, dann auch nochmal. Besprechen.
11:40
Aber das ist halt. Ja, ja, ja.
11:41
Klar können wir noch kurz anreißen, glaube ich, dass die
11:44
Richtung Skalierbarkeit ja hat vielleicht.
11:46
Auch ein bisschen ist ja auch, geht auch irgendwie Hand in Hand
11:49
mit Automatisierung, irgendwie, aber wie gesagt.
11:53
Können wir nochmal drüber quatschen?
11:55
Ja, machen wir mal fahren, dann weiß ich Bescheid, worum es, was
11:59
wir jetzt tun. OK, ja gut, dann lass uns doch
12:02
einfach mal anfangen mit Automatisierung CICD erklär doch
12:07
mal bitte für unsere Zuhörerinnen oder Zuhörer, was
12:11
wofür steht denn CICD und was hat das mit Automatisierung zu
12:14
tun? Genau, also CICD steht auf jeden
12:18
Fall also für Continuous Integration.
12:22
Also das CI ne, also. Beziehungsweise wenn es jetzt
12:25
auf Deutsch übersetzt, kontinuierliche Integration, das
12:28
heißt, es geht darum, dass du sozusagen dein Code, den du
12:32
schreibst, kontinuierlich in deine Code Basis integrierst,
12:37
also zum Beispiel, es gibt ja Repositories, ne, wenn du zum
12:41
Beispiel mit oder SVN verschiedene Arten kannst du
12:44
nehmen gibt, ist ja ein sehr weit verbreitetes Repository und
12:51
um sozusagen arbeitenden Code machst du sagen Änderung.
12:54
Und willst kontinuierlich regelmäßig deinen Code, den du
12:58
geschrieben hast, der Neues in die gesamte Code Basis, wo er
13:02
verschiedene Entwickler innen arbeiten integrieren?
13:05
Ne, ja, das ist jetzt muss ich kurz einhaken.
13:07
Was heißt denn für dich kontinuierlich regelmäßig, also
13:11
über welche Intervalle reden wir denn dabei?
13:13
Das ist ein guter Punkt, also den finde ich richtig geil.
13:16
Gerade, dass du ihn ansprichst, weil das ist, glaube ich, auch
13:19
ein sehr wichtiger Punkt. Also ich würde bei einer
13:21
kontinuierlichen Integration ja eigentlich schon.
13:24
Erst an täglich oder mehrmals täglich, die den Code in die
13:28
Code Basis und integrieren reden einfach damit man quasi kleine
13:32
Steps verändert und sozusagen wenn man dann irgendwann wieder
13:35
bei Monitoring ist relativ schnell auch ne sag ich jetzt
13:38
mal sieht OK können wir gleich nochmal drüber reden, aber dass
13:41
du relativ schnell weißt OK vielleicht geht irgendwas
13:44
schief, ne, dass du aber relativ schnell weißt OK um welchen Code
13:48
geht's denn hier wenn du ein halbes Jahr lang irgendwas
13:50
entwickelst und das dann alles rums Riesending schmeiß rein in
13:53
die Code Basis machst dann. Dann weißt du ja vielleicht gar
13:57
nicht mehr. Also wenn wir jetzt gerade bei
13:58
großen Releases sind, was ja viele auch, was man oft hört.
14:04
Dann weiß. Vielleicht gar nicht mehr.
14:06
Welcher Part eigentlich deiner Änderung quasi jetzt den Fehler
14:10
verursacht, das ist ja auch genauso das Thema.
14:12
Wenn du jetzt verschiedene Features implementierst, macht
14:16
es natürlich keinen Sinn mehrere Features zu implementieren und
14:20
dann zu integrieren, sondern wie du schon meintest täglich, also
14:25
in Best Case, sollte so ein Feature was man sich zieht ja
14:28
auch nicht. Wochenlang dauern, dass du
14:30
implementieren, weil dann ist einfach zu groß und müssen fein
14:33
granularer beschrieben werden. Aber sagen wir mal ein 2 Tage,
14:39
dann kann man natürlich sagen, OK ich entwickele das Feature
14:42
fertig schreiben n Test zum Beispiel dafür, für mich läuft
14:45
das Ding jetzt nicht integriert das und guck mal was für ein
14:48
Feedback ich dadurch bekomme von der gesamt Software sozusagen ne
14:51
also von meinem von meiner Infrastruktur noch besser ist
14:55
natürlich das Feature in Teilbereiche unterteilen und die
14:58
Einzelnen zu integrieren um zu gucken.
15:00
Läuft es denn bis zu dem Punkt, zu dem ich entwickelt habe?
15:04
Da bin ich auf jeden Fall ganz bei dir.
15:06
Es gibt leider auch viele Entwickler, die das nicht so
15:08
sehen, haben wahrscheinlich vielleicht auch Argumente, warum
15:12
man das nicht so machen sollte, aber ich versteh s halt einfach
15:15
nicht, warum ich wochenlang entwickeln sollte um dann
15:18
vielleicht zu erkennen, dass irgendwas falsch läuft.
15:20
Genau also das Hauptproblem, wenn man es mal so beleuchtet,
15:23
finde ich es ja, dass du dann dich hinstellst und sagst, OK,
15:27
es gibt ein riesen Release und man hört ja so davon o nein, es
15:30
ist Release und hoffentlich geht alles gut.
15:32
Und so. Aber wenn du quasi jeden Tag ne
15:34
Art von Release hast, ne, also sozusagen eine Release Probe
15:37
jeden Tag, dann ist ein normaler Release so.
15:40
Keine Ahnung. War gerade ein Release, ich weiß
15:42
es nicht, keine Ahnung Daily Business so ne und da muss
15:45
eigentlich sag ich jetzt mal meiner Meinung nach aber deiner
15:49
Meinung ja auch hingehen ne aber du hast noch.
15:52
Ja genau, weil wenn du einfach mal den worst case anguckst, ne
15:56
worst case im Prinzip nach unserer Methode.
16:00
Dass ein Tag Arbeit diesen Fehler verursacht hat.
16:03
Also es muss innerhalb der letzten Änderung ja drin sein,
16:07
weil vorher war ja alles in Ordnung, richtig jetzt 2 Wochen
16:10
lang entwickeln, also wirklich 2 Wochen an dem Code arbeite,
16:14
woher soll ich jetzt noch so schnell sehen, welcher Teil
16:19
meiner Änderungen jetzt den. Fehler verursacht genau also das
16:22
ist aber auch n interessanter Punkt, weil jetzt müssen wir
16:25
noch ein bisschen trennen, weil und das CI, also die Continuous
16:29
Integration zählt ja das integrieren.
16:31
Also deines Codes in die Code Basis und zusätzlich soll
16:34
natürlich auch der Code nur integriert werden, wenn alle
16:37
Tests grün sind. Ne, das heißt du hast auf deiner
16:39
CICD Pipeline im CI teil hast du den Bereich, dass quasi alle
16:44
Tests laufen und wenn alle Tests grün gelaufen sind sag ich jetzt
16:48
mal dann können wir einen Schritt weitergehen, es wird
16:50
quasi der Code wird integriert, der Code wird getestet und dann
16:53
können wir weiter zum CD Teil gehen, das Ding ist dieser C
16:56
teil sozusagen das Fehler wirklich auftreten können weil
17:00
ja sozusagen also. Komme gleich auf CD, also
17:03
Deployment bedeutet ja sozusagen die Bereitstellung, dass deine
17:06
Änderungen halt eben auch wirklich an Mann und Frau
17:09
kommen, sozusagen ne also an den Anwender, an den User, weil die
17:11
Userin und dann ist es ja so, dass wir gesagt haben, es kann
17:17
ja durchaus sein, also sagen wir mal den Test laufen rot, OK,
17:20
dann wird es nicht bereitgestellt, dann wird es
17:22
nicht deployed, fährt ja gut, also ich war.
17:24
Jetzt gedanklich auch nicht beim Deployen.
17:25
Aber mal angenommen, ich stelle meine Änderungen halt erst nach
17:30
2 Wochen bereit, dann sind das halt extrem viele Änderungen.
17:33
Und dann laufen hat verschiedene Tests rot und dann denkst du so
17:36
hm. Ja, genau, aber genau.
17:37
Und deswegen wollte ich mal diese 2 diese Trennung machen,
17:40
wenn deine Tests rot laufen, dann hast du natürlich zumindest
17:42
schon mal einen Anhaltspunkt zu sagen, ey OK, der Test und der
17:45
und der läuft rot, es kommt nicht mal an den User, was ja
17:48
schon mal gut ist, dass fehlerhafter Code nicht an oder
17:50
kommt, das heißt du kannst erstmal ganz entspannt deine
17:53
Sachen irgendwie regeln dauert natürlich gebe ich dir total
17:55
recht, aber du hast natürlich den Punkt, dass du sagst, OK,
18:00
ich weiß aber trotzdem schon, ich hab Anhaltspunkt, aber wenn
18:02
wir jetzt an den Punkt kommen, dass wir sagen OK.
18:04
Alle Tests laufen grün, weil wir am Anfang auch gesagt hatten,
18:07
OK, es kann ja durchaus sein, du hast Tests, alles cool, du
18:11
arbeitest programming nach TD, warum?
18:13
Es kommt trotzdem irgendwie ein Fehler rein ne deine Tests
18:16
laufen grün. Irgendwas wurde übersehen, kann
18:18
passieren, wird definitiv passieren.
18:20
Da brauchen wir gar nicht genau, brauchen wir gar nicht irgendwie
18:22
drüber streiten, aber dann wird es deployed und jetzt sind wir
18:26
erstmal CD ne, hatten wir schon gesagt so die also das was quasi
18:32
dieser dieser Stand der gerade ne gebaut wurde wird sozusagen
18:37
dem User zur Verfügung gestellt ne und da ist jetzt ein Fehler
18:42
drin so. Und das wurde nicht erkannt.
18:45
Das ist ja sozusagen jetzt noch ein ganz anderer Punkt, und da
18:47
könnte man jetzt von ausgehen, dass man sagt Okay machen
18:49
Release ne riesen Änderungen, läuft alles grün vielleicht mal
18:53
werden natürlich noch besser. Was denkbar ist.
18:57
Das stimmt so. Und dann sind wir an dem Punkt,
19:01
dass wir dann diesen Fehler, der erstmal muss erkannt werden,
19:05
weil wir wissen ja nicht, dass er da ist, normalerweise, sonst
19:08
würde man ihn nicht raushauen. Das heißt, er muss erstmal
19:11
erkannt werden und wenn er dann erkannt wurde, musst du noch
19:13
wissen, OK, wo kommt das jetzt her.
19:14
Ne hast keine Tests dafür alle Tests laufen grün, hast keinen
19:17
Anhaltspunkt und dann hast du ein Problem, ne?
19:20
Aber das ist ja auch wieder, das spielt ja in die gleiche
19:23
Richtung, ne, also klar, wenn wir jetzt vom Deployment
19:26
ausgehen, macht es ja Sinn kleine Änderungen auch
19:29
regelmäßig zu deployen um zu sehen ob das im Feld, also im
19:33
Feld quasi beim Kunden sag ich mal also ob, ob da jetzt
19:38
irgendwelche Bugs reinkommen oder nicht, macht ja auch
19:41
kleinere Änderungen schnell zu deployen und dementsprechend
19:44
müssen diese kleineren. Änderungen auch schnell
19:47
integriert werden, weil wenn ich jetzt keine Ahnung, ich sag OK
19:50
es gibt ein neues Release und das ist n Major Release, das
19:53
heißt es sind komplette Änderungen drin, das ist nicht
19:55
mehr kompatibel, meinetwegen zur alten Version, also was alles
19:58
passieren kann ne und du hast du raus und kriegst halt wirst halt
20:02
überflutet mit irgendwelchen Fehlermeldungen also berichten
20:05
Fehler berichten ja Kunden sagen hier läuft nichts mehr eine
20:08
Stern also ein stern Bewertung so weißt du du denkst hä weißt
20:13
du wie was ist passiert so ne und das ist halt immer die
20:16
Gefahr und deswegen. Macht es Sinn?
20:19
Und dafür steht ja auch, dass kontinuierlich in kleinen Zyklen
20:22
zu integrieren und auch zu auszuliefern, also Deployment
20:26
Delivery, wie man es übersetzen möchte, ne.
20:28
Manche nennen das, Glaube ich, sogar Baby Steps.
20:30
Klingt immer ein bisschen bescheuert.
20:32
Ja, aber das ist also bin ich auch Verfechter davon.
20:34
Klar, du musst jetzt nicht, keine Ahnung, du machst jetzt in
20:37
der Oberfläche ändern der Farbe von Text oder so, das musst du
20:40
jetzt vielleicht nicht sofort raushauen, kannst vielleicht
20:42
warten noch andere drin, ist aber an sich, wenn der neue
20:46
Funktionalität reinkommt. Ein Haus.
20:49
Ja, aber wenn kannst ja mal zusammenfassen.
20:51
Punkt Automatisierungs ICD. Also wenn ich jetzt zum Beispiel
20:54
als Entwickler ne Fabian möchte, jetzt danach arbeiten, was
21:00
passiert dann? Also ich hab jetzt n kleines
21:02
Feature fertig, hab meinen Tag beendet was passiert dann kannst
21:05
du ja vielleicht zusammenfassen wie das in der also bei uns ist
21:09
beziehungsweise wie genau also bei uns ist es ja so aber auch
21:12
quasi im Endeffekt so diese Automatisierung CD wie das so
21:16
was jetzt genau passiert. Kannst ja mal kurz nochmal
21:19
zusammenfassen, damit man das nochmal so als.
21:21
Also im Endeffekt läuft es ja so, dass du dir quasi den
21:24
aktuellen Stand der Software ziehst, jeden morgen ne weiß
21:27
keiner sein, dass Änderungen gekommen sind.
21:29
Das heißt du willst ja immer von vom neuesten Stand anfangen zu
21:34
entwickeln, sonst kaufst du dir einfach Probleme ein, dass du
21:37
halt schon veraltet bist, was unnötig wäre zu dem Zeitpunkt wo
21:41
du anfängst zu entwickeln. Möglicherweise wird Konflikte,
21:43
warum man. Zum Beispiel kann man ja auch
21:45
mal ne andere Folge darauf eingehen.
21:47
Auch kann auch sehr problematisch.
21:48
Wenn sowas. Genau dann fängst du an,
21:53
Features zu implementieren. Und da wir ja davon ausgehen,
21:55
alles läuft super, ist der Umfang natürlich an dem Tag
21:58
schaffbar. So am Ende hast du deine Tests
22:02
geschrieben, das Feature läuft lokal bei dir auf deinem eigenen
22:05
PC Check und alles super, alles grün so und dann sagst du OK
22:10
jetzt möchte ich meine Änderungen einchecken, das heißt
22:14
zur Verfügung stellen für andere Entwickler oder beziehungsweise
22:17
in die Software einfließen lassen, dann machst du wir
22:20
arbeiten mit Geld dann comites. Dass das heißt, du stellst das
22:24
bereit. So, und dann laufen quasi in
22:28
unserer sogenannten Pipeline Services los.
22:31
Dies quasi erkennen. OK, es gibt eine Änderung an der
22:34
Software, das schau ich mir mal an auf gut Deutsch, das heißt es
22:40
wird angefangen, diese Software wird gebaut, also ausgecheckt
22:44
wird gebaut, die Tests laufen, alles grün OK es ist alles grün
22:48
hier super ne ja vielleicht auch noch ein größerer Test Umfang
22:53
als die lokalen Tests, das ist dann halt immer n bisschen
22:55
Pipeline abhängig ne man lässt. Je nachdem, wie lange es dauert.
22:58
Vielleicht nicht alle Tests lokal laufen, sondern lagert das
23:01
dann halt auf dem Server aus, sozusagen ne genau genau und
23:05
wenn alles grün ist, ist quasi die Integration abgeschlossen.
23:10
Genau also CICDCI sorry, CI ist ja quasi dann im Endeffekt
23:14
integrieren in ins Repo und die Tests laufen so.
23:17
Genau. Also man kann sagen, das war
23:19
erfolgreich. Es ist in das Repository
23:21
integriert, die Änderung ist jetzt auf dem Server sozusagen
23:25
ne, also auf der Code Basis für alle.
23:27
Und dann würde ja der CD teil starten.
23:30
Das heißt, du möchtest jetzt diese neue Software Version, die
23:34
dadurch entstanden ist Fasi ausliefern?
23:37
Genau. Dem User zur Verfügung stellen.
23:40
Genau das heißt, du baust dann die Software, je nachdem in
23:44
welchen Bereich man sich entwickeln B befindet, stellt
23:49
Installer bereit, keine Ahnung, automatische Updates You Name
23:52
It, wie auch immer. Website wird aktualisiert.
23:56
Genau, oder? Die Website wird aktualisiert,
23:58
wenn es jetzt wirklich n Frontend ist, also da.
24:00
Jetzt 1000 Bereiche jedenfalls. Das Ziel ist, dass am Ende, wenn
24:04
der CD teil durchgelaufen ist, diese neue Version der Software
24:09
ausgeliefert ist. Das heißt der Kunde.
24:12
Geht auf die Website. Sieht die Änderungen.
24:15
Der Kunde startet meinetwegen die Software und kriegt eine
24:17
Benachrichtigung, dass neue Version da ist.
24:19
Ob er updaten möchte, wie es dann halt auch immer aussieht,
24:22
aber das ist ja das Ziel schnell danach quasi diese Änderungen
24:26
auch ausliefern zu können. Genau also.
24:28
Ist es ja bei uns quasi. In unserer Arbeitswelt mit
24:32
unserer Software ist es ja so, wenn wir das Ganze quasi
24:35
delivered, kriegt der der Anwender eine Benachrichtigung
24:38
beim Start der Software oder halt auch zyklisch.
24:41
Hey, es gibt gerade eine neue Version reingekommen, möchtest
24:44
du updaten? Genau, also im Endeffekt kann
24:47
man sich das ja, wenn man das jetzt mal ganz zusammen stampfen
24:50
will. Tino schreibt n Feature zum
24:54
Beispiel eine neue Page für die Anwendung Page X gibt es schon.
24:58
Es gibt jetzt ne Page y und dann nachdem sozusagen CICD alles
25:04
fertig ist, kann ich als Anwender beispielsweise mich
25:07
hinsetzen und diese Page y aufrufen.
25:10
Genau, genau, ja geil das halt relativ zeitnah nach der
25:15
Entwicklung dieses dieser Page. Genau, also man sagt ja so ne
25:18
CICD Pipeline sollte im schönsten Fall vielleicht sagen
25:23
wir mal nicht länger als eine halbe Stunde laufen.
25:25
Das heißt, wenn du etwas raus haust in einer halben Stunde hat
25:30
der User das und das ist natürlich genau das ist
25:32
natürlich geil und jetzt hattest du ja auch schon mal ein
25:35
bisschen darüber gesprochen, dass du sagst, ja, OK, Moment,
25:38
wäre ja blöd, wenn du jetzt irgendwie Anwendung hast und die
25:41
Anwendungen hat dann irgendwie n.
25:45
Problem Fehler fliegen. Kriegst einen Stern irgendwo in
25:48
der Bewertung und denkst oh scheiße so das wäre natürlich
25:52
blöd ne das heißt hier würde ich jetzt sagen können wir ja mal
25:55
das Monitoring und Feedback mit Reinschmeißen weil angenommen
25:59
wie wir vorhin meinten OK es wurde was übersehen Tests sind
26:02
grün es wird deployed obwohl n Fehler da ist, dann ist es
26:06
durchaus natürlich sinnvoll zu sagen es kommt vor es kann
26:11
vorkommen und es wird vorkommen dass du aber.
26:15
Als Entwickler Team super schnell darauf reagieren kannst.
26:19
Das heißt zum Beispiel irgend ne Anfrage von deiner App
26:24
beispielsweise wird irgendwie bearbeitet und s fehlerhaftes
26:27
heißt irgendwie fliegt ein Fehler an deinem Backend
26:29
beispielsweise ne, dann wäre es im Optimalfall schön, dass
26:35
sozusagen du irgendwie als Entwickler da sitzt, ganz
26:37
entspannt arbeitest und auf einmal kriegst du in irgendeinem
26:41
Nachrichten Channel, sei mal hingestellt, was für einen
26:43
Nachrichten Channel das ist. Kriegst du eine Nachricht?
26:45
Besteht Moment, hier ist gerade ein Fehler geflogen in der
26:48
Anwendung und dann denkst du dir so OK, das heißt bevor der User
26:52
sich noch sagt, was ist denn das für ne Scheiße, wieso geht das
26:54
nicht? Ich rufe jetzt mal den Support
26:56
an, weißt du als Entwickler Entwicklerin schon bereits ey da
27:00
ist ein Problem, daran arbeite ich mal ne also das ist
27:03
sozusagen sofort also und hier geht es wirklich darum, dass um
27:07
sofort geht es um Minuten ne also im Optimalfall fliegt
27:11
irgendwo ein Fehler in der Anwendung und da muss hingehen
27:14
ne also nicht dass du sagst ja aber das wäre ja optimal.
27:17
Sondern das ist eigentlich die Anforderung, dass du sagst,
27:19
irgendwo fliegt ein Fehler in der Anwendung und als obs im
27:23
Obst teil kümmerst du dich darum, dass du sagst, OK, meine
27:27
Anforderung ist, dass ich Minuten nach diesem Fehler, der
27:30
aufgetreten ist, als Entwickler Team weiß, da ist dieser Fehler.
27:34
Ne, das ist sozusagen dieses diese Art von Monitoring, die
27:39
man im Endeffekt für seine Anwendungen bereitstellen
27:42
sollte. Ne, also wenn man sagt ja OK,
27:45
vielleicht geht das nicht, bei mir geht das nicht, die Frage
27:48
ist eher, wie schafft man es, dass es genau so schnell geht,
27:52
weißt du? Ja, da geht es ja natürlich dann
27:55
auch um Verfügbarkeit, ne und ich sag mal so, wenn dein
27:58
Service ausfällt, den du vielleicht bereitstellt oder wo
28:00
Kunden darauf angewiesen sind, ist es natürlich auch ganz
28:03
schnell eine Frage von Geld. Ja, also im Sinne von jede
28:07
Minute, die du offline bist, kostet dem Unternehmen.
28:10
Geld? Na, das ist ja.
28:12
Oftmals dann der Fall und deswegen ist dieses Feedback und
28:15
das Monitoring so enorm wichtig, weil klar, wir haben die
28:19
Pipeline aufgebaut, das heißt, wir könnten schnell den Fehler
28:22
finden, richtig, also ihnen fixen es integrieren und
28:26
deployen. Genau das heißt, wenn du es
28:28
wirklich schnell findest, den Fehler kriegst, vielleicht nicht
28:31
unbedingt mit, dann war halt die Software 30 Minuten lang
28:33
fehlerhaft und dann ist die neue Version schon draußen.
28:36
Ja, oder die Down Time deiner Anwendung ist halt vielleicht ne
28:39
Stunde, aber nicht eine Woche lang.
28:40
Genau so. Aber das setzt halt genau dieses
28:43
Monitoring und Feedback voraus, dass das richtig funktioniert.
28:47
Genau, also es ist ja im besten Fall, darf ja gar nicht so weit
28:51
kommen, wie du ja schon meintest, dass der Kunde dich
28:53
darauf aufmerksam macht, weil dann sagt man ja, so schön ist
28:56
das Kind schon im Mund gefallen, weil dann hast du, dann ist der
28:58
Bock drin so ne, aber wenn du quasi über deinen eigenen System
29:04
quasi schon benachrichtigt wirst, ey.
29:06
Keine Ahnung, sowas abgeflogen oder hat n Critical Error
29:10
geworfen oder was auch immer. Ne dann ist das halt ja sehr
29:16
förderlich, wenn man das schnell.
29:17
Mitbekommt. Aber es ist auf jeden Fall eine
29:20
schöne Beschreibung, dass du es schneller mitkriegst, dass ein
29:23
Fehler in der Anwendung gibt, als der Kunde es kann natürlich
29:26
auch sein, dass zum Beispiel der Kunde oder die Kundin, der User,
29:29
die Userin, was auch immer beispielsweise irgendwie ne n
29:33
Service benutzt und dieser Service hängt von anderen
29:35
Services beispielsweise ab. Und jetzt?
29:37
Willst du irgendwas machen, zum Beispiel Feature X?
29:39
Möchtest du benutzen und es geht nicht und dann könnte man ja zum
29:43
Beispiel auch sagen, ne, bevor der Kunde jetzt sagt, Ah
29:46
Scheiße, ich muss mich jetzt, ich ruf da jetzt mal beim
29:48
Support an und beschwere mich, gibt es auch die Möglichkeit von
29:52
sogenannten Status Pages man in seiner Anwendung integrieren
29:56
kann. Das macht Github zum Beispiel
29:58
super gut, dass Du sagen kannst, OK weiß ich nicht, ich kann
30:00
jetzt zum Beispiel keinen repo Auschecken, als Beispiel ne
30:03
woran liegt denn das? Und dann kannst du also
30:06
irgendwie funktioniert das nicht und dann?
30:08
Hast du ja die Möglichkeit, wenn du sagst es gibt eine Status
30:10
Patch. Ich guck erstmal auf die Status
30:12
Patch und sehe o keine Ahnung. Service XY ist rot, das geht
30:16
nicht und der ist dafür zuständig, dass man zum Beispiel
30:18
K checken und dann hast du im Normalfall diesen Effekt, dass
30:21
der User sich denkt, also totale Transparenz dem User gegenüber
30:26
gibt, dass man sich denkt AOK gut, jetzt weiß ich warum das
30:31
das wirklich nicht gerade nicht geht, die haben ein Problem, ich
30:34
muss mich jetzt bitte ich muss mich jetzt erstmal nicht, ich
30:36
muss mich darum kümmern muss niemanden anrufen ich.
30:38
Wie du meintest, ich versuchs später genau und das ist zum
30:41
Beispiel auch eine Möglichkeit, die natürlich.
30:43
Gut ist ja guter Punkt. Um halb magst du ganz kurz
30:46
erklären, was github ist. Für Leute die das vielleicht
30:49
noch nicht verwendet haben, hier einen Raum geworfen hast.
30:52
Ja, also github ist ja im Endeffekt eine Plattform, die
30:55
Repositories verwaltet. Ne, also du hast ne Art von
30:58
Service, das heißt du kannst einfach sagen, OK, ich möchte
31:02
meine Code Basis irgendwo ablegen, Remote und diese Code
31:06
Basis ist ein Repository und. Dieses Repository kannst du.
31:11
Es geht auch. Kannst du gehostet, kannst du.
31:13
Genau, ja, cool. Genau.
31:18
Ich glaube, das haben wir jetzt eigentlich ganz cool beleuchtet.
31:20
Also mir ist auch selbst nochmal bewusst geworden, wie enorm
31:22
wichtig das ganze Thema ist. Und ich finde es auch cool, dass
31:26
wir da echt wirklich viel Ambition reinstecken, dass das
31:30
alles so läuft bei uns auch. Ja, aber wie?
31:32
Aber eine Sache noch ne, warum läuft es so gut?
31:35
Es läuft so gut, weil zum Beispiel wir haben eine
31:37
Pipeline, also ne unsere Pipeline ist aufgebaut, aber wie
31:40
ist denn die Pipeline zum Beispiel aufgebaut, ne?
31:42
Also Ah, jetzt wird es auf den Dritten.
31:44
Punkt kommen ganz normal kurz, GHG nochmal kurz darauf eingehen
31:47
weißt du. Ist richtig.
31:49
Aber das ist ja dieser infrastructures Code und man
31:53
kann sich ja zum Beispiel hinstellen.
31:54
Ich hatte der mal gesagt, dass ich mit ABS ne Menge zu tun
31:57
hatte und bei ABS halt unglaublich krass, wie viele
32:01
Sachen du du brauchst den Service, du brauchst den
32:02
Service, du brauchst XYZ und was auch immer ne.
32:05
Und wenn du dich jetzt aber hinstellst und sagst, OK keine
32:08
Ahnung, dir fliegt deine Pipeline weg, es kann ja
32:10
irgendein Fehler kommen, keine Ahnung.
32:11
O zerschießt dir selber deine Pipeline, weil du irgendeinen
32:14
Mist konfigurierst, weiß aber nicht mehr was du gemacht hast.
32:17
Ja musst du vielleicht die ganze Pipeline wieder aufsetzen, deine
32:21
ganze Infrastruktur, keine Ahnung den und den Service wo
32:25
dein Backend drauf läuft, was auch immer und damit du das aber
32:29
nicht alles manuell machen musst, weil du das vielleicht
32:31
vor einem Jahr mal gemacht hast und jetzt überhaupt nicht mehr
32:33
weiß wie mach ich denn das weißt du.
32:36
Ja, ganz kurz manuell meinst du, dass du ja meistens bei diesen
32:41
Services ja auch ne Web Oberfläche, also Frontend hast,
32:46
wo du es quasi konfigurieren kannst?
32:48
Richtig wie deine Pipeline aussehen soll, richtig und was
32:52
du mit s Code meinst ist, dass man diese Konfiguration ja
32:57
wirklich programmieren kann. Genau ne Art Gerd, du hast ne ne
33:00
Art. Skript nennen wir Skripten.
33:02
Ja genau, also zum Beispiel n weitverbreitete Filart.
33:07
Für Jamel feiern ne. Ja, zum Beispiel genau, also
33:11
halt ne spezielle Syntax und kannst damit quasi dann die
33:14
Konfigurations Skripten. Genau.
33:16
Also das ist ja zum Beispiel, also machen wir ja auch so ne,
33:18
also wir benutzen ja Files für unsere Pipeline und den der
33:23
Vorteil, der liegt ja eigentlich auf der Stelle, und zwar wenn
33:26
irgendwas kaputt geht oder irgendwas oder du musst
33:29
vielleicht deine Pipeline woanders nochmal aufsetzen 1 zu
33:32
1, dann nimmst du einfach nur dein Skript oder den Pfeil oder
33:37
wie man das nennen mag. Und Jagst, das durch diesen,
33:39
durch diesen Service sag ich mal und dann wird alles aufgebaut
33:43
für dich, zum Beispiel bei AW. Es war Sommer, ne.
33:47
Genau. Also du hast natürlich in einem
33:49
also eine wesentlich bessere Skalierbarkeit, also angenommen,
33:51
du willst jetzt auf mehreren Services aufsetzen.
33:55
Oder halt auf mehreren Servern kannst du halt mit dem Jamel
34:00
Film mit einem Skript, das überall sofort konfigurieren.
34:03
Bei der anderen Variante musst du manuell überall alles
34:05
durchklicken und dann machst du auf jeden Fall Fehler und ein
34:09
wichtiger Punkt dabei ist, wenn wir schon bei Repositories sind,
34:14
der große Vorteil dabei ist ja die Versionierung, ne, also
34:16
jeder einzelne Stand ist Versioniert und
34:18
Wiederherstellbar, das heißt angenommen du würdest einen
34:22
Fehler in deine Konfiguration einbauen, kannst du einfach
34:25
einen vorherigen Stand wiederherstellen der
34:27
funktioniert hat. Und dir die Änderung angucken.
34:29
Ja, super geiler Punkt auf jeden Fall, weil damit ist es ja auch
34:32
dokumentiert, was du gemacht. Genau hast du kannst auf jeden
34:36
Fall die Änderungen zurücksetzen und dann die überlegen o warum
34:39
funktioniert das nicht? Warum ist meine Pipeline
34:42
zerstört? Sozusagen durch diese Änderung,
34:44
wenn du manuell rum klickst? Du weißt du noch 10 Minuten
34:46
nicht mehr worauf du geklickt hast?
34:48
Richtig? Ja ne.
34:50
Also das ist auf jeden Fall genau.
34:52
Das ist auf jeden Fall wichtig, weil es geht da bei der
34:54
natürlich auch zusätzlich um die.
34:58
Sag ich mal. Um möglichst eliminieren von
35:01
manuellen Schritten ne. Das ist so.
35:04
Sag ich mal. Die Faustregel bei Dev Ops, da
35:06
kannst du dir so ganz oben auf auf die Fahne schreiben, so nach
35:09
dem Motto, also für jeden Zuhörer und Zuhörerinnen macht.
35:15
Wichtig. Automatisiert.
35:18
Möglichst automatisiert. Ja, genau.
35:19
Ja, also ich würde sagen, es gibt auch viel mehr Punkte, die
35:22
man da jetzt ansprechen könnte, aber ich denke so die groben und
35:25
wichtigsten Punkte haben wir genannt, deswegen würde ich
35:27
jetzt die Folge auch beenden. Definitiv aber ist noch mal
35:32
dazu, liebe Kolleginnen, liebe Zuhörer, falls du mehr dazu
35:35
wissen möchtest, schreib uns gerne auf unseren Plattformen,
35:38
melde dich bei uns, wir können auch gerne noch eine weitere
35:40
ergänzende Folge dazu aufnehmen im Podcast vor und Nachteile
35:44
genau einfach auf weitere Punkte eingehen.
35:47
Ansonsten würde ich sagen, abonniert doch gerne den
35:50
Podcast, wenn es dir gefallen hat, die Links für unsere
35:53
anderen Plattformen findest du Show Notes.
35:55
Meld dich auch gerne da und folge uns da.
35:57
Ansonsten wünschen wir noch einen schönen Tag und bis zum
36:02
nächsten Mal. Eure Coding war das gemeinsam
36:05
besser.