Latest / Coding Buddies | Tech & Dev-Mindset / #124 DevOps Finale – Alles. In einer Folge. Der komplette DevOps-Plan

Transcript

#124 DevOps Finale – Alles. In einer Folge. Der komplette DevOps-Plan · Coding Buddies | Tech & Dev-Mindset

0:00
Aber nicht, weil ich faul bin. Ich sag's mal provokativ,
0:04
sondern um quasi meinen Entwicklungsprozess vor mir
0:07
selbst zu schützen. Coding Buddies, Dein Podcast
0:11
rund um Softwareentwicklung und aktueller Tech News herzlich
0:14
Willkommen. Halli Hallo und herzlich
0:28
Willkommen zur neuen Folge vom Coding Buddies Podcast.
0:33
Ich würde sagen, es ist Zeit für eine neue Folge, und zwar mit
0:37
mir und mit Tino, den ich hier herzlich begrüßen kann.
0:40
Tino, Was geht ab, wie geht's dir alles gut bei dir?
0:44
Moin Moin Fabi, mir geht's gut, mir geht's sehr gut, was geht
0:48
ab? Ich finde es eigentlich nicht
0:49
gut, dass du meine Frage am Anfang klaust, um das Mal kurz
0:51
vorweg zu nehmen, was geht, das kannst du nicht patentieren,
0:54
Alter magst du nicht. Also ich finde so unter uns
0:59
beiden so ein Podcast kann ich das schon.
1:02
OK, es ist meine Frage. OK gut, wir machen aus, aber um
1:08
deine Frage zu beantworten was geht ab eigentlich gar nicht so
1:12
viel ich find momentan plätschern die Wochen so n
1:14
bisschen vor sich hin aber nicht im negativen Sinn, sondern es
1:17
ist immer was los so weißt du am Wochenende ach das ist geplant
1:20
und dir und so. Aber irgendwie rennt die Zeit
1:23
schon wieder dadurch. Das ist so, weißt du, das ist so
1:25
n typischer Spruch, den wo ich früher immer dachte, Oh, das
1:28
sagen wir so, die alten Leute, ne ich weiß nicht ob ihr jetzt
1:30
mittlerweile selbst als alt zählt, aber es ist so dieses Ach
1:34
das Jahr rennt aber auch schon wieder Fabi, das rennt schon
1:38
wieder. Solange man nicht sagt, die
1:40
Jahrzehnte rennen. Ich weiß nicht, wie es dir da so
1:45
geht, aber ich hab immer das Gefühl so WOW ist schon wieder n
1:47
Monat rum. Ja ich weiß aber auch ehrlich
1:49
gesagt nicht wann das angefangen hat weil es gab ne Zeit da war
1:53
es für mich so. Boah ey irgendwie geht es gar
1:56
nicht voran und ich will endlich jetzt zum Beispiel so weißt du
2:00
so in der Schule so ich will endlich wieder Sommerferien
2:02
haben oder wenn man noch n bisschen weiter zurückgeht so oh
2:05
mein Gott, bis mein nächster Geburtstag ist und ich wieder
2:07
Geschenke kriege, dann dauert das alles so so 1000 Jahre weißt
2:11
du so ungefähr. Und das hat man gefühlt jeden
2:15
zweiten Tag Geburtstag so, ja, das ist schon krass, das ist
2:21
schon krass, sollten wir vielleicht auch mal eine Folge
2:24
drüber machen. Ja, nee, aber ich kenne das.
2:26
Ich kenne das, es geht über ratzfatz, ich meine, das sieht
2:29
man ja auch an den Podcast folgen, ich meine, wir haben
2:32
einfach schon, weiß ich nicht, die wir sind schon jenseits der
2:36
120 folgen, also das ist schon ein.
2:38
Ist schon krass ne und ich habe das Gefühl Tino Wir haben erst
2:41
gestern mit dem Podcast angefangen oder sagen wir mal
2:43
zumindest vorvorgestern, das ist schon krass, geht echt.
2:48
Schnell. Aber ich würd sagen, lass uns
2:51
mal so n bisschen reinkommen. Wir haben nämlich heute n ganz
2:54
interessantes Thema mal wieder und bevor wir das Thema jetzt
3:00
anteasern, wollt ich noch mal ganz kurz anmerken, liebe
3:03
zuhören liebe Zuhörerinnen, vergiss nicht.
3:06
Die Glocke anzumachen und den Podcast abonnieren, weil dann
3:08
verpasst du keine Folge mehr, weil wir sind ja auch schon wie
3:11
gesagt schon n bisschen fortgeschritten.
3:13
Ne, also schon in über 120 in den 100 Zwanzigern.
3:17
Den 100 Zwanzigern ja genau, ja, wichtiger Punkt.
3:21
Wir haben ja das Glöckchen erst selbst für uns entdeckt.
3:23
Übrigens mach ich das bei Podcast die ich höre auch jetzt
3:26
sehr gut, also ich mach das auch, ich hab das auch schon
3:29
vorher gemacht, aber ich hab irgendwie einfach nicht
3:31
realisiert, dass man das ja auch sagen kann für den eigenen
3:33
Podcast. Aber ist ja.
3:36
Na, bei mir war es wirklich so, dass ich halt immer geguckt hab,
3:38
oh, gibt es ne neue Folge, gerade wenn welche nicht so
3:41
regelmäßig, also so so Gescadued hochladen ne so jede wie wir
3:45
jetzt zum Beispiel jeden Donnerstag 18:00 Uhr, dann
3:47
musste ich halt immer gucken, Oh gibt es schon was neues und dann
3:50
denk ich mir so oh mein Gott diese Glocke ist n gamechanger
3:53
so ne ja krass ach ja das schöne Glöckchen wie gesagt nicht
3:59
vergessen genau. Aber Tino Pass auf.
4:04
Es geht ja heute los, ne und zwar es geht los, große Finale
4:08
heute und zwar von der Def Ops Reihe.
4:11
Also ich sag jetzt mal wir werden uns jetzt nicht so weit
4:14
aus dem Fenster lehnen, dass wir sagen wir machen nie wieder mal
4:16
n def Ops Thema, aber. Jetzt so ne, dafür leben wir das
4:19
Thema zu viel. Aber, so die Reihe wollen wir
4:21
jetzt erstmal abschließen, die wir jetzt so ins Leben gerufen
4:24
haben. Wir haben ja schon einige Topics
4:26
behandelt und wir haben eigentlich.
4:30
Verschiedene Themen wirklich intensiv behandelt und falls du
4:35
Liebe zu Liebe zu dir denkst, so ey, Mensch hier, da habe ich
4:37
jetzt irgendwie Bock, noch mal reinzuhören, was.
4:39
Da gibt es verschiedene, wusste ich noch gar nicht, hör da auf
4:42
jeden Fall rein oder wenn dich ein spezifisches Thema
4:44
interessiert, falls das jetzt die 1.
4:46
Folge ist von dieser Reihe die du hörst, dann kannst du auf
4:49
jeden Fall immer wieder noch mal zurückskippen und noch mal
4:51
gucken und dir ein einzelnes Thema rauspicken, ne, aber vom
4:56
Fahrplan her Tino. Was sagst du dazu, wenn wir
4:59
heute sagen, OK, wir schließen die Reihe mal so ab, dass wir
5:02
mal die ganze, ich nenne es jetzt mal def Ops Kette
5:04
durchspielen und sagen, wie kommt beispielsweise der Code
5:08
eigentlich vom Commit bis zu, ich nenne es mal in die
5:11
Produktivumgebung, also ne, dass die live läuft.
5:14
Zum Kunden sozusagen, ja. Genau, genau, genau.
5:18
Und warum das eigentlich wichtig ist, dass man diese ganzen Def
5:22
ops Praktiken eben halt auch im Verbund.
5:26
Verwendet ne nicht nur einzeln, sondern im Verbund.
5:29
Und wir hatten ja zum Beispiel schon über CICD, Staging
5:33
Monitoring, Observability, Infrastructures Code,
5:35
Containerization und Occustration gesprochen und
5:40
jetzt möchte ich dir mal das Gedankenexperiment zuspielen
5:43
Tino und sagen OK, pass auf, stell dir mal vor, du hast jetzt
5:46
n neues Feature fertig, ne du hast jetzt programmiert, du hast
5:50
jetzt n Feature bekommen, hast es programmiert soweit so gut OK
5:53
geil so. Richtig geiles Feature.
5:55
Was anderes kenn ich von dir nicht und jetzt hast du deine
6:00
Change. Was lachst du danach?
6:04
Also ich weiß nicht immer wenn ich wenn ich so das hat nichts
6:08
Böses zu tun, das war. Wirklich nicht böse gemeint.
6:11
Ich hab mich einfach nur darüber gefreut, dass ich dir ein
6:13
Kompliment gemacht hab. Schön, danke und jetzt hast du
6:17
deinen Changes, du checkst die ein ne also beziehungsweise du
6:20
committest das ganze und pushst es in dein Remo rein.
6:24
Und jetzt geht es los. Was ist jetzt die Frage, was
6:26
passiert jetzt? Wie geht die ganze Nummer los?
6:29
Wir, wir sind jetzt in dieser in unserer, Ich nenne sie wie
6:31
gesagt Def Ops Kette ja und der Push ist gemacht ins Repo, der
6:36
neue Code ist irgendwie da genau also wir haben ja in unserer
6:41
Reihe quasi so Grund die Grundlagen besprochen wie eine
6:43
grundlegende CICD Kette also Pipeline aussieht ja und davon
6:47
gehen wir jetzt mal wieder aus, also keine kein Schnickschnack
6:50
ja so die Basics. Und dann geht es halt
6:54
logischerweise, so haben wir es ja auch in der Reihe gemacht,
6:56
als erstes mit der Continuous Integration los, also mit dem CI
6:59
teil und man muss sagen, ab jetzt, liebe zuhören, liebe
7:03
Zuhörer, reden wir davon, dass Sachen automatisiert passieren,
7:07
denn das ist ja der große Benefit.
7:10
Unserer Pipeline, die uns sehr, sehr, sehr viel Arbeit der sonst
7:14
manuell echt nervig wäre, abnimmt.
7:16
Ja und dadurch ja auch ne gewisse Qualität gewährleistet
7:19
wird, weil es automatisiert ist das noch mal als kleiner
7:21
Reminder ab jetzt. Kleiner Einwurf, weil wenn man
7:24
sich das mal vorstellt, bevor man CICD Pipelines alles den
7:28
ganzen Kram. Ich sag mal erfunden hat ne hat
7:31
man das eigentlich wirklich manuell gemacht?
7:33
Ne so ja wahrscheinlich in einer geringeren Frequenz Frequenz
7:36
aber es ne. Genau also wie du ja schon
7:41
gesagt hast. Ich hab jetzt n Feature
7:42
entwickelt. Ich hab das committed und
7:44
gepusht so in unserer agilen Welt, wie wir sie leben.
7:49
Also wir jetzt wir beide vor allem ja sind ja so ne Features,
7:53
nicht sehr groß sondern kleingeschnitten, das heißt
7:56
diese Frequenz die du gerade angesprochen hast ist ja erhöht.
7:59
Ja. Ja, und nicht wir machen einmal
8:02
im Jahr nen Update, weil es halt so aufwendig ist ein Update an
8:05
den Kunden auszuspielen. Das ist ja schon der erste
8:07
wichtige Punkt, warum diese Automatisierung so so
8:11
unglaublich effizienzsteigernd auch ist.
8:13
Am Ende ja und genau und deswegen ich hab das jetzt
8:16
committed gepusht und ich möchte, dass der Kunde das jetzt
8:18
erfahren kann. Ne, das ist n geiles Feature wie
8:20
du meintest und das soll jetzt ausgerollt werden.
8:23
Und damit geht es dann halt wie gesagt mit dem CI teil los.
8:26
Das heißt unsere Pipeline kommt jetzt so richtig ins Rollen,
8:28
dafür muss sie aber natürlich erstmal erkennen, dass es eine
8:32
Änderung gibt auf dem Branch zum Beispiel, auf dem ich das
8:35
gepusht hab. Ja, also das ist ja jetzt die
8:36
Grundvoraussetzung, dass die Pipeline das auch erkennen kann.
8:39
Oh, es gibt n neuen Commit der gepusht wurde, es gibt sozusagen
8:42
Changes und das überprüf ich jetzt mal, bevor das hier
8:46
richtig integriert wird oder als integriert gilt in unserer
8:50
Codebasis. Müssen jetzt erstmal Checks
8:52
laufen und Tests, damit man sagen kann, es ist erfolgreich
8:55
integriert und das ist ja im Prinzip die Kernaufgabe des CI.
8:59
Teils genau das heißt, man lässt die Tests laufen, die ja
9:03
hoffentlich da sein sollten, Leute die müssen da sein, die
9:05
sind da erstmal so, Tests müssen da sein, das heißt die Tests
9:10
laufen. Man kann auch ne statische
9:12
Codeanalyse laufen lassen. Also da sind jetzt sag ich mal,
9:16
da gibt es keine Grenzen was man testen möchte, ne je mehr desto
9:20
besser mal so als kleiner Grundsatz solange es einen Sinn
9:23
dahinter gibt. Ja, also sinnlose Tests bringen
9:25
natürlich nichts und man kann natürlich auch sagen, oder das
9:29
ist wichtig dabei zu achten, es gibt 2.
9:34
Wie soll ich sagen, Prämissen oder Eigenschaften, die dieser
9:38
CI teilhaben sollte? Noch mal so als Reminder und
9:41
Zusammenfassung erstens bei all den Tests, die ich laufen lasse,
9:45
ist es wichtig, dass die Pipeline in diesem CI teil
9:49
schnell abbricht und Meldung macht, was schief gelaufen ist.
9:53
Es bringt mir nichts, ich habe jetzt tausende Tests und der 10.
9:57
Failed. Da muss ich die anderen nicht
9:59
laufen lassen, weil dann ist ja dann stimmt schon irgendwas
10:01
nicht, weil wir gehen ja davon aus, dass der Test seine
10:03
Daseinsberechtigung hat und selbst wenn er es nicht hat oder
10:09
es sogar richtig ist, dass der falsch ist, weil der das Feature
10:12
sich geändert hat, ne, dass da Sachen überprüft werden, die gar
10:14
nicht mehr drin sind. Es ist ja trotzdem wichtig die
10:17
Meldung zu bekommen und zu sehen, dass da was nicht stimmt
10:20
und den Hinweis zu bekommen, weil dann heißt es ich hab
10:22
irgendwas übersehen oder nicht angepasst.
10:24
Das heißt ich will ja schnell drauf reagieren können, wieder
10:26
als Entwickler. Und mit schnell, das ist der
10:30
zweite Punkt, der wichtig ist. Es darf halt auch insgesamt
10:34
nicht lange dauern, weil auch ein positives Feedback möchte
10:38
ich schnell haben. Ja, also nicht nur, ach, es
10:41
läuft nichts schief, na dann mach dein Ding CI teil, wir
10:45
sehen uns morgen. Das ist natürlich auch nicht der
10:47
Sinn, sondern so mal als Richtwert 10 bis 30 Minuten.
10:51
Das ist so für ne Pipeline schon wünschenswert, ne.
10:54
Also dass ich sage OK ich hau jetzt mein Feature rein in die
10:57
codebasis und ich möchte ja auch schnell sehen, war das
11:01
erfolgreich. Ja, also wir haben ja, wir sind
11:03
ja jetzt an dem, also man muss auch dazu sagen, wenn man jetzt
11:05
so für sich selber ne Pipeline entwickelt, ist sie
11:07
wahrscheinlich eh. Also du hast so ne kleine
11:09
Anwendung, willst hier die Ployn, da ist sie wahrscheinlich
11:11
eh relativ schnell, weil du gar nicht so viel hast, ne?
11:14
Aber selbst wenn sie ein bisschen länger wäre, würde es
11:16
dich alleine wahrscheinlich gar nicht stören und deswegen würde
11:19
man sich wahrscheinlich denken, ja gut, passt schon, wenn die
11:21
jetzt mal eine Stunde läuft, ist mir egal wann.
11:24
Wann ändere ich mal was. Angenommen, du hast jetzt
11:26
vielleicht du arbeitest alleine, hast so privat, hast jetzt
11:28
vielleicht jeden Tag mal einen Push aufs Repo, weißt du wenn du
11:33
jetzt aber davon ausgehst und wenn wir das jetzt mal
11:35
gedanklich ein bisschen durchspielen, sagst du hast ein
11:37
Team von 6 Leuten, die regelmäßig codeänderungen
11:41
pushen. Und jedes Mal läuft die Pipeline
11:44
los. Dann hast du eventuell das
11:46
Problem, dass die sich irgendwann richtig cune, bis das
11:50
irgendwann durchläuft und dann hast du vielleicht so 6 commits
11:53
sag ich jetzt mal oder 6 ne neue Änderung auf deinem Repo und der
11:58
Erste läuft durch, der zweite läuft durch, der Dritte läuft
12:00
durch und dann der Vierte den du eigentlich haben willst, der
12:04
failed so aber bis. Dass du das gemerkt hast,
12:07
brauchst du ja im Worst case vielleicht einige Pipeline
12:10
Durchgänge und wenn du dann aber eine Pipeline hast, die 2
12:12
Stunden läuft, ich übertreibe jetzt ne, aber es gibt es
12:15
wirklich. Also ich habe auch schon mal ein
12:16
Projekt gearbeitet, wo eine Pipeline, ich würde sagen
12:19
eineinhalb Stunden gedauert hat und das ist ein Killer wirklich,
12:22
das ist ein Killer das das funktioniert dann irgendwann
12:25
nicht mehr, gerade wenn du häufig committest, was an sich
12:27
eigentlich eine ganz gute Practice ist.
12:29
So ne ja, aber du hast natürlich im Kopf, das dauert echt lange,
12:33
vielleicht mache ich das und das vorher noch.
12:35
Also das macht natürlich was mit dem Mindset des Entwicklers oder
12:39
der Entwicklerin. Wenn du weißt, das dauert lange
12:42
oder du blockst lange, dann die Pipeline.
12:44
Ja, deswegen ist so n so n Richtwert schon gut.
12:48
Klar kann man ihn nicht halten, je nachdem wie das Projekt
12:50
skaliert wie du gerade meintest, aber so n Richtwert ist immer
12:53
gut zu sagen Ah lass mal schon gucken, dass wir da drin bleiben
12:56
so ne. Ja, genau, ja.
12:58
Und abschließend kann man dazu sagen, das ist im Prinzip der
13:01
CI, teil ist so der erste sogenannte Gatekeeper, ne der
13:06
Halt wirklich sagt Pass mal auf ja du codeänderung ja OK du
13:10
kannst rein, du bist sauber, du nee, das muss noch mal geprüft
13:13
werden ne also du hast halt da schon so deine erste, deine
13:16
erste Überwachung sozusagen, dass alles in Ordnung ist.
13:20
Ja, richtig, genau. Und ansonsten wird es halt
13:23
geblockt und wenn dann halt alles wirklich grün ist.
13:25
Ne Test Checks und so weiter dann gilt ja der Code als
13:28
integriert. Offiziell ne was ich noch ganz
13:31
interessant fand, weil du vorhin meintest es muss auch einen Sinn
13:34
ergeben bei diesen Checks, weil wir jetzt, weil ich gerade noch
13:37
mal Checks gesagt habe, ich hatte auch zum Beispiel schon
13:40
mal gesehen, dass irgendwo ein Test drin war, es hieß OK, es
13:42
sollte irgendwie, es sollten Tests für Files da sein und dann
13:46
gab es tatsächlich ein Test. Zu einem Pfeil wo drin stand
13:50
accept true to be trucy, so als Beispiel ne und das ist halt
13:55
also das war halt schon wirklich sehr dreist so nach dem Motto
13:58
Wir haben Tests, es laufen Tests aber die Tests waren halt sowas
14:01
von unaussagekräftig weil sie halt einfach gar nichts getestet
14:04
haben und das war schon n bisschen bisschen heftig so viel
14:08
zum Thema, wenn es denn auch sinnvoll ist.
14:10
Ne genau. Aber Tino, wenn wir, ich möchte
14:14
mal ganz kurz ne Sache spoilern, ne und zwar.
14:16
Wir OK. Wollen ja gerne das, was wir
14:20
jetzt hier besprechen. Diese ganze def Ops Kette ne
14:22
wollen wir auch gerne mal vom From scratch selber machen ne
14:27
also wirklich mal aufbauen und das so als ich sag mal
14:31
Videoreihe ne dass man wirklich sagt OK wir machen so ne Art ja.
14:36
Ich will es jetzt nicht wirklich Tutorial nennen, aber so n so ne
14:40
Art OK, wir machen ne Videoreihe und man kann sich das halt
14:42
angucken um halt was draus zu lernen und dann vielleicht.
14:45
Praktisch zu sehen. Mal genau.
14:46
Genau, genau. Und das sind ja auch einige
14:48
Sachen, die da mit Reinspielen und dafür würde ich gerne dir
14:52
mal ganz kurz ne kleine Werbung machen.
14:54
Weil wir wollen dafür ja einen v Server von Strato nehmen und da
14:59
gibt es ja auch immer mal wieder günstige Angebote, ne und wir
15:02
wollen ja zum Beispiel den VC 624 nehmen, das heißt der hat 6
15:06
Kurs 360 Gigabyte Speicher, 24 Gigabyte RAM und das halt eben
15:11
für einen Euro pro Monat ne. Der ist ein Nobranner, ne, also
15:14
3 Monate lang kann man das testen, das ist natürlich mega
15:18
genial. Der hat halt auch schon
15:19
ordentlich Leistung, ne, also da ist halt dann auch einiges
15:21
möglich mit ich bin richtig gespannt, ich freue mich drauf
15:24
auf. Auf die Videoreihe und ich find
15:26
es halt auch mega cool, dass wir das auf diesem V Server machen
15:29
können. Ja, auf jeden Fall.
15:30
Aber wenn man jetzt zum Beispiel sagt, Ey, ich find jetzt zum
15:32
Beispiel den entsprechenden V Server, der ist mir eigentlich
15:34
schon zu viel oder zu wenig, also es gibt auch noch viele
15:38
andere und die Angebote ändern sich auch, also das ist auf
15:40
jeden Fall alles möglich, wenn du, liebe zürer lieber Zürer
15:42
sagst, ey, das ist cool, ich brauch auch gerade so NV Server
15:45
oder also nicht ich brauch irgendwie n Server worauf ich
15:47
irgendwas laufen lassen kann. Dann guck auf jeden Fall mal in
15:49
die Shownotes, weil da haben wir n Link, das ist n Link wo du uns
15:52
auch zusätzlich noch unterstützen kannst und guck da
15:54
auf jeden Fall mal rein, check das aus und wenn du sagst ich
15:57
brauch so n Ding, dann let s go. Ja, genau.
16:00
Werbung, Werbung Ende, wie man es so schön sagt, dann lass uns
16:03
mal über den CD teil reden. Du meintest ja gerade so, wir
16:06
haben Gatekeeper, ne unsere Tests Checks sind alle
16:08
durchgelaufen, jetzt ist es grün, wie geht es weiter?
16:10
Weil prinzipiell ist der Code ja noch nicht deployed, wir können
16:13
das ja noch nicht verwenden. Dein neues geiles Feature was du
16:15
entwickelt hast. Kino das heißt?
16:17
Wir müssen ja jetzt noch gucken, dass wir das Ganze, dass das
16:20
Ganze weitergeht, und zwar, dass man halt auch wirklich die
16:24
Änderung, die man jetzt gemacht hat, dass man die auch wirklich
16:26
live schaltet, und da hatten wir ja auch schon mal so ein
16:30
bisschen einen Unterschied gehabt zwischen Deployment und
16:34
Delivery, das hatten wir schon mal ein bisschen besprochen,
16:36
möchte das noch mal ganz kurz vielleicht zusammenfassen, was
16:38
das ist, damit man das noch mal auf einen Blick zusammen hat.
16:42
Und. Ja, also unter CD verstänken
16:45
sich halt genau diese beiden Begriffe, oder man kann halt so
16:48
beide damit verwenden sag ich mal ne, aber so ganz grob die
16:52
Unterscheidung delivery ist halt, dass man sagt, OK, ich
16:56
bereite alles soweit vor, dass es an zum Beispiel dieses neue
17:00
Feature, was wir jetzt committed haben an den Kunden ausgerollt
17:03
werden kann, aber ist am Ende immer noch eine.
17:06
Sag ich mal. Manuelle Freigabe benötigt ja,
17:09
also man kann sich das wirklich so vorstellen, alles ist Grün,
17:13
das Ding ist bereit integriert zu werden, also beziehungsweise
17:18
nicht integriert, sondern dem Kunden zur Verfügung gestellt zu
17:20
werden und ich drück jetzt nur noch n Knopf und sag so Leute
17:24
ihr könnt es verwenden, jetzt ist es für euch da.
17:26
Update so nach dem Motto Ja. Und Deployment ist dann
17:31
eigentlich so vom Grundprinzip her, dass es komplett
17:35
automatisiert ist. Ja, also in dem Moment, wo ich
17:38
mich als Entwickler entschieden habe zu sagen.
17:41
Ich Committee mein neues Feature, Das ist fertig.
17:43
Von meiner Seite aus. Ich übergebe es quasi meiner
17:46
Pipeline, alles läuft durch, wir hatten ja gerade den CI TEIL CI
17:50
sagt ja alles super und der CD teil sagt alles super OK dann
17:55
werde ich jetzt nen nen Deployment eine Auslieferung
17:59
vorbereiten und Vollautomatisiert an den Kunden
18:01
gehen. Genau das heißt.
18:02
Das heißt, mit meinem Commit mit dem Push nach einer gewissen
18:08
Zeit hat der Kunde es dann auch im Prinzip zur Verfügung.
18:11
Genau, und das ist das Ziel. Ja, im Endeffekt baut man, so
18:15
sag ich jetzt mal im CD Teil, baut man die Software, hat ja
18:20
irgendwie n Artefakt ne also ich sag mal was man sich gut
18:23
vorstellen kann so also das ist es jetzt nicht mal, also n
18:27
Artefakt ist ja zum Beispiel auch sowas wie ne exe ne, also
18:29
irgendwas was man laufen lassen kann, so nach dem Motto ne.
18:32
So n Ergebnis dann halt. Und das wird dann halt irgendwo
18:36
halt eben auch laufen gelassen. So ne in einer bestimmten
18:38
Umgebung und. Delivery zum Beispiel finde ich,
18:42
wenn man das noch mal sagt, so oder noch mal aufgreift, finde
18:45
ich ganz gut, wenn man sagt, OK, man hat es vielleicht so n
18:47
feature Set wo man sagt OK ich möchte nur einen Deployment
18:49
machen, wenn das gesamte Feature Set was gerade entwickelt wird
18:52
auch fertig ist. Ne weil das kannst du jetzt ohne
18:56
weiteres ne und ich sag extra ohne weiteres bei Deployment
18:59
halt nicht unbedingt gewährleisten weil da wird ja
19:01
erstmal stand jetzt so wie wir es gerade besprochen haben immer
19:04
gesagt OK. Neue Änderungen du wirst die
19:07
ploy, du wirst die ploy, du wirst die Ployd also angenommen.
19:09
CI ist Grün, der Code wurde integriert, dann wird es auch
19:12
Deployd das heißt wenn du 3 Teil Features sozusagen oder ne was
19:16
vielleicht zu einem Featureset zusammengehört wird es halt
19:17
einfach deployd und dann ist halt n Teil davon da und Teil
19:20
nicht ne da kann man natürlich auch sich wieder hinstellen und
19:23
sagen ja gut OK dann mach halt zum Beispiel so sogenannte
19:26
Feature flags. Und setzt die erst auf.
19:29
Dieses Feature ist da, wenn das gesamte Set, zum Beispiel das
19:32
ist eine Möglichkeit, auch das so zu machen, weil wie gesagt,
19:36
Def OPS ist ja auch, man versucht ja möglichst viel zu
19:39
automatisieren und demzufolge ist auch, sagen wir mal Strebsam
19:45
im Def Ops Bereich zu sagen, Wir wollen Deployment und nicht nur
19:47
ein Delivery, aber es ist bringt natürlich auch noch ein bisschen
19:52
mehr mit sich, also gerade bei Deployment.
19:55
Ja, also. Im Prinzip alles, was sich mit
20:00
Deployment beschäftigt. Da kommt man schnell an den
20:03
Punkt, dass man sagt, OK, wir brauchen ja auch eine gewisse
20:04
Strategie, um zu Deployen in einer ganz einfachen Pipeline,
20:08
wie wir es jetzt bis jetzt stand jetzt haben, ist es halt im
20:12
Prinzip direkt deployed, wie du auch meintest, so ne, dann ist
20:15
es halt schwierig ganze Features Sets mit einmal auszuliefern
20:19
oder quasi noch sozusagen zurückzuhalten.
20:22
Aber du hast natürlich auch das Thema, wie kommt das überhaupt
20:26
an das Feature? Ne, also du hast jetzt zum
20:29
Beispiel gesagt Mensch Tino Klasse feature was du gemacht
20:31
hast, aber vielleicht sieht der Kunde das nicht so oder nur n
20:34
Teil der Kunden finden das gut und da haben sich halt so
20:37
verschiedene Deployment Strategien herauskristallisiert,
20:41
Liebe, zuhören, Liebe zuhören falls sich das Thema genau
20:43
interessiert, hör gern noch mal in die spezielle Folge der Reihe
20:46
rein. Ich werd es jetzt nur noch mal
20:48
nennen. Wir haben ja so über Blue Green
20:50
Deployment gesprochen, Canary Deployment und das sind im
20:54
Prinzip Strategien um nicht zu 100% an alle direkt auszurollen
21:01
das neue Feature, sondern das sind Strategien um.
21:05
Sag ich mal noch mal zu testen, wie es denn ankommt, ob es
21:08
wirklich fehlerfrei läuft. Ja, also Blue Green ist halt,
21:12
dass ich im Prinzip wirklich sage, ich schalte um, kann aber
21:15
auch wieder zurückschalten. Ja, also ich habe jetzt wirklich
21:17
so ne Art Spiegelung mit dem neuen Feature und ja so n toggle
21:23
wirklich und man sagt Ah nee warte mal, warte mal da da ist
21:27
stimmt irgendwas nicht zack zurück ja.
21:30
Und Canary, um das noch mal kurz zusammenzufassen, ist ja im
21:33
Prinzip, dass ich prozentual ausrolle.
21:35
Das ist auch ne echt coole Strategie zu sagen, ich geb es
21:38
erstmal nur n gewissen Anteil meiner Kunden, es kann auch
21:41
zufällig sein und wenn da keine Rückmeldung kommen, dann kriegen
21:44
es halt noch mehr so und dann oh jetzt kommen die positiven
21:47
Feedbacks rein und mehr mehr mehr bis ich es irgendwann zu
21:50
100% verbreitet hab und das sind halt Strategien die man da im
21:54
Hinterkopf haben sollte und die halt auch wirklich absolut Sinn
21:57
machen, ja. Ja, richtig, und das ist halt
22:00
auch wieder ein Ding. Also dass gerade weil du ja
22:02
sagst, so okay, wenn was schief läuft, wenn das vielleicht beim
22:05
Kunden nicht so gut ankommt, ist natürlich die Frage okay aber.
22:08
Wie? Woher weißt du das?
22:10
Das, das kann man ja nicht jetzt ohne weiteres einfach so wissen,
22:13
sondern und da ist natürlich wieder ein Punkt, den besprechen
22:16
wir auch noch bisschen später im Monitoring, weil Monitoring ist
22:20
unglaublich wichtig, um halt eben auch zu.
22:23
Sozusagen die geeignete Automatisierung dann zu finden,
22:26
zu sagen, OK, ist das jetzt n einmaliger Fehler ist das jetzt
22:29
n Fehler der vom letzten Deployment kam und so weiter und
22:33
sofort, aber das ist essentiell dafür um überhaupt sowas machen
22:37
zu können. Ne was bedeutet aber auch
22:38
gleichzeitig, dass Continuous Deployment ja auch wirklich,
22:43
also wirklich NN höheren Aufwand einfach mit sich bringt am Ende.
22:49
Einen initialen Aufwand, wo man dann noch immer gucken muss okay
22:51
lohnt sich das fürs Projekt oder nicht?
22:53
Es ist natürlich immer sehr spezifisch, aber das muss man
22:56
halt einfach dann selbst abwägen.
22:57
Prinzipiell ist es natürlich eine gute Practice, das so dann
23:00
zu machen, genau und gerade auch weil du oder weil wir jetzt
23:06
davon geredet haben, ja, wenn sich ein Fehler einschleicht, da
23:07
kann man sich jetzt auch denken, ja, ci, wir haben noch gesagt,
23:10
alle Tests sind grün, Checks sind grün, es muss doch alles
23:12
passen, ja, das ist natürlich die.
23:16
Absicherung auf dem im ersten Level du kannst aber nie
23:20
hundertprozentig sicher sein, dass vielleicht doch irgendwas
23:22
schief läuft, was du eigentlich sogar nicht haben wolltest.
23:25
Also man ist dem halt irgendwie nie gewahrt.
23:29
Also ein Fehler kann trotzdem irgendwie mal, sagen wir mal
23:32
auftreten, irgendwas kann vielleicht nicht schmecken, dem
23:35
User beispielsweise oder es treten irgendwelche Side Effects
23:38
auf mit dem man halt wirklich nicht gerechnet hat, kann halt
23:42
einfach passieren. Es kann natürlich auch genauso
23:45
sein, wenn ich jetzt quasi die Artefakte baue, ne, also meine
23:48
Auslieferung zusammenbaue kann natürlich auch was schiefgehen.
23:51
Ja, also gerade wenn ich zum Beispiel externe Abhängigkeiten
23:54
hab, irgendwas hat sich geändert in meiner Software, dann ist
23:57
vielleicht meine Software an sich grün im CI teil aber im CD
24:01
teil lässt sich halt die Auslieferung nicht mehr
24:03
zusammenbauen, das kann auch sein, also hier gilt natürlich
24:05
auch wieder dieses schnelle Feedback am Ende ja definitiv.
24:10
Genau. Aber ein Punkt, der sehr wichtig
24:12
ist. Und das ist auch ne coole
24:13
Überleitung, weil du meintest, so was ist Delivery Deployment
24:17
der Unterschied und wenn ich featuresets in im gesamten
24:19
Ausrollen möchte, ne, deswegen haben wir ja auch in unserem
24:23
Grundlagen in unserer Grundlagenreihe das Staging
24:25
besprochen, weil es halt auch n enorm wichtiger Punkt ist.
24:28
Und genau damit kann ich ja jetzt sowas dann ermöglichen,
24:32
weil in unserer einfachen Kette, wie wir sie jetzt haben von
24:35
meinem Commit, den ich vorhin gemacht hab bis jetzt.
24:37
Ist alles sehr geradlinig. Ja, also so ne Einbahnstraße sag
24:42
ich mal. Klar, ich krieg mein Feedback,
24:43
aber es gibt nur eine Richtung und Staging ist ja jetzt genau
24:47
das, dass ich sagen kann, ich kann mehrere, wir hatten ja
24:52
damals in der Folge so diese Analogie von Spielen früher
24:56
genommen, ne, dass ich so verschiedene Stages hab wie ich
24:59
immer weiter komme sozusagen und ich find das ist halt auch
25:01
sinnbildlich sehr sehr treffend. Ich kann jetzt mehrere Etappen
25:05
sozusagen einbauen und. Wie weit möchte ich jetzt etwas
25:11
deployen? Zum Beispiel Wohin?
25:12
Auf welche Stage soll das landen?
25:14
Und da gibt es halt so am Ende immer diese sogenannte Prot
25:18
Stage, also die wirklich produktiv ist.
25:21
Da wo quasi sag ich mal der Kunde drauf sitzt was er
25:24
verwendet, am Ende zum Beispiel die Website, die wirklich live
25:28
ist. Ne die du dann über deine Domain
25:30
aufrufen kannst. Genau, aber jetzt kann ich ja.
25:34
Variabel davor mehrere Stages einbauen.
25:36
Ich kann zum Beispiel sagen, es gibt ne Develop stage, ja da
25:39
sammel ich jetzt meine Features, die Entwickler können drauf
25:43
zugreifen, alle kriegen quasi diesen Stand.
25:47
Wenn ich jetzt mein Feature entwickelt hab kann ich sagen ey
25:50
ich hab es deployed auf unsere. Develop Stage beispielsweise und
25:55
die anderen Entwickler können das Ausprobieren.
25:56
Also die können dann einfach darauf arbeiten, sie entwickeln
25:59
ja auch mit dem Stand weiter und wir sammeln so unsere Features
26:01
da, bis wir irgendwann sagen, so, dieser Stand geht jetzt auf
26:05
unsere produktiv Stage und jetzt viel Spaßkunde das wird richtig
26:09
geil, was wir gebaut haben, so ne genau eine Möglichkeit, was
26:13
siehst du denn noch so für Stages um das noch mal kurz
26:15
zusammenzufassen ja es gibt zum Beispiel, also was halt beliebt
26:18
ist ist auch sowas wie ne QR Stage also so.
26:21
Ich nenne es mal auf Deutsch Qualitätsmanagement Stage.
26:23
Also es gibt ja auch Anwendungen, wo es auch externe
26:27
Tester gibt, die dann noch mal wo die Software noch mal extra
26:30
von externen Testern getestet wird oder getestet werden muss,
26:33
auch manchmal. Das heißt, es gibt dann zum
26:35
Beispiel eine Stage, wo sich dann die Leute zum Beispiel
26:38
austoben können und halt eben nicht in der Produktivumgebung
26:41
testen sollen, weil du willst ja vielleicht zum Beispiel nicht
26:45
bei Instagram oder so 1000 user QR 123, User QR 555 oder weil.
26:51
Weißt du sowas, wenn du dir so denkst, was ist das hier alles
26:53
gerade nur mal so als Beispiel? Also du haust ja auch Daten in
26:57
die Datenbank rein, die du aber am Ende in der Produktivumgebung
27:00
nicht haben möchtest. Demzufolge kannst du halt den QA
27:05
also oder den Tester ne, die kannst du halt dann expliziten
27:08
Zugang zu einer Stage geben, die aber genauso funktioniert wie
27:11
Pod oder oder sehr sehr ähnlich ist.
27:14
Sag ich jetzt mal. Und da kannst du aber auch
27:17
andere Sachen testen, wie zum Beispiel, ob deine
27:19
Datenbankmigration funktioniert, weil es gibt, ich sag jetzt mal
27:22
n bisschen salopp gesagt, nichts schlimmeres, als wenn du ne
27:25
Datenbank migrierst und es failed und am Ende hast du
27:30
riesen Datensalat in deiner Datenbank.
27:33
Das ist halt nicht so geil und man kann sich das halt ungefähr
27:35
so vorstellen, dass ne, wenn du jetzt zum Beispiel sagst, meine
27:39
Website de beispielsweise ne, weil du Website gesagt hast.
27:43
Gibt es, kannst ja auch auf Apps, Münzen oder so, aber du
27:45
hast am Ende ne eigene Domain, ne, das ist dann zum Beispiel
27:48
sowas wie dev Punkt, meine website de oder QR Punkt, meine
27:51
website de und vielleicht hast du andere login Mechanismen,
27:55
dass du halt eben nicht in der Lage bist als produktiv User die
27:58
QR Stage zu verwenden und so weiter dass es halt gekapselt
28:01
ist. Ne, dass du vielleicht ein
28:02
bisschen, deswegen meine ich auch nicht ganz hundertprozentig
28:05
gleich. Dass du vielleicht noch eine
28:07
andere Anmeldemöglichkeit hast oder so, dass du eventuell
28:10
sagst, OK, wir schließen aber auch wirklich aktiv bestimmte
28:12
Usergruppen aus, ne, damit es halt eben wirklich isoliert ist.
28:16
Irgendwo ne für den entsprechenden Zweck, das ist
28:19
halt wichtig, ja, aber ich würde tatsächlich so weit gehen, dass
28:24
ich sagen würde, wenn wir etwas. Von der ganzen Sache, die wir
28:27
besprechen, so noch annähernd als optional hinstellen können,
28:31
dann ist es das Staging im Sinne von ne Protz Stage gibt es
28:35
immer, die ist auf jeden Fall wichtig, wenn du alles.
28:38
Richtig muss es hingehen. Aber wenn du alles richtig
28:40
machst, ist das irgendwie in Ordnung.
28:42
Weißt du, dann passt das so, aber deswegen, du kannst ja zum
28:46
Beispiel sagen, OK, ich bau noch ne Test stage ein, du musst aber
28:49
keine QR Stage haben, du kannst. Du hast Stage einbauen, musst
28:52
aber kein Test Stage haben. Du kannst aber auch 5 Stages vor
28:54
Port noch machen, deswegen das meine ich so ein bisschen mit in
28:57
Anführungsstrichen optional ne. Genau.
29:00
Also das ist ein sehr wichtiger Punkt, der halt relevant wird,
29:03
wenn es um skalieren geht, ne und wenn du mehrere Entwickler
29:05
rein kriegst, wenn es halt ein Riesenprojekt wird, dann wird
29:09
Staging irgendwann nicht mehr vermeidbar sein und dann ist es
29:12
auch richtig, es nicht mehr zu vermeiden.
29:14
Aber ich sag mal, du hattest ja auch gesagt, wenn man jetzt so
29:16
ein kleines Einzelprojekt hat, dann ist es vielleicht noch
29:20
nicht notwendig, wie du gerade meintest.
29:21
Also so in so einer ganz Lean Basic Pipeline muss es dann
29:25
nicht Teil davon sein, dann brauchst du zum Beispiel keine
29:29
Test Stage oder auch keine, weil ich meinte Death Stage wo Halt
29:33
so Features gesammelt werden, die aber auch sauber ist.
29:36
Also noch mal kurz zur Differenzierung, eine Test Stage
29:39
ist für mich halt etwas, da kann ich machen was ich will ja also
29:42
da. Länger yolo mäßig.
29:46
Ich kann da alles löschen. Ich kann Edge Cases
29:49
ausprobieren, ich kann richtig wilde Sau spielen da ja und ne
29:52
Death Stage ist für mich, aber wenn ich jetzt ganz viele
29:54
Entwickler hab ne dass die da alle auch ne ne saubere
29:57
Grundlage haben wo denn die Features wirklich integriert
30:00
sind. Und als korrekt geltend
30:02
sozusagen. Und das brauche ich nicht, wenn
30:05
ich alleine bin, wozu soll ich das machen, hast du natürlich
30:08
absolut. Recht, du meintest ja vorhin
30:10
auch schon bei den Checks, was man wirklich braucht und genau
30:13
hier gilt eben auch was, also bauen eine Stage auf für das was
30:17
du halt auch wirklich brauchst. Und weil ich ja auch meinte Okay
30:20
eine Stage muss vielleicht leicht anders konfiguriert sein,
30:24
also sie sollte sich gleich verhalten, kann aber anders
30:26
konfiguriert sein im Endeffekt und.
30:29
Und da ist eigentlich n ganz interessanter Punkt, weil wie
30:32
kann man zum Beispiel das ganze gut konfigurieren und damit du
30:37
halt zum Beispiel sagst, OK, du hast vielleicht ne Umgebung, die
30:40
immer gleich ist, ne auf der einen Seite, aber du.
30:44
Du hast auf der anderen Seite zum Beispiel kannst du diese
30:46
Umgebung halt eben auch irgendwie von außen noch
30:48
konfigurieren, ne, was ja schon mal dazu führt, dass du jetzt
30:51
sagst, OK, ich hab zwar meine Stages, die ich irgendwie
30:53
aufbaue, wo ich irgendwie meine entsprechende Anwendung in der
30:57
entsprechenden Stage hin deploye ne, aber du willst es ja nicht
31:03
plain einfach auf den Server ballern und sagen, OK, du hast
31:05
jetzt vielleicht hier Abhängigkeiten, also installiere
31:07
ich die alle auf dem Server und Let's go.
31:09
Ne, sondern da machen wir auch eine bestimmte Practice
31:13
sozusagen, die ich am Anfang angesprochen hab.
31:17
Ja, also man merkt schon, wenn es mehrere Stages gibt und das
31:20
ganze skalieren soll, dann kommt halt ein Punkt ins Spiel, der
31:24
unfassbar wichtig ist. Und ich finde es ist Best
31:26
Practice ihn von Anfang an einzusetzen.
31:29
Ja, und zwar reden wir jetzt von Infrastructure is Code und es
31:34
geht halt im Prinzip darum. Seine Konfiguration codiert
31:41
abzubilden, ja, also ich habe keine manuellen Schritte zu
31:45
sagen, ja, ich mache das hier, was welche Stage, ja du willst
31:50
eine Test Stage ja warte, da muss ich das so und so
31:52
Umkonfigurieren, sondern ich habe es in Code gegossen.
31:55
Ja es ist auch Versioniert zum Beispiel wichtiger Punkt ja also
31:59
ich habe Stände von meiner Konfiguration die ich auch
32:02
wiederherstellen kann und im Prinzip habe ich dann
32:05
unterschiedliche. Konfiguration um diese einzelnen
32:09
Stages dementsprechend aufzubauen und ich kann sie
32:12
immer wieder so aufbauen und dadurch nehme ich quasi die
32:17
Komplexität und den Zeitaufwand raus, den eine manuelle
32:22
Abarbeitung einfach hätte. Das heißt nicht, dass es nicht
32:24
komplex ist, diese diese das zu coden ja auf keinen Fall, das
32:28
kann auch sehr komplex und und nervenraubend werden, ja da will
32:32
ich, das will ich nicht schönreden.
32:34
Aber Fakt ist, wenn es läuft und nachweislich läuft, ja, also man
32:39
kann sowas natürlich auch überprüfen und testen, dann hab
32:42
ich das, dann hab ich diesen Stand und der wird funktionieren
32:45
und der wird immer gleich funktionieren am Ende und das
32:48
ist es ja worum es geht am Ende. Ja, also du hast ja gerade jetzt
32:52
so bei den ganzen Anwendungen, die man eben hat.
32:54
Du hast ja nicht nur ein Frontend und ein Backend, also
32:57
nicht nur irgendwie, sagen wir mal, ein Artefakt von deinem
32:59
Frontend Code und ein Artefakt von deinem Backend Code, sondern
33:01
du hast ja dazu noch irgendwie du brauchst ein Server wo das
33:03
drauf läuft, du brauchst eine Datenbank, du brauchst
33:05
vielleicht noch ein Load Balancer, weil deine Anwendung
33:07
so groß ist, dass irgendwie der die ganze Last ne von den ganzen
33:10
Usern die kommt irgendwie aufgeteilt wird auf.
33:13
Zum Beispiel mehrere Instanzen deiner deiner Anwendung,
33:17
beispielsweise ne. Du hast vielleicht irgendwie
33:20
noch ein Storage, weil du irgendwie Bilder und Videos
33:22
irgendwie anzapfen willst. Du brauchst einen credentials
33:25
Manager, weil irgendwie die Datenbank verschlüsselt ist und
33:28
so weiter und sofort und um das alles aufzubauen, ne, es ist
33:32
halt anstrengend so ne und das kannst du manuell machen, das
33:36
kannst du manuell machen und dann hast du es einmal gemacht,
33:38
dann hast du weil. Wenn ich jetzt aus eigener
33:40
Erfahrung spreche, so wenn du so infrastructures Code baust, das
33:43
ist immer so OK. Ich mach erstmal ich mach
33:44
erstmal das ich leg erstmal das an und jetzt sozusagen versuch
33:48
ich die Infrastruktur hochzufahren ah OK gibt n Fehler
33:51
warte mal da fehlt Parameter ah der ist required OK da muss ich
33:55
noch mal gucken in die Doku alles klar ach ja genau die
33:58
Datenbank muss verschlüsselt sein so als Beispiel ne so ne
34:01
und dann. Du hast richtig viele, also
34:03
meiner Erfahrung nach einige Iterationen um halt eben deine
34:07
Infrastruktur auch wirklich so aufzubauen.
34:09
Über infrastructures Code wie du es haben möchtest.
34:11
Das heißt es wie du meintest, es dauert.
34:13
Es dauert natürlich aber und das ist das Schöne, wenn du es
34:15
einmal hast ne dann funktioniert es halt und dann funktioniert es
34:21
deterministisch, das ist halt das schöne und nicht irgendwie.
34:25
Klar, wenn du noch mal n bisschen was ändern willst, dann
34:27
du änderst Kleinigkeiten auch alles in Ordnung, ne, wenn
34:30
vielleicht noch was schief geht und du sagst oh Gott ich hab
34:32
jetzt mich komplett in der Einbahnstraße manövriert ne bei
34:36
dieser infrastructures Code. Und du sagst, ey ich, ich krieg
34:39
meine Umgebung, die die ist kaputt irgendwie.
34:41
Ich hab richtig Mist gebaut OK nimm wie du meintest, du kannst
34:45
gucken in deiner Versionierung, das war der letzte Change, der
34:48
hat alles kaputt gemacht, das heißt ich geh von meinem, von
34:51
meinem, von meiner Git Versionierung beispielsweise
34:54
einen Schritt zurück, lösche meine komplette Umgebung, phasi
34:57
komplett wieder hoch und ich hab wieder n stand der wieder läuft
34:59
mach das mal manuell, das ist halt.
35:01
Ne krass. Gerade wenn du noch mehrere
35:03
Stages aufbaust und sagst, OK ich bau jetzt die def Stage auf,
35:06
ich bau jetzt zum Beispiel meine QR Stage auf, ich baue meine
35:08
Prod Stage auf, du musst das dreimal machen so und dann
35:11
denkst du dir vielleicht so ja OK, ich hab jetzt zum Beispiel
35:14
meine prod Stage und meine def Stage, aber ich brauch jetzt
35:16
noch ne QR Stage und dann warte mal was hab ich jetzt noch mal?
35:19
Was brauch ich jetzt wie hab in welcher Reihenfolge hab ich das
35:21
gemacht ich weiß es gar nicht mehr so hab ich jetzt zum
35:23
Beispiel das so konfiguriert oder so ich guck noch mal nach
35:25
und das ist funktioniert nicht, skaliert nicht und das ist halt
35:30
das wichtige um halt eben Infrastruktur infrastructures
35:33
Code zu haben, das heißt du hast würde ich jetzt einmal kurz
35:36
durchspielen Commit cicd und deine Stages, aber das Ganze das
35:41
kannst du. Du kannst es alles manuell
35:43
irgendwie aufbauen, aber infrastructures Code wir sind
35:46
hier wieder bei Automatisierung wird ja groß geschrieben bei def
35:48
Ops die braucht man um das gesamte zugrunde liegende System
35:53
auf also auf der die Pipeline läuft halt eben einfach.
35:57
Ich sag mal modern aufzubauen, Wartbar und Automatisierbar zu
36:01
machen. Ne, also auch das aufbauen der
36:03
Struktur selber sozusagen ne und auch einfach nachweisbar.
36:06
Ne, du kannst ja denn genau sehen, wie sieht meine CI aus,
36:10
wie sieht meine CD aus, welche Stages hab ich, das ist ja
36:15
nachlesbar so wenn das jemand manuell gemacht hast, dann musst
36:19
du die denjenigen Fragen sagen, was passiert da eigentlich, ja
36:22
ist ja ganz einfach hier, ich hab es vergessen.
36:27
Und so hast du es natürlich nachweislich in einer Version da
36:31
und kannst es quasi nachlesen, wenn du ja den Code verstehst.
36:35
Dahinter ne, ja richtig, und das ist einfach der Riesenvorteil
36:39
und was du meinst die Versionierung.
36:41
Ich kann Stände wiederherstellen, ne und auch
36:43
hier muss natürlich der Fokus sein, es schnell zu erkennen
36:46
falls was schief läuft um schnell reagieren zu können.
36:49
Ne also wie bei allen. Bestandteilen gilt das natürlich
36:52
hier auch genau, aber und damit man das auch machen kann, wie
36:55
ich meinte, irgendwas ist vielleicht kaputt an der
36:57
Umgebung, dafür brauchst du halt infrastructures Code ne oder
37:00
halb wen mit der Versionierung und und und.
37:02
Wichtig ist noch kleine Anmerkung, Es ist natürlich und
37:05
das muss man wissen, einfach von vom Feelinger, von der Anwendung
37:08
es es muss natürlich lesbar sein für die Umgebung, für die Cloud,
37:12
in der man das Halt zum Beispiel eben eben macht, ne, also
37:15
beispielsweise Azure ist nicht gleich ABS ne und die Reden auch
37:19
anders. Das ist wie ne
37:20
Programmiersprache. Du hast halt einfach
37:22
unterschiedliche Parameter, die du irgendwo einsetzen musst.
37:28
Die Sachen heißen anders und so weiter ne, aber ich denke das.
37:30
Ist klar. Also da muss man sich dann halt
37:32
in das Scripting quasi so n bisschen reindenken und
37:35
Reinlesen. Aber ich sag mal Konzepte sind
37:38
oft ähnlich, das hilft dann dabei ne und man sammelt so
37:42
seine Erfahrungen damit. Lass uns mal zu dem nächsten
37:45
Punkt kommen, der jetzt quasi entscheidend ist wenn wir sagen.
37:49
Wir sind jetzt, wir haben unsere Pipeline mit Infrastructure Code
37:53
aufgebaut. CI läuft durch, die Stages
37:55
laufen durch und wir entscheiden uns jetzt zu deployen,
37:59
beispielsweise ne, dann haben wir ja über einen Punkt
38:02
gesprochen, der auch super essentiell ist und zwar
38:06
containerisierung. Ja also wir haben über Container
38:09
und Orchestration gesprochen. Denn die Frage ist jetzt, wie
38:14
liefer ich denn das Ganze aus, was liefer ich aus?
38:17
Du hast ja jetzt beispielhaft gesagt, er stell dir einfach ne
38:19
exe vor oder so in modernen Lösungen, dabei sieht das ja
38:24
ganze n bisschen anders aus, ne, dann redet man ja oft von
38:27
Container, Docker fällt sofort als Wort, da haben wir auch ne
38:32
Folge drüber gemacht, die ich persönlich auch sehr sehr geil
38:34
fand, weil es einfach so ein cooles Thema ist.
38:37
Aber das würde ich gern mit dir auch noch mal so n bisschen
38:39
zusammenfassen. Ja.
38:41
Stellen wir uns vor, es reden sehr viel, immer von
38:43
Microservices. Ne, du hast halt ja kybernetes
38:48
Feld dann ne und das ganz ganz viele Container die da laufen in
38:51
deiner Umgebung und jeder hat so seine Aufgabe und jetzt stellt
38:55
man sich natürlich die Frage, gerade vielleicht als
38:58
Einsteigerin oder Einsteiger, warte mal was Microservices,
39:03
Hunderte Container, was geht da ab, ich hab eine Software so
39:07
weißt du. Und genau darum geht es ja im
39:10
Prinzip, dass man seine Anwendung zum Beispiel in
39:12
Microservices aufteilt. Ne, dass du gewisse Teile,
39:16
Aspekte, Aufgaben, auslagerst oder als eigenen Service
39:21
betrachtest und dann im Endeffekt eine Servicelandschaft
39:26
hast, die deine gesamte Funktionalität abbildet und das
39:28
läuft alles so in einzelnen Bestandteilen und da haben wir
39:31
über Container gesprochen. Und Container haben ja im
39:34
Prinzip die Aufgabe, ein Problem zu lösen, und zwar das IT Works
39:40
of my Machine Problem sozusagen. Nur weil du sagst, ich hab bei
39:44
mir auf meinem PC alles eingerichtet und wenn ich jetzt
39:47
meine Software laufen lasse, dann läuft das ja, das heißt ja
39:51
aber nicht in der Integration, wenn ich jetzt davon ausgehe,
39:53
ich habe ganz viele Bestandteile und ich lass das jetzt auf
39:56
irgendeinem Server laufen. Dass das da auch läuft, dann,
40:00
das ist ja nicht gewährleistet. Dann fehlt halt ein Package oder
40:05
n Klassiker ist es ne falsche Node JS version da installiert
40:10
und der Support ist nicht mehr gegeben und du kriegst auf
40:12
einmal da n Fehler hier keine Ahnung was du hier vorhast, das
40:15
läuft so nicht ne so geht. Und das sind, das sind halt
40:19
Klassiker, und die werden auf dich zukommen, wenn du dich
40:22
darum nicht kümmerst. Und dafür gibt es halt im
40:24
Prinzip auch Container, die denn dafür sorgen, dass du halt diese
40:28
Abhängigkeiten darin bündelst und sagst, OK, dieser Container
40:33
mit dieser Software, die ich deployen möchte mit diesem
40:35
Stand, bringt alles mit, um laufen zu können.
40:39
Ja, um das noch mal kurz zusammenzufassen, und das ist
40:42
halt n sehr essentieller Punkt und vor allem wichtig für deine
40:45
Pipeline um sauber deployen zu können und vor allem mit dem
40:48
Ziel, dass es am Ende auch läuft.
40:50
Ja, selbst wenn du auch nicht sagst, OK, ich mach alles in
40:52
Microservices, aber weil ich ja vorhin meinte, du brauchst
40:55
vielleicht n Load Balancer, weil du die Last verteilen willst,
40:57
weil zum Beispiel eine Anwendung, also eine Instanz der
41:00
Anwendung, nicht mehr ausreicht, dann brauchst du halt noch mal
41:02
genau die gleiche Anwendung woanders.
41:05
Und da kannst du einfach sagen, OK, ich fahr noch n neuen
41:07
Container hoch, der aber im gleichen in der sozusagen, der
41:10
aber auch mitorchestriert wird, beispielsweise ne, damit du halt
41:13
ja auch eben sagen kannst, OK, wo leite ich das denn hin, die
41:16
müssen ja auch irgendwie die gleiche Datenbasis auf die
41:18
gleiche Datenbasis zugreifen, damit es irgendwie funktioniert
41:20
und so weiter ne und weil ich zum Beispiel vorhin auch meinte,
41:23
angenommen du hast ne QR Stage und ne protzstage und.
41:26
Irgendwelche Tester wollen zum Beispiel auf die QR Stage gehen,
41:28
aber prod. User sollen da zum Beispiel
41:30
nicht drauf gehen. Könntest du beispielsweise den
41:34
wenn du jetzt einen Microservice hast und Authentication Service
41:38
könntest du zum Beispiel einfach die URL der URL eine andere
41:42
geben als zum Beispiel, also dem der Container, also sozusagen
41:46
der Container. Frisierten Anwendung ne andere
41:49
URL von außen reingeben wo du sagst, OK das ist Deine QA
41:52
Anmeldung und das ist deine prot Anmeldung ne, also dass du
41:55
einfach die URL änderst beispielsweise die du von außen
41:58
reingeben kannst, weil das ist zum Beispiel auch sehr wichtig
42:01
und ne Best practice, dass eine Umgebung selber nie weiß, dass
42:05
sie zum Beispiel def ist oder prot ist.
42:07
Das heißt im Code gegossen. Ne, du kannst halt sagen, OK, du
42:11
bist jetzt def von außen oder du bist prot.
42:13
Du kannst es dem von außen mitgeben, aber von innen würdest
42:17
du niemals sagen, OK ich bin jetzt def beispielsweise oder
42:20
ich bin prott genau ne ja. Das und das ist halt n wichtiger
42:24
Punkt um das Staging dann vernünftig auch umsetzen zu
42:27
können. Ne, dass du halt zum Beispiel
42:30
deinen Container hast für Test. Du gehst halt auf deine
42:33
Testdatenbank und den Prot gehst du auf deine echte Datenbank
42:35
beispielsweise und das wird halt in den Container mit Reingegeben
42:39
und wie du meintest, er weiß es nicht, es ist für ihn einfach
42:42
die Anwendung die läuft und das ist ja auch gut so.
42:44
Ja hast du ja gerade erklärt, aber das sind das greift, da
42:47
sieht man mal wieder, dass so ne Pipeline, dass all diese Aspekte
42:51
halt ineinander greifen. Und sich gegenseitig
42:54
unterstützen. Sagen wir mal, wenn du davon was
42:56
weglässt, fällt es dir halt schwer, es denn im gesamten auch
42:58
so umsetzen zu können. Genau, aber pass auf die nur das
43:02
Wichtigste ist finde ich und das ist auch wirklich ein sehr sehr
43:06
essentieller Punkt, noch mal ganz am Ende, weil es kann ja
43:08
überall irgendwo was auftreten, also in allen Sachen, wo wir
43:11
gerade irgendwas beschrieben haben, kann ja irgendwas
43:12
auftreten, wir haben ja auch zum Beispiel gesagt, Ey, wenn die
43:15
Tests failen, du musst ja irgendwie darüber benachrichtigt
43:17
werden, ne, also du kannst ja nicht sagen, ey, weiß ich nicht.
43:21
Meine Pipeline läuft normalerweise 20 Minuten.
43:23
Ich guck mal nach 5 Minuten schon mal prophylaktisch rein,
43:25
um einfach mal zu gucken okay ist es denn gefällt oder nicht,
43:28
das heißt du willst informiert werden darüber ob irgendwie die
43:32
CI gefällt ist, ob irgendwie das Deployment nicht funktioniert,
43:35
ob deine Infrastruktur irgendwie nicht richtig hochfahren kann
43:37
oder da vielleicht ein Problem ist, ob vielleicht irgendein
43:40
Problem innerhalb deines Containers oder deiner
43:42
Containerumgebung auftritt. Du willst quasi darüber
43:45
benachrichtigt werden, ob vielleicht irgendwelche Probleme
43:47
in deiner Anwendung fliegen, damit du irgendwie wieder deine
43:50
Deployment Strategie. Hier anwenden kannst zu sagen,
43:52
ich Rolle es wieder zurück und so weiter und sofort und gerade
43:55
im Zuge des neuen Features. Ja, was wir jetzt gerade
43:57
versuchen zu integrieren und zu deployen.
44:01
Genau. Und wenn du darüber nicht
44:03
Bescheid weißt, dann hast du eigentlich schon wieder n großes
44:06
Problem. Das heißt n sehr sehr wirklich
44:07
essentieller Punkt. Meiner Meinung nach ist halt
44:10
eben Monitoring und Observability ne, also was jetzt
44:12
beides genau ist. Wie gesagt haben wir ne Folge
44:14
drüber gemacht. Aber es ist definitiv wichtig,
44:16
um da um einfach irgendwie zu erkennen.
44:18
Okay, du hast Anomalien irgendwo in deiner Umgebung, irgendwo,
44:22
egal wo in in dem Ganzen, was wir gerade besprochen haben.
44:25
Und wichtig ist halt zu sagen okay, du hast eine Anomalie, du
44:28
kannst sie sehr schnell irgendwie erkennen und sagen
44:31
okay Pass auf, hier ist eine Anomalie und dann musst du auch
44:34
noch schnell dazu in der Lage sein zu sagen okay weiß ich
44:37
nicht, diese Anomalie ist ein Bug und der ist da, der Ursprung
44:40
ist darunter, das ist halt wichtig, dass man das schnell
44:43
machen kann und das. Dafür ist es halt einfach
44:46
notwendig, auch schnell benachrichtigt zu werden.
44:48
Also du kannst halt jetzt irgendein Tool nehmen und sagen,
44:50
ey hier ne, also du du sagst es fliegt zum Beispiel super oft
44:54
ein Fehler in deiner Anwendung, also kriegst du eine
44:57
Benachrichtigung auf irgendein Messenger beispielsweise der dir
45:01
sofort sagt EY Hallo hier Fehler.
45:04
Ne, und dann gehst du rein, guckst OK, da hab ich n Fehler
45:07
warum ah OK Zeile so und so in meinem Code oder hast du nicht
45:11
gesehen ne aber das ist halt unglaublich wichtig, genauso wie
45:13
wenn deine CICD Pipeline failed, dass du dann sofort ne
45:18
Mitteilung bekommst die dir sagt Ey das hat nicht funktioniert,
45:21
damit du sofort wieder reagieren kannst, ne.
45:24
Genau. Und ja, also im Prinzip haben
45:27
wir jetzt mit all diesen Punkten ja auch wirklich ne vollwertige
45:30
Pipeline geschaffen. Ja, also auch gerade mit dem
45:33
Monitoring, was du jetzt am Ende noch erwähnt hast, was im
45:36
Prinzip flächendeckend ist, das kann man sich wirklich so
45:39
vorstellen. Das sitzt über jede, über jeden
45:42
einzelnen Bestandteil, weil wir haben ja jedes Mal gesagt, ich
45:45
möchte schnell wissen, dass etwas nicht klappt, ich möchte
45:48
schnell wissen, ob es also auch geklappt hat.
45:51
Ja, also beide Fälle und deswegen ist das halt n
45:54
unfassbar essentieller Punkt, den du gerade angesprochen hast,
45:57
aber nicht aber und. Ich möchte noch zuletzt auf
46:01
einen weiteren Punkt eingehen, denn das ganze def Ops.
46:06
Ja, wir haben jetzt wirklich alles, gerade in den einzelnen
46:09
Folgen detailliert besprochen, um wirklich die Grundlagen
46:11
abzubilden. Aber wir haben ja ganz am Anfang
46:14
dieser Reihe um ein Thema, auch sag ich mal, uns Zeit genommen
46:19
für ein Thema, und zwar für das Mindset dahinter.
46:22
Denn so oft, wie wir jetzt gerade schon gesagt haben, ich
46:25
möchte Feedback. Ich möchte wissen, ob es
46:27
geklappt hat. Ich möchte vor allem schnell
46:29
wissen, wenn es nicht klappt, ja, also ich will einfach
46:32
Qualität gewährleisten, ich möchte sehen, dass etwas
46:34
funktioniert am Ende und wenn es nicht funktioniert, bitte sag es
46:38
mir so schnell wie möglich, damit ich es fixen kann.
46:40
Ja, das zeigt ja, dass man ein gewisses Mindset braucht und das
46:44
finde ich ist unfassbar essentiell, wenn es um das Thema
46:48
Dev ops geht und vor allem wenn man in dem Bereich.
46:52
Tätig sein möchte oder halt auch mal so eine Pipeline umsetzt,
46:55
dass man dieses Mindset mitbringt, weil man verwendet
46:58
viele Tools. Ja, es gibt unfassbar viele
47:01
Tools im Def Ops Bereich, allein um eine richtig coole cicd
47:06
Pipeline aufzusetzen, so in dem Basic in der Basic Form wie wir
47:11
sie jetzt besprochen haben, wirst du ja schon viele Tools
47:13
einsetzen, keine Frage. Also das Tooling ist gigantisch,
47:17
aber am Ende ist es unfassbar wichtig halt ein.
47:21
Ein richtiges Mindset in sich selbst zu verankern, ja, also
47:25
nicht so. Ja OK, ich nehme jetzt das Tool
47:27
da da, das haben die jetzt gesagt das das muss ich nehmen,
47:30
was war es ja hier Docker jut Docker hier komm wie
47:32
funktioniert das jut alles klar ja hier Tutorial AB fertig
47:36
funktioniert und das mach ich jetzt bei allem und dann hab ich
47:38
jetzt irgendwie so ne Pipeline die läuft irgendwie und fertig
47:42
also man muss halt auch n gewisses Mindset da einfach.
47:45
Mitbringen, weil, so wird es am Ende nicht laufen, ja, sondern
47:48
man muss sich fragen, wie kann ich etwas automatisieren und
47:52
warum automatisiere ich das vor allem auch ne das Ziel muss sein
47:57
mir so viel manuelle Schritte wie möglich abzunehmen, aber
48:01
nicht weil ich faul bin, ich sag es mal provokativ.
48:05
Sondern um quasi meinen Entwicklungsprozess vor mir
48:08
selbst zu schützen. Ich finde, das kann man
48:10
eigentlich so sagen, weil manuelle Schritte bedeutet
48:14
fehleranfällig und deswegen das Mindset zu haben, kann man da
48:18
was automatisieren, kann ich gewährleisten, dass es immer
48:21
gleich abläuft, das ist halt wichtig, ne und dann dieses
48:25
erkenne ich schnell, dass etwas schiefläuft, ich möchte bitte
48:27
sofort wissen, wenn etwas nicht läuft.
48:29
Ja. Na, ich finde es halt.
48:31
Ich habe halt oft gehört, so was wie es geht nicht, aber die
48:34
Frage ist halt finde ich eher so okay wie geht es, wie kann ich
48:37
das ermöglichen und das ist halt ein essentieller Teil und am
48:41
Ende geht es ja auch darum, dass man bei Def Ops eben nicht
48:44
einfach nur sagt okay ich muss jetzt hier irgendwie ne wie du
48:47
schon meintest, so eine Toolpalette anwenden, sondern es
48:49
geht darum Silos aufzubrechen, also gerade wissens Silos die du
48:53
irgendwo verankert hast, vielleicht unter Umständen oder
48:55
vielleicht verankern würdest in deinem Team und.
48:59
Und halt eben auch zu sagen, ich teile die Verantwortung über die
49:04
entsprechende, über den gesamten, über die gesamte
49:09
Anwendung sag ich jetzt mal. Und alles, was damit zu tun hat
49:12
durch halt eben Automatisierung und ja, es geht halt auch
49:17
irgendwo darum, Transparenz zu schaffen, ne, also dass du
49:20
sagst, OK ich hab ne Transparenz, Transparenz schafft
49:23
Vertrauen und. Und das ist halt am Ende das
49:27
Wichtigste. Das muss im Kopf sein.
49:29
Ansonsten funktioniert es auch nicht so richtig, Depp Ops
49:32
anwenden zu wollen, weil man es muss, sondern man möchte, man
49:35
muss es wollen, sozusagen nicht, weil man es muss, man muss es
49:38
wollen. Und deswegen auch noch mal
49:43
abschließend noch mal gesagt, Wir haben es schon oft gesagt,
49:46
diese Feedback und Fehlerkultur ist halt das Maß aller Dinge und
49:51
das muss gelebt werden. Ja, man muss zu Fehlern auch
49:53
stehen. Das Ziel ist, wie können wir sie
49:56
nächstes Mal vermeiden, was können wir jetzt verbessern,
49:59
damit diese Fehler nicht mehr auftreten.
50:01
Und das sind halt essentielle Fragen, die du dann stellen
50:04
musst. Am Ende ne nicht so wer war es,
50:06
ich war es nicht hier RR da drüben, da stehst du aber 5
50:09
hinten rechts in der Ecke was genau unser klassischer Business
50:13
Server nein es geht darum OK sprichwörtlich, das Kind ist im
50:18
Brunnen gefallen, es ist passiert.
50:20
Wie machen wir es besser nächstes Mal und ich finde diese
50:22
Fehlerkultur ist halt auch sehr essentiell im Def Ops teil.
50:26
Auch hier noch mal die Anmerkung, Wir hatten es damals
50:28
schon gesagt, dass Def Ops Handbook fantastisches Buch, wo
50:32
auch alle Punkte, gerade das Mindset finde ich sehr sehr gut
50:36
enthalten ist. Was sind es für Schritte, was
50:39
muss in meinem Kopf passieren, wie muss ich an so ne Sache
50:42
rangehen? Da auch noch mal die Empfehlung,
50:45
wir können auch gerne den Link noch mal in die Shownotes
50:47
packen, ist n wirklich sehr gutes Buch, richtig?
50:49
Ganz kurz bevor wir jetzt vielleicht die Folge
50:51
abschließen, will ich noch mal ganz kurz n kleinen Ausblick
50:53
geben und zwar es gibt ja def Ops, vielleicht hat der ein oder
50:56
andere. Auch schon mal sowas wie def sec
51:00
ob es gehört ne. Im Endeffekt ist das so ich
51:02
vielleicht so die logische Erweiterung, dass man halt sagt,
51:05
OK nicht es ist nicht nur Development and Operations
51:07
sondern Security kommt mit rein, weil oftmals ist es so, dass in
51:11
Anwendung Security irgendwie nachgelagert wird, so nach dem
51:13
Motto Wir bauen erstmal die Anwendung und dann gucken wir
51:15
mal. Was kann man denn Security
51:16
technisch noch vielleicht verbessern?
51:18
Hier ist es so, dass Security da nicht nachgelagert wird, sondern
51:21
eher so bei Design mit in den Entwicklungsprozess von Anfang
51:25
an integriert wird. Ne und dann wird halt eben aus
51:28
Def Ops def sec ops. Ja also ich sag mal so es ist
51:32
auf jeden Fall im groben soll es halt die Haltung da also.
51:38
Mitgeben dass Security ist eine Verantwortung von jedem für
51:42
jeden, der Halt Software entwickelt oder Infrastruktur
51:45
aufsetzt oder was auch immer, ist ein essenzieller Teil und
51:47
wenn es irgendwie mal ein Interesse gibt zu sagen, okay
51:49
können wir vielleicht defs Hack Ops noch mal ein bisschen
51:52
vertiefen. Im Podcast können wir gerne auch
51:53
noch mal machen, noch mal eine Folge drüber machen, also Liebe
51:55
zuhören, lieber Zurer sagt auf jeden Fall Bescheid.
51:58
Ja, und warum das so extrem wichtig ist, haben wir in der.
52:04
Einer der letzten Big Fails folgen gezeigt der solarwinds
52:08
Fall war ein perfektes Beispiel, warum auch dieses Bestreben oder
52:13
das Denken Richtung Defsac Ops gegangen ist.
52:17
Ja, weil das war halt ein Riesending mit extrem hohen
52:20
Schäden. Und deswegen hatte man dann auch
52:22
gesagt, so vielleicht sollte man im deffops Bereich auch so ein
52:26
Security by Design betreiben. Also gute Anmerkungen und Liebe
52:29
zuhören, Liebe zuhören, falls du da Bock drauf hast, schreib uns,
52:32
wir können uns gerne mit dem Thema auseinandersetzen, ist
52:34
auch wirklich ein sehr coole, sehr cooler Punkt ansonsten fabi
52:40
es ist leider soweit, ich muss es jetzt leider sagen, damit
52:43
haben wir unsere geliebte Deffops Reihe erstmal als
52:46
Grundlagenreihe abgeschlossen. Es war mega cool.
52:50
Vielen Dank noch mal an dich dafür.
52:52
Ich liebe es über dev Ops mit dir zu sprechen, liebe Zuhörer,
52:56
liebe Zuhörerin, ich hoffe, dir hat die Reihe auch gefallen,
52:59
falls es vielleicht die 1. Folge war und du jetzt sozusagen
53:02
dieses Chi Chi bekommen hast. Ne mit diesem gesamten
53:05
Überblick, hör auch gerne noch mal in die anderen Folgen rein,
53:07
da haben wir alles detaillierter besprochen.
53:10
Wenn du dir jede Folge angehört hast, schwören wir dir, dann
53:13
hast du das Def Ops wissen in den Grundlagen, dann weißt du
53:16
wie es läuft. Kannst du mitreden, du bist def
53:19
Ops dann und ansonsten würde ich sagen Liebe zu Liebe zu und
53:24
falls dir der Podcast grundlegend gefällt oder halt
53:27
auch speziell diese Folge empfiehlt ihn gerne weiter, lass
53:30
ne Bewertung da, das würde uns mega freuen, dass du unterstützt
53:33
uns ungemein. Das Glöckchen was Fabi schon
53:38
erwähnt hat, wichtig, wichtig, ich wusste es nicht.
53:40
Ich hoffe du weißt es jetzt und hast drauf geklickt falls du
53:44
Fragen hast zu def aufschreibt uns die Podcast Mail wie immer
53:47
in den Show Notes Anmerkungen immer gerne her damit.
53:51
Ja wir tauschen uns super super gerne damit aus auch auf dem
53:55
Discord, schau gerne vorbei, da gibt es jeden Tag Diskussion zu
53:58
Themen ist richtig cool wir lieben unsere Truppe, da ist es
54:01
einfach mega cool mit den Leuten und und ansonsten würde ich
54:05
sagen, hören wir uns alle beim nächsten Mal wieder.
54:07
Bis dahin ne gute Zeit euch allen ciao ciao deine Codening
54:11
Bodys gemeinsam besser.