Latest / Coding Buddies | Tech & Dev-Mindset / DevOps #5 - Staging: Die Generalprobe für deinen Code

Transcript

DevOps #5 - Staging: Die Generalprobe für deinen Code · Coding Buddies | Tech & Dev-Mindset

0:00
Das heißt, der End User ist der Endgegner.
0:03
Genau den gilt es zu bezwingen, ihn zufrieden zu stellen.
0:07
Es ist noch viel, viel schwieriger, ihn zufrieden zu
0:09
stellen als zu bezwingen. Coding Buddies Dein Podcast rund
0:12
um Softwareentwicklung und aktueller Tech News herzlich
0:16
Willkommen. Halli Hallo und herzlich
0:30
Willkommen zur neuen Folge vom Coding Buddies Podcast.
0:33
Es ist wieder soweit, die 2. Folge im Jahr 2025 steht an und
0:39
damit würde ich sagen, Tino, Ich heiße dich hiermit herzlich
0:42
willkommen. Wie geht es dir?
0:44
Ja, also wunderbar geht es mir. Hi Fabi, Grüße dich, was geht
0:48
ab, was? Geht ab.
0:49
Ich habe gerade ganz kurz überlegt, welches.
0:52
Jahr wir haben. Ich weiß nicht, kennst du das,
0:56
wenn du frisch ins neue Jahr gestartet bist und dir denkst
0:58
so? Es ist 20 Jahre ja doch ein Jahr
1:02
mehr als letztes Jahr 20. 44555. Ich hab das früher in der Schule
1:07
hab ich immer regelmäßig, wenn du n Test oder so im neuen Jahr
1:10
entstand hab ich immer das falsche Datum draufgeschrieben.
1:12
Am Anfang musste ich immer wieder wegkillern und dann neu
1:16
hinschreiben. Wegkillern das ist so n geiler
1:18
Begriff, so n tintenkiller, ja. Er tötet die Tinte.
1:23
Ja, die einfach irgendwann. Das schmiert ja irgendwann
1:25
einfach nur noch rum und sieht super Scheiße aus.
1:27
Dann also war bei mir immer so, vielleicht muss man die
1:29
irgendwie pflegen oder so die. Stifte?
1:31
Keine Ahnung. Aber ich fand die immer fand.
1:33
Also eigentlich ist es ja sauberes Durchzustreichen und
1:36
hinzuschreiben, noch mal so ganz akkurat.
1:39
Ja, also weil das das hat immer so Rumgeschmiert sorry off
1:43
topic, aber das Triggert nicht, du merkst das ist so n so n
1:46
Wunder Punkt aus meiner Kindheit.
1:49
Ja OK, aber ich ich hab ich hab immer du bist kein Linkshänder
1:52
ne weil ich hab nämlich immer ich hab immer Linkshänder da
1:55
dachte ich immer so Mensch die Armen weil wenn die mit Tinte
1:59
geschrieben haben die sind ja dann quasi mal über das
2:01
Geschriebene sozusagen gleich mit der Hand drüber ja und dann
2:04
haben die es auch verschmiert, außer dann dass sie dann die
2:06
Hand so oben gehalten haben. Es gab ja nun mal so
2:09
verschiedene Techniken, aber das fand ich immer dachte ich mir
2:11
immer so ey puh Gott sei Dank bin bin ich, also bin ich
2:15
Rechtshänder, weißt du? Ja, da hab ich tatsächlich noch
2:17
nie drüber nachgedacht. Nee, mich hat das immer.
2:20
Ich dachte immer, Mensch, ey, das wird mich jetzt irgendwie
2:22
nerven. Ja versteh ich, versteh ich oder
2:26
oder haben die haben die denn immer automatisch so
2:28
automatisiert gepustet, damit das schneller trocknet?
2:31
So beim Schreiben weißt du kennst.
2:35
Du das wenn du n Luftballon aufpustest, dann wird ja
2:37
schwindelig. Dann immer so n Diktat schreiben
2:41
pusten und dann hinterher war es klappen.
2:43
So einen Aufsatz mit 800 Wörtern?
2:46
Nein, aber das ist echt ein Punkt, da habe ich noch nie
2:50
drüber nachgedacht, das ist echt stimmt, hast du recht, ziehst du
2:53
rein, Mann, ziehst du, das ist krass, das ist so, das ist so
2:56
voll ne Lücke im System ey ja da brauchst du vielleicht so einen
2:59
kleinen Handkarren weißt du links nach rechts lesen ey
3:02
klasse stell. Dir mal vor, du hast so einen
3:03
kleinen Handkarren, da kannst deine Hand drauflegen und dann
3:05
fährt die immer so weißt du mit so genau über die Schrift
3:08
drüber, das wäre doch geil. Patent ist angemeldet.
3:13
Das wär echt krass, aber ist auch n spannendes Thema.
3:15
Ich hab letztens irgendwann gehört, dass es eigentlich viel
3:18
mehr Linkshänder gibt als statistisch erfasst oder als
3:22
Leute die wirklich denken sie sind Linkshänder, aber dass es
3:25
halt so gesellschaftlich aufgedrückt ist mit Recht zu
3:28
schreiben beispielsweise, dass eigentlich von der Natur aus
3:31
viele mit links schreiben würden, fand ich ziemlich krass,
3:35
aber siehst du, du hast n perfektes Beispiel gebracht, ja.
3:40
Also dadurch allein schon die die Schriftrichtung, die die sag
3:44
ich jetzt mal suggeriert halt, dass es besser wäre.
3:46
Aber es ist halt was soll ich sagen, am Ende schreibt man
3:51
hinterher doch nur noch mit der Tastatur.
3:52
Also ich muss ganz ehrlich sagen, ich meine Schrift ist
3:55
richtig schlimm geworden seitdem ich nur noch an der Tastatur
3:58
sitze, aber ist doch so ewig denn ne aber es bringt die
4:04
Softwareentwicklung halt eben mit sich.
4:06
Ja, ist so. Also lieber zur lieber zur du
4:09
merkst off topic können wir also kommen wir mal zur Folge
4:14
beziehungsweise Nein ah noch n bisschen off topic, eine Sache
4:17
haben wir noch ganz ganz wichtig am Anfang Fabi erzähl mal.
4:19
Ja, wir wollen uns auf jeden Fall noch mal ganz, ganz
4:21
herzlich bei euren Spenden bedanken, und zwar zum Beispiel
4:25
bei Dirk. Vielen, vielen Dank und auch bei
4:29
Kai Kai hat auch geschrieben, dass er sich für unseren tollen
4:32
Podcast bedanken möchte und in jeder Folge was Neues dazu lernt
4:36
und wir ihm mit dem Podcast auch schon richtig geholfen haben.
4:39
Bei dem Einstieg in die IT Welt und dass wir weiter so machen
4:42
sollen und Kai vielen Lieben dank auch an dich und wir werden
4:45
auf jeden Fall weiter so machen. Ja, und dann auch noch bei
4:49
Franziska. Franziska hatte nämlich das
4:52
letzte Thema vorgeschlagen, was wir ja letzte Woche tatsächlich
4:56
behandelt hatten, und zwar das im Poster Syndrom.
4:59
Franziska noch mal vielen vielen Dank für diesen Themenvorschlag.
5:01
Das Thema war auch mega spannend, es hat Mega Spaß
5:04
gemacht darüber zu reden, weil es auch ein ernstes Thema ist.
5:06
Und vielen Dank für deine Spende.
5:08
Ja, vielen, vielen Dank und liebe Zürerin lieber zürer, wenn
5:11
du Lust hast und sagst, Ey, ich finde die beiden auch cool, die
5:16
möchte ich gerne auch unterstützen, dann kannst du das
5:18
auch gerne tun. Der Link.
5:21
Zu der Unterstützung sozusagen ist in den Show Notes.
5:25
Verlinkt genau so. Jetzt haben wir es fabi, jetzt
5:29
können wir. Anfangen fahren wir los.
5:31
Jetzt sind. Die stimmen warm.
5:32
Jetzt können wir loslegen. Wir starten genau, wir starten
5:34
in die Folge rein und es gibt geht mal wieder in dieser Folge.
5:38
Wir wollen die Def Ops Reihe fortführen und zwar geht es also
5:42
jetzt um eine neue Def Ops Folge und zwar um das Thema Staging,
5:47
weil. Wir hatten ja jetzt in den
5:50
letzten beiden Dev Ops folgen ging es ja zum, also ging es ja
5:53
auch um CI und CD, also Continuous Integration,
5:56
Continuous Deployment Delivery und da haben wir auch schon ab
6:03
und an mal über Staging gesprochen und da haben wir
6:05
gedacht, jetzt wollen wir mal ne Folge über Staging machen um
6:09
einfach mal zu klären, was ist eigentlich genau staging und
6:14
also was kann man sich darunter vorstellen.
6:17
Ne, dieses dieses, dieser große Begriff dahinter.
6:20
Ja erstmal find ich n super cooles Thema, weil es auch
6:25
unsere bisherigen Def Ops folgen jetzt irgendwie bündelt und in
6:30
einen gesamten Kontext bringt. Auch wie du schon meintest, wir
6:33
haben ja über CI und CD gesprochen, also wir haben es
6:36
quasi jetzt an dem Punkt geschafft unsere Änderungen zu
6:38
integrieren. Auch die Tests laufen zu lassen
6:41
und das Ganze zu delivern beziehungsweise zu deployen.
6:45
Wenn wenn quasi ne Änderung vorgenommen wurde.
6:48
Aber die Frage ist, wie sieht jetzt so so n Ablauf aus und wie
6:52
gestaltet man das strategisch gut und da kommt jetzt auch so
6:56
das Thema Staging halt dazu um das Ganze irgendwie auch
7:00
zusammenzufassen. Genau.
7:02
Und Staging ist für mich persönlich sind das irgendwie so
7:06
2 Sachen. Die jetzt zusammen spielen, aber
7:09
so gedanklich mal. Einerseits ist es für mich ne
7:12
Art Methodik, also die in Death Ops verwendet wird, also was
7:16
strategisches auch und andererseits ist es auch was
7:20
Greifbares, weil es für mich halt auch diese Umgebung sind,
7:25
die man sich schafft um zum Beispiel ne gewisse Strategie
7:27
umzusetzen. Das heißt, du hast halt wirklich
7:30
was, sozusagen was klar, virtuell, aber was greifbar ist.
7:34
Und für mich ist es halt auch ne Methodik.
7:35
Ich weiß nicht wie du das siehst, um das erstmal so
7:38
voranzustellen. Ja, also gehe ich auf jeden Fall
7:41
mit. Also wenn man das jetzt erstmal,
7:43
wenn man jetzt so staging oder so so ne Stage sozusagen sehen
7:47
möchte, dann ist es im Endeffekt eigentlich ne sagen wir mal ne
7:50
spezielle Umgebung. Jetzt sagen wir mal innerhalb
7:53
der Softwareentwicklung. Und zwar ist es eigentlich ne,
7:56
Na ja ne annähernd reale Produktionsumgebung oder es wird
8:00
ne Produktionsumgebung simuliert ne und da ist es natürlich so,
8:06
dass das ist das was du meintest, ne das ist halt ne
8:08
Methodik, weil du halt sagen kannst OK stages staging das
8:12
sind so, du kannst unterschiedliche stages dir.
8:16
Sag ich mal erschaffen. Du kannst sagen, ich nehme die
8:18
Stage, ich nehme Stage ABC, du kannst es ja selbst benennen,
8:21
rein theoretisch, da gibt es zwar, ich sag mal gängige
8:25
Staging Namen, aber an sich ist es eine Methodik und es ist auch
8:29
irgendwie was festes, so was Greifbares, weil es ja wirklich
8:34
wie diese Anwendung die du baust ist, die du auch mit der du auch
8:39
arbeiten kannst und bloß halt eben nicht, dass es wirklich
8:42
dann im Endeffekt unbedingt die Produktionsumgebung ist, also
8:45
die Umgebung, die der End User am Ende auch nutzt.
8:49
Genau das ist nämlich n wichtiger Punkt.
8:52
Die Umgebung, die der Endanwender am Ende nutzt.
8:55
Wie du so schön gesagt hast, ist ja so die Finale Stage am Ende
8:59
genau und du hast irgendwo n Beginn wo deine Änderung
9:02
sozusagen. Entstehen und dann quasi
9:05
Staging. Das Prinzip dahinter von Stage
9:08
zu Stage weitergeleitet werden, bis du am Ende dein Ziel
9:12
erreicht hast. Und zwar ist an den End User
9:15
auszurollen und er kann es verwenden.
9:17
Produktiv, also in deiner Produktionsebene Stage so und
9:22
ich finde als Analogie woran ich bei diesem Begriff immer denken
9:25
muss ist so an meine Kindheitstage und noch mal ein
9:27
bisschen off top so. Super Nintendo Frühjahr, wenn du
9:32
so ein Spiel hattest und du wolltest das unbedingt
9:34
durchspielen, was ja am Ende nichts anderes ist.
9:36
Du fängst am Anfang an und willst irgendwann so das letzte
9:38
Level erreichen und dann hast du ja mehrere Level, oder?
9:42
Damals hieß es ja auch so Stage One, Stage Two, gerade in so
9:46
verschiedenen mir fällt jetzt kein direktes Spiel ein, aber so
9:50
wo du halt so mehrere Abschnitte hattest quasi und.
9:54
Das daran muss ich immer denken, dass du halt sagst.
9:56
Ja OK, die Stage hab ich geschafft, jetzt komm ich zur
9:58
nächsten und ja, hier auch geschafft und immer weiter bis
10:00
du dein finales Ziel erreicht hast.
10:02
Und ich find diese Analogie passt halt in diese def Ops Welt
10:05
halt auch rein wie weit kriege ich meine Änderung?
10:08
Ja OK die Tests sind bestanden, ey wir können es da jetzt auf
10:11
die nächste und auf die nächste Wir gehen ja gleich noch auf die
10:14
genaueren Stages ein, aber du kannst es halt immer weiter
10:17
ziehen. Bis es am Ende der Endkunde
10:19
nutzen kann und zufrieden ist. Genau, und da hatten wir auch
10:22
zum Beispiel in der Continual, also in der CD Folge.
10:25
Sozusagen hatten wir auch darüber gesprochen, dass man ja
10:30
auch wo, wo man hin deliver sozusagen ne, und da kann man
10:35
jetzt auch differenzieren und sagen, OK, klar, wenn du
10:37
sozusagen deine Software deliverst ne oder Deployest,
10:41
dann geht das ja an den End User zum Beispiel, also irgendwann am
10:46
Ende. Ne, aber du kannst rein
10:48
theoretisch auch wenn du jetzt zum Beispiel von einer
10:50
Auslieferung sprichst, rein theoretisch auch auf ne andere
10:54
Stage ausliefern. Ja, und das wird ja auch so in
10:57
der Praxis als Best Practice gemacht.
10:59
Das ist ja nicht nur in der Theorie so, sondern du deliverst
11:03
ja oft auch Änderungen, zum Beispiel an Stakeholdern, was am
11:06
Ende aber nicht dein Endkunde ist, sondern vielleicht nur
11:10
irgendwer aus einem anderen Team, der damit arbeitet oder
11:12
damit testet, wie auch immer. Aber du hast ja nicht nur die
11:16
Endkunden oder die End User als Kunden sozusagen.
11:19
Ja, genau, aber trotzdem würde ich halt auch sagen, dass am
11:23
Ende sozusagen also prot. Produktiv ne, also produktiv die
11:28
die Stage sozusagen die der End User am Ende nutzt.
11:31
Sag ich jetzt mal. Das ist ja irgendwo auch ne
11:33
Stage, ne. Also manchmal wird halt gesagt,
11:36
alles was vor produktiv kommt sind stages oder das Staging und
11:40
produktiv ist nicht mehr, das ist keine Stage, würde ich jetzt
11:44
aber schon so sehen, dass ja das was der End User nutzt, die
11:48
produktive Anwendung, also die Prot.
11:50
Stage ist, dann wirklich quasi auch eine Stage, das heißt rein
11:54
theoretisch die kleinste Möglichkeit vom Staging ist.
11:57
Du hast sozusagen deine Integration, deine Tests laufen
12:01
und du lieferst sozusagen deinen Artefakte Anwendung.
12:05
Deine neuen Änderungen, deine neuen Features genau direkt
12:07
sozusagen auf die Produktivstage.
12:08
Ne, so ist für mich aber auch ne Stage OK, also da da bist du
12:13
nicht alleine. Ich für mich ist das auch immer
12:16
so die Finale Stage am Ende genau.
12:19
So aber wenn wir jetzt gucken, was ist jetzt eigentlich, also
12:21
man kann jetzt sagen, okay, es gibt stages, man, man hat jetzt
12:24
verschiedene Stages, vielleicht bevor man zur Prot Stage kommt,
12:29
klingt ja erstmal alles ein bisschen so okay, warum macht
12:32
man das was, was soll das eigentlich und im groben und
12:34
ganzen geht es ja darum, dass man, machen wir mal ein fiktives
12:38
Beispiel, wir haben unsere Prot Stage, die wir gerade
12:40
beschrieben haben, und wir haben noch irgendeine Stage davor.
12:45
Ne sagen wir mal unsere Stage X erstmal ne und diese und diese
12:52
Stage x ist jetzt dafür da, dass man halt eine
12:55
Produktionsumgebung simuliert, also die trotz Stage simuliert,
12:59
also möglichst versucht, versucht reale Bedingungen oder
13:03
realitätsnahe Bedingungen zu schaffen, so wie der End User
13:06
sie auch eigentlich hätte und auf dieser Stage hat man dann im
13:10
Endeffekt die Möglichkeit Fehler zu finden.
13:13
Beim Entwickeln oder bestimmte Tests werden darauf ausgeführt
13:19
oder irgendwelche externen Tester sag ich jetzt mal testen
13:24
etwas auf dir oder ne du hast halt irgendwie etwas was du
13:27
darauf prüfen kannst, hast aber nicht sozusagen den Einfluss auf
13:33
die Daten, die du dann zum Beispiel wirklich also
13:35
angenommen du hast weiß nicht tausende von End Usern.
13:39
Und du hast irgendeine Datenbank, wo irgendwelche Daten
13:41
drin stehen und irgendwas geht auf.
13:43
Der Test Stage Chief rein theoretisch was alle user Daten
13:47
kaputt machen würde, dann hast du genau die Möglichkeit sowas
13:50
im Vorfeld zu testen bevor das dann wirklich in beim End User
13:55
bei der bei der echten Anwendung auftritt und irgendein
13:57
schwerwiegendes Problem stattfindet.
13:59
So und genau dafür ist dieses dieses Staging da, dass man halt
14:03
genau zum Beispiel bei einer Web App oder so ne, dass du zum
14:07
Beispiel sagst OK. Funktionieren irgendwelche API
14:10
Calls zu anderen Systemen? Funktionieren Datenbankzugriffe
14:13
so wie sie sollen und so weiter und sofort ne auch Stichwort
14:18
datenbankmigration wenn du wirklich sagst okay man muss
14:22
irgendwie Daten migrieren, dass das auch alles ordentlich
14:27
vonstatten geht datenbankmigration Liebe zürin
14:29
lieber zürer, wenn es dich interessiert, dann können wir
14:32
dazu auch noch mal eine Folge machen, ist glaube ich jetzt
14:33
würde das systemisch sprechen. Da kannst du 1000 folgen zu
14:37
machen. Ich finde, ein wichtiger Punkt
14:40
dabei ist oder ein großer Vorteil, der jetzt da schon
14:44
durchgeschimmert ist, ist halt, dass du mit Hilfe einer weiteren
14:47
Stage dein Risiko extrem minimieren kannst, weil du halt
14:52
deine produktive Umgebung, wo tagtäglich Kunden mit Arbeiten,
14:56
nicht an fest an der Stelle, das heißt, du hast Änderungen,
15:00
vielleicht neue Features, irgendwelche Abänderungen, die.
15:04
Wirst du halt erstmal dann testen auf einer gesonderten
15:08
Stage, ohne dass du deine eigentliche Umgebung
15:10
beeinflusst. Und das ist halt ein sehr, sehr
15:12
entscheidender Faktor dabei, wie du schon meinst, wenn da
15:15
irgendwie zum Beispiel ne Datenbank Migration schief
15:18
läuft, dass du das halt nicht auf echten Daten machst, einfach
15:22
weil wenn dann das Telefon klingelt, weil alle Kunden
15:25
anrufen. Hey, der Service funktioniert
15:26
nicht mehr oder ich kann mich nicht mehr einloggen oder was
15:29
auch immer dann passiert. Das ist ja so der absolute Worst
15:32
Case und damit kannst du das Risiko extrem minimieren, indem
15:35
du das Halt auf einer gesonderten Stage auf der Stage
15:38
X, wie du so schön gesagt hast. Das ist total mysteriös, keiner
15:40
weiß, was da abgeht, das da halt im Vorfeld überprüfst einfach
15:48
und sagen wir mal so so ne Stage X wird ja oft QR Stage genannt
15:55
für Qualitätssicherung, Quality Insurance und.
16:00
Das ist halt genau dafür da, um vielleicht auch einfach
16:04
erweiterte Tests laufen zu lassen, die du jetzt nicht jedes
16:07
Mal bei jeder Änderung in der Integration laufen lassen
16:09
möchtest, wo einfach halt noch mehr überprüft wird am Ende,
16:13
weil das Halt, wie du so schön meintest, so nah wie möglich an
16:17
die Realität herangeht. Diese Stage an die produktive
16:21
Ebene und man so sehr realitätsnah auch testen kann
16:24
und. Genau.
16:25
Also im Normalfall hast du halt, wenn du jetzt, sagen wir mal, du
16:28
hast irgendwelche Unit Tests oder du hast zum Beispiel
16:30
irgendwelche Systemtests, die laufen automatisiert im Vorfeld,
16:34
ob du überhaupt guckst, ob dein Code integriert wird, dann bist
16:37
du ja an diesem an dieser Stelle, wo dein Code getestet
16:40
wird. Das sind aber diese wirklich
16:42
sehr automatisierten Tests und da hast du meistens ja
16:46
beispielsweise auch wenn du externe Services hast, es das
16:49
wird ja alles weg gemockt und da, da nutzt du ja nicht
16:53
wirklich. Echte externe Services, die du
16:56
vielleicht irgendwie angebunden hast in der Anwendung und das
16:58
ist auf jeden Fall auch ein krasser Unterschied von so sage
17:01
ich jetzt mal reinen Testfällen, die irgendwie automatisiert
17:05
laufen und wirklich solchen Stages.
17:06
Also das sind wirklich eine Stage, ist wirklich eine, die
17:09
die Anwendung, so wie sie da ist und du kannst damit arbeiten,
17:14
rein theoretisch und ich finde es ganz gut, dass Du
17:17
angesprochen hast, zum Beispiel eine QR Stage, das ist auch eine
17:20
Stage, die ich. Oft kenne die mir oft, sag ich
17:24
mal, auf die mir oft begegnet ist, genauso wie zum Beispiel ne
17:27
Death Stage Development auch n sehr gutes Beispiel und so Prot
17:32
hatten wir eh schon genannt. Also ich kenn also ne Death
17:36
Stage kenn ich zum Beispiel, dass man einfach wirklich diese
17:38
Anwendung aufbaut und als developer Team kannst du auf
17:42
dieser Stage machen was du möchtest.
17:44
Ne, also du hast wirklich freie. Freie Spielwiese kannst du n
17:49
bisschen rumprobieren, wenn du selber auch mal n bisschen was
17:52
machen möchtest. Ne QR Stage ist dann meistens
17:56
schon n bisschen weiter, dass du halt jetzt gar nicht so als
17:59
developer Team sag ich jetzt mal darauf rumspielst, sondern dass
18:03
es wirklich wie du meintest ne quality Insurance.
18:05
Da werden dann bestimmte. Qualitätsmerkmale,
18:09
Sicherheitsaspekte gecheckt und um dann zu gucken, OK, läuft das
18:14
jetzt und dann können wir das Ganze auch weiter auf die
18:17
Produktivstage packen. Ja, ich finde es ganz
18:22
interessant mit der. Death Stage Weil die ist auch
18:26
sehr wichtig, gerade wenn du jetzt wie du meintest im
18:29
Entwicklerteam arbeitest, weil dieses Geradlinige, was wir am
18:33
Anfang meinen so ne minimal so n minimalstaging ist.
18:36
Ich hab n Entwickler er entwickelt was und er ist sich
18:40
sicher, dass das funktioniert, so sicher wie man sich sein kann
18:43
und es wird halt direkt auf prod geändert und das ist so eine
18:47
Stage dann am Ende ne so dann haben wir gesagt OK es gibt so
18:50
ne. QR Stage also ich zieh das jetzt
18:53
mal wohlgemerkt n bisschen von hinten auf, weil ich find, dass
18:55
der Gedankengang ganz interessant ist dabei.
18:57
Wenn ich jetzt aber sage, ich möchte halt nicht meine
19:00
produktive Ebene sofort abändern, weil ich hab jetzt
19:02
wirklich schon n paar Kunden mit meinem neuen Produkt zum
19:04
Beispiel ja sei es ne Website, ne App, whatever.
19:09
Ich möchte halt die nicht vergraulen und mein neues
19:11
Feature bin ich mir nicht sicher.
19:12
Das mach ich jetzt erst mal auf so ne QR Stage und lass das
19:15
vielleicht mit n paar Test Usern oder so ausprobieren.
19:18
Wär auch Vadide, dann hast du halt diese zweite Ebene schon
19:21
mal und bringst halt mehr Sicherheit rein minimierst das
19:24
Risiko wie gesagt wenn ich jetzt aber mein Produkt so wächst,
19:28
dass ich es alleine gar nicht mehr bewältigen kann und ich
19:30
jetzt mehrere Entwickler hab. Diese Death Stage.
19:32
Unfassbar viel Sinn, weil wie willst du es sonst noch managen,
19:35
wer jetzt was auf die QR Stage deployed und wer nicht und dann
19:39
hast du halt diese Spielwiese wie du es genannt hast.
19:41
Weil so kenn ich es auch, dass man da wenig Einschränkungen
19:45
hat. Klar, du hast immer noch gewisse
19:46
Richtlinien, vielleicht auch ja keine Ahnung, sagen wir mal
19:52
irgendwelche Bedingungen an die du geknüpft bist.
19:55
Auch vielleicht Tests die da laufen müssen bevor irgendwas
19:57
reinkommt, was auch immer. Aber halt nie im vollen Umfang,
20:01
sondern du bist da immer frei auszuprobieren, Sachen ändern zu
20:04
können und tust niemandem weh damit.
20:07
Also der maximale Ärger, der entstehen kann, ist, dass ein
20:10
eine Entwicklerkollegin oder ein Kollege dich anruft und sagt,
20:13
Ey, so was ist denn hier los, gerade den neuen Def stand
20:16
gezogen, was geht denn da ab, weißt du, das ist so der
20:19
maximale Zorn, den du dir denn eigentlich aufheisen kannst.
20:23
Und dafür ist das halt super sinnvoll um auch so Teams zu
20:25
organisieren und dann haben wir ja am Ende. 3 Stages wenn ich
20:30
mich jetzt nicht verzählt hab, ne, also du hast diese def
20:32
Stage, von da aus gehst du in eine QR Stage und wenn alles gut
20:35
ist läuft kommt es dann in die Prot Stage und das ist für mich
20:38
so ne sinnvolle einfache Pipeline am Ende gesamtheitlich
20:43
genau. Also das Ding ist.
20:45
Du kannst natürlich auch, das ist jetzt noch mal der Punkt,
20:48
den du meintest, das ist ja. Es ist ja jetzt nicht
20:51
festgeschrieben, dass du sagst, es ist n Konzept ne.
20:53
Also es ist jetzt nicht festgeschrieben, dass du sagst
20:55
es muss jetzt ne def stage, ne QR Stage, ne prod stage sein.
20:57
Es kann halt aber auch beispielsweise du kannst halt
21:00
auch noch ne sowas wie ne user acceptance ebene reinbauen, dass
21:04
du wirklich auch sag ich mal ausgewählte End User zum
21:07
Beispiel nimmst um halt eben die UI damit zu testen oder was auch
21:11
immer, die aber unabhängig von den anderen Stages sozusagen
21:15
läuft, weil unabhängig um das noch mal zu sagen, weil ich kenn
21:19
das beispielsweise so. Also wenn ich jetzt von dem DEF
21:22
QA Prot Stage Prinzip ausgehe, dann hab ich also damit hab ich
21:26
auch schon ne ganze Zeit lang gearbeitet und da war es dann
21:30
beispielsweise so. Also ne du implementierst
21:32
irgendwas, hast jetzt irgendwie n feature ne feature 1 sagen wir
21:35
mal du willst irgendwie auf prot willst du 3 Features packen?
21:40
Und sagst jetzt Feature 1 ist fertig, pack ich schon mal auf
21:43
dev ne und das geht dann automatisch auf Dev und QA,
21:46
musst aber dann noch quasi nach QA muss erstmal noch mal das
21:50
gecheckt werden abgenommen werden ob das so funktioniert
21:52
von irgendjemandem was auch immer und erst dann darf das
21:55
dann auf prot und vielleicht aber auch erst in einem gewissen
21:58
Batch, dass du sagst OK wirklich erst 3 Features diese 3 Features
22:01
sollen zusammen deployed werden auf prot.
22:04
Ne das ist halt nicht gesagt wird OK feature 1 und.
22:09
Ist unabhängig von Feature 2 und 3 ne, sondern feature 1
22:12
funktioniert nur mit Feature 2 und 3 und das muss im Paket hin
22:16
ne so also nur mal so von der von der von der Abfolge, dass
22:20
man dann halt sagen kann, OK ich kann erstmal feature 1 sozusagen
22:24
integrieren, deployen bis QA feature 2 und 3.
22:28
Das wird dann meinetwegen nach und nach abgenommen und
22:30
irgendwann kommt der Punkt wo man sagt OK jetzt kommt dieses
22:33
Paket sozusagen auch an den End User raus, beispielsweise ne.
22:36
So. Da sind wir auch beim Thema
22:38
Releasecyclin wieder ne, weil nicht jedes Produkt möchte jede
22:42
Woche geupdatet werden. Also nicht jeder Kunde für
22:45
gewisse Produkte möchte jede Woche n Update haben zum
22:48
Beispiel oder jedes kleine Feature einzeln ausgerollt
22:50
haben. Genau.
22:51
Ja, ganz klar. Und was auch noch dazu ist, also
22:55
was auch noch wichtig finde ich ist.
22:57
Um sich das noch mal vorzustellen, wenn man jetzt
22:59
sagen kann, OK, aber warum brauche ich denn jetzt ne Death
23:01
stage und ne QR Stage? Prot macht ja schon Sinn, weil
23:05
das muss doch mal der End User nutzen, aber wieso zum Beispiel
23:08
diese beiden? Also erstmal hat hab ich auch
23:11
schon erlebt, dass man gar keine QR Stage hatte oder gar keine
23:14
Death Stage, weil man einfach auf der QR Stage arbeiten konnte
23:17
wie auf der Death Stage und dann hatte ich aber mal n Projekt,
23:20
dass man irgendwann gesagt hat na ja, diese Death Stage QR
23:24
Stage, ich weiß gar nicht mehr wie wir die genannt haben, weder
23:26
noch. Aber die musste noch mal
23:28
aufgesplittet werden, weil dann nämlich irgendwann die
23:32
Anforderung kam, dass man zum Beispiel, dass, dass bestimmte
23:36
Leute, die auf der QR Stage etwas testen, abnehmen wollen,
23:39
was auch immer ne dieses Feature checken wollen, dass sie gesagt
23:44
haben, OK, ich hab jetzt aber n user da und ich möchte gern
23:46
diesen User benutzen und ich möchte mir den nicht jedes Mal
23:49
wieder anlegen. Ich möchte mir auch bestimmte
23:51
Daten aufbauen und die Daten sollen für mich weiterhin da
23:54
sein. Und wir haben aber gesagt, OK,
23:56
aber als Def Team müssen wir immer in der Lage sein, auch mal
24:00
zu sagen, OK, wir clearen komplett die Datenbank und
24:02
machen einfach noch mal von von von reinem Tisch.
24:06
Ne, wollen wir noch mal irgendwie was testen und da war
24:10
es dann so, dass du halt dann diesen diesen Konflikt hast und
24:12
sagst, OK, die einen sagen wir wollen aber nicht, dass die
24:15
Datenbank immer abgeräumt wird, weil wir haben da ne Riesen die
24:18
riesen Datenstruktur. Konstrukt uns aufgebaut in der
24:22
Datenbank und das soll nicht jede Woche gelehrt werden und
24:25
wir haben aber gesagt, wir müssen, wann wir das wollen,
24:28
halt die Datenbank lernen können, dass sie wirklich mal
24:30
platt ist. Und das ist zum Beispiel so n
24:32
Unterschied ne hier auch wieder wichtig, dass man halt eben die
24:34
Datenbasis trennt. Also du hast dann quasi für jede
24:36
Stage auch wirklich eine Datenbank, ne, also die wird
24:39
nicht gemixt mit den End Usern und QA Usern und die Developer
24:43
und so weiter. Und das ist zum Beispiel, finde
24:46
ich, ein sehr, sehr wichtiger Punkt beim Staging auch, dass du
24:49
halt sagen kannst, ey, auf der def Stage kann das def Team
24:52
machen was es möchte und dann gibt es halt vielleicht noch
24:55
diese QR Stage und da kann man dann vielleicht nicht mehr
24:57
machen was man möchte, aber andere können da ihre Sachen
25:01
drauf erledigen. So ne, das ist noch mal finde
25:04
ich war für mich auf jeden Fall finde ich es ein wichtiger Punkt
25:07
an der Stelle, wieso zum Beispiel man eventuell eine Def
25:09
Stage und eine QR Stage hat. Und du hast ja auch so schön
25:14
erklärt, dass es dabei ja gar nicht bleiben muss, sondern dass
25:16
es dann Projekt 123 Projektspezifisch ein
25:21
schwieriges Wort, auch spezialstages oder weitere
25:26
Stages geben kann. Einfach ne, also zum Beispiel
25:29
wenn man sagt, diese Death Stage ist schon sehr.
25:34
Freilebig also man kann viel machen da ne.
25:36
Man kann sich seine Umgebung schaffen wie man möchte, aber
25:39
vielleicht auch nicht in jedem Maße, weil ja wieder das ganze
25:42
dev team da drauf arbeitet, sodass es auch oft so n Begriff
25:47
von Sandbox gibt, dass es so ne Sandbox Stage gibt, wo halt
25:51
wirklich mach was du willst. Jetzt probier aus, überleg dir
25:55
vielleicht auch Features da drin ja vielleicht, also weißt du,
25:58
dass man einfach so wirklich so n so n so ne Spielwiese hat, das
26:01
ist dann wirklich ne Spielwiese. Also.
26:04
Das kenne ich noch, habe ich jetzt selbst nie gehabt in
26:08
Projekten, dass es ein Sandbox Stage gab, aber ist es gängig,
26:14
sage ich mal, begegnet einem so und aber eine Sache, die ich
26:18
noch super spannend finde ist, da können wir auch mal drüber
26:21
reden, weil das haben wir in der letzten Def Ops Folge angerissen
26:25
bei Deployment Strategien und zwar hatten wir da über so AB.
26:32
Deployment oder also Blue Green oder Canary Releases gesprochen
26:38
und das sind Strategien, die meistens eine weitere Stage
26:45
erfordern. Wir können das ganze ja mal an
26:49
ja such dir raus, Blue Green oder Canary Release, woran
26:53
möchten wir das erklären? Wir können das gerne.
26:56
An Blue Green machen. Ich glaube, das ist relativ
26:58
einfach, weil du kannst dir vorstellen, du gehst einen Weg
27:00
und hast dann quasi 2 mögliche 2 Türen wo du durchgehen kannst,
27:03
sozusagen die blaue oder die Grüne.
27:06
Oder wie war das bei Matrix mit den Pillen?
27:08
Na ja, gut, ist ja auch egal, aber ja genau du hast im Prinzip
27:14
die gleiche Stage, sie ist nicht identisch logischerweise, aber
27:18
sie sind gleich aufgebaut und. Das eine ist deine
27:22
Produktivumgebung, die live ist, wo die Nutzer drauf arbeiten.
27:27
Das ist jetzt Blue oder Green, ich weiß immer nicht, ich
27:29
verwechsle immer die Farben, ist das Blue oder Green, ist es
27:32
einmal. So ist einfach so A deswegen A
27:34
und b. Sagen wir jetzt einfach Blue.
27:37
Wenn nicht, ist es Green, liebe Zuhörer, dann tut es mir leid,
27:40
aber das Prinzip ist das gleiche, egal welche Farbe.
27:43
Und auf der. Anderen Farbe aber.
27:46
Hast du quasi deine Änderung drauf, aber es ist trotzdem im
27:50
Prinzip die gleiche Stage, nur halt mit dieser Änderung schon.
27:55
Und wenn du dann siehst, dass die funktioniert, kannst du halt
28:00
eine 1 zu 1 Umschaltung machen, also dann Switch du einfach von
28:03
A auf b von Blue of Green oder umgekehrt, je nachdem ob es dann
28:07
wirklich erfolgreich war oder nicht und kannst halt super
28:09
schnell agieren, weil einfach 2 Parallelwelten existieren vom
28:14
gleichen und. Und das ist halt eine sehr coole
28:17
Deployment Strategie, weil wenn du gehen wir jetzt noch mal die
28:21
Stages durch. Du hast deine
28:22
Qualitätssicherung, du bist ja eigentlich sehr sehr sicher,
28:24
dass das funktioniert, aber du kannst dir nie zu 100% sicher
28:28
sein, weil es nie identisch sein kann wie deine Produktumgebung
28:32
das ist auch ein wichtiger Punkt am Ende, du kannst versuchen so
28:37
nah wie möglich daran zu kommen, selbst wenn du alles hört
28:41
partyanbindung. Die also echt hast und von mir
28:45
aus auch die Kosten bezahlst für irgendwelche Anbindungen, weil
28:49
das ist ja auch alles sehr viel mit viel Geld verbunden
28:51
irgendwann. Selbst wenn du das alles machst.
28:53
Du wirst nicht dieses echte Datenvolumen simulieren können
28:58
oder vielleicht von der Menge her, aber es ist nicht das
29:00
gleiche. Ich hoffe ich kann das jetzt
29:02
erklären, weil die echten Kunden sind auf deiner Prodstage, das
29:06
heißt, das ist die echte Datenbank mit den echten
29:08
Nutzerverhalten auch, also da agieren ja.
29:11
Die Nutzer in echt drauf und das kriegst du halt niemals mit
29:15
Simulation abgebildet. Das heißt du hast immer nen
29:17
Restrisiko, dass irgendwas noch schief gehen kann und da ist
29:21
dieses AB Ding dann am Ende auch ziemlich cool, weil du schaltest
29:24
jetzt einfach auf B auf Blue oder Green um auf die andere
29:27
Farbe und lässt es laufen und sobald irgendwas schief läuft.
29:32
Hast du immer noch deine Unangefasste alte Umgebung und
29:35
schaltest es einfach Instant wieder zurück?
29:37
Die halt. Funktioniert hat ne genau.
29:39
Ja, das heißt. Im Best Case werden nur n paar
29:43
User merken, dass was schief läuft.
29:45
Und dann schaltest du es zurück. Ne, die meisten merken davon gar
29:48
nichts. Das funktioniert aber nur mit
29:50
einem sehr sehr guten Monitoring und das ist ne weitergehende
29:53
Folge in der Def Ops Reihe, da kommen wir auch noch zurück, das
29:56
ist ja auch n sehr spannendes. Thema also, um noch mal ganz.
29:58
Ruhig einzugrätschen bei dir ne, weil du ja meintest es ist nicht
30:02
die gleiche Umgebung, also das Verhalten der Umgebung wie Leute
30:06
damit umgehen, darauf arbeiten ne zu welchen Zeiten.
30:10
Vielleicht kann man zwar versuchen wie du meintest zu
30:12
simulieren, es ist aber du kommst halt.
30:14
Im Normalfall nie genau ran, weil du ja auch gar nicht genau
30:17
her willst. Eigentlich kannst du alles was
30:18
passiert oder so kannst. Du natürlich auch simulieren sag
30:21
ich mal ne, aber zum. Beispiel die Infrastruktur.
30:24
Ne, also wirklich so wie die Stage aufgebaut ist ne, also was
30:27
für ne Datenbank, was für infrastrukturkomponenten du am
30:30
Ende sozusagen zusammenbastelst das ist ja schon das gleiche ne
30:35
oder kann das gleiche sein beziehungsweise kann man dann
30:39
auch wieder gucken. OK brauche ich denn für zum
30:41
Beispiel ne dev stage genauso ne hohe?
30:44
Kapazität also sagen wir mal ne hohe Rechenleistung, ne oder was
30:48
weiß ich für n krassen Server genauso wie für die Protzstage
30:51
wahrscheinlich nicht, also wird da schon mal n kleiner
30:53
Unterschied eventuell sein, wenn man Kosten optimieren möchte und
30:56
das sind halt die Sachen wo sie sich dann meistens eigentlich
30:59
schon unterscheiden, oder du greifst halt tief in die Tasche
31:01
unterm Steppen. Genau, es ist halt mit enormen
31:05
Kostenobern verbunden. Also du hast natürlich recht,
31:07
also hier noch mal ganz klar der Hinweis da drauf, du schaffst es
31:11
diese Umgebung so. Gleich zu gestalten, dass im
31:15
Prinzip nachher nur eine URL sich unterscheidet, also wo
31:18
zeigt sie hin oder wo? Also was zeigt auf diese
31:22
Umgebung, sage ich mal und halt, dass dieses Nutzerverhalten
31:26
niemals das echte ist. Diesen Unterschied hast du am
31:29
Ende noch. Ansonsten Infrastruktur kannst
31:32
du, wenn du das Geld in die Hand nimmst, komplett gleich machen,
31:34
auf jeden Fall. Was man natürlich noch dazu
31:38
sagen. Also.
31:39
Was man noch dazu sagen kann ist, dass du ja zum Beispiel,
31:41
wenn du wirklich sagst, du hast eine QR Stage und Du hast
31:44
externe Services, mit denen du arbeitest, also zum Beispiel
31:46
über apis oder so, kannst ja auch apis ansprechen aus deiner
31:50
Anwendung heraus, dass du andere Systeme anfragst.
31:52
Wie wird zum Beispiel auch schon mal bei einer Essens bestell App
31:56
oder so, da hast du ja wahrscheinlich dann auch apis,
31:59
um sozusagen an den entsprechenden Restaurants zu
32:01
anzufragen, welche Angebote habe ich denn da überhaupt und?
32:07
Damit man dann zum Beispiel sowas eben halt auch in der QR
32:11
Stage zum Beispiel vielleicht nicht auf der Prot Stage
32:16
sozusagen, also wirklich auf den echten API Schnittstellen von
32:18
den Restaurants arbeitet und die vielleicht bei einer zu hohen
32:22
Last oder was auch immer lahmlegt, gibt es meistens halt
32:25
eben auch. Qr Stages für solche API
32:29
Schnittstellen also, die dann externe Services anbieten.
32:31
Also angenommen sowas gibt es, sollte man diese auch nutzen und
32:34
dann zum Beispiel für irgendeinen Hinweis für
32:35
irgendeine Test Stage oder Death Stage oder so jetzt nicht die QR
32:39
Stage die die die Protz Stage von anderen apis anbinden, das
32:42
wäre natürlich blöd und das ist auf jeden Fall auch eine Sache
32:45
die natürlich an der Stelle wichtig ist, dass man auch sagt
32:48
Okay auch hier würde sich dann logischerweise die Protz Stage
32:52
von den anderen Stages unterscheiden.
32:56
Da kann man auch ein. Ganz cooles Beispiel bringen
32:58
also jetzt kein Ex. Also genaues, aber nur mal ein
33:01
Gedankenspiel. Ich bin ein Drittanbieter an zum
33:04
Beispiel eine API und habe da Credits, ist jetzt nicht
33:09
unüblich, dass quasi so eine Art Abo Modell mit Credits dahinter
33:13
ist und ich kann am Tag so und so viel Credits verbrauchen und
33:15
jeder Request verbraucht dann Credits.
33:19
So und. Die muss ich mir aber
33:20
eigentlich, weil es kalkuliert ist, für meine Produktivumgebung
33:23
aufsparen. Und jetzt bind ich das aber in
33:27
meiner QR Stage zum Beispiel an, weil ich mir sage, ja ne, will
33:30
ich jetzt aber wirklich mit den echten apis testen und haut dann
33:35
Fehler rein und statt ein Request gehen 1000 raus und ich
33:37
hab alle meine Credits verbraucht im.
33:39
Worst case. Sogar wird das automatisch
33:42
erneuert und ich hab ne riesen Rechnung erzeugt.
33:44
Also das ist nur mal so n kleines Warnbeispiel und sowas
33:47
passiert, das ist nicht aus den Haaren herbeigezogen oder wie
33:51
man sagt keine Ahnung, ich glaub das war sogar richtig.
33:54
Das war wichtig. Oder sowas passiert.
33:57
Und das passiert dann aber auch nur einmal, weil das Halt
33:59
wirklich mit Kosten verbunden ist.
34:00
Und dann lernt man es zu schätzen zu sagen, ey, wir haben
34:04
jetzt ne Dummy Anbindung oder so.
34:07
Ja find ich auf jeden Fall sehr, sehr wichtig, dass du es noch
34:09
mal sagst. Geht ja auch genauso wie mit
34:11
irgendwelchen Raid Limits oder sowas.
34:13
Ne wenn du zum Beispiel am Tag n Raid Limit hast oder was auch
34:15
immer, was ich noch zu den Spezialstages wie du sie so
34:19
schön genannt hast sagen würde ist, dass.
34:22
Man natürlich, wenn du so verschiedene Stages hast, wie
34:24
zum Beispiel Dev Stage prod. Stage, ne QR Stage oder Sandbox
34:29
Stage, was du meintest oder vielleicht gibt es auch ne
34:31
Hotfix stage, was auch immer das sind ja vielleicht so
34:33
verschiedene Stages, ne die du ja irgendwie aufbauen kannst und
34:37
wie du sie dann sozusagen hintereinander schaltest oder in
34:40
welcher Reihenfolge von welche, welche Features.
34:43
Wandern ne ist ja eigentlich, also kann man sich ja aussuchen.
34:46
Du kannst halt beispielsweise in deiner Automatisierung sagen,
34:50
wenn ich ein neues Feature habe, wird das erst auf Development
34:54
deployed, dann geht es weiter auf QA, dann geht es weiter auf
34:57
prot oder du sagst ne das geht automatisch und du sagst von QA
35:00
auf Prot muss ich noch mal manuell triggern, weil da gibt
35:04
es noch mal einen extra Gate Keeper sozusagen der da vorsteht
35:08
und. Aber es muss ja auch nicht sein,
35:10
dass du sagst, es geht auf jeden Fall von Def zu QA zu.
35:13
Prot ne Beispiel diese Sandbox Stage.
35:16
Es kann ja sein, dass du sozusagen deine aktuelle, dein
35:18
aktuelles Feature geht zwar auf def QA und dann irgendwann auf
35:21
prot, aber gleichzeitig geht dieses eine Feature auch zum
35:25
Beispiel auf Sandbox. Und von Sandbox geht es gar
35:27
nicht weiter so. Also weißt du, da kannst du
35:29
vielleicht auch noch sogar einen ganz anderen Branch mit ganz
35:33
anderen experimentellen Features hin, die Ployn, die aber
35:37
vielleicht niemals auf Prot kommen.
35:38
Weißt du, das sind ja zum Beispiel auch noch so Sachen,
35:40
über die man halt eben auch nachdenken kann, also absolut
35:44
nur um zu sagen so, es muss nicht immer seriell geschaltet
35:47
werden, weil ich finde zum Beispiel ein sehr, sehr
35:49
wichtiger Punkt, der finde ich in diesem ganzen Konstrukt
35:53
schnell mal aufkommt ist was ist denn wenn du ich nehme noch mal
35:57
das Beispiel von vorher. Du hast zum Beispiel 2 von 3
36:00
Features bis auf die QR Stage gepackt und wartest jetzt auf
36:04
das Dritte, damit du sozusagen alle 3 gleichzeitig auf Prot
36:09
bringen kannst. An den End User und jetzt merkst
36:12
du aber während der Entwicklung von dem dritten Feature was noch
36:17
nicht da ist zum Deployen, das ist ein ganz ganz wichtige
36:20
Sicherheitslücke gibt ein Bug der gefixt werden muss.
36:23
Was machst du dann beispielsweise?
36:24
Dann kannst du ja rein theoretisch natürlich sagen, OK,
36:27
ich schalte jetzt, ich, ich entwickle jetzt also ich fix den
36:32
Bug und schalte also ne und schalte den Bug plus diese 2
36:35
Features 2 von 3 halt live, was aber eigentlich nicht sein
36:38
sollte ne und da kannst du beispielsweise natürlich sagen,
36:41
OK, ich nehme vielleicht den Stand von prot ne hab davon
36:46
natürlich noch irgendwo in meiner Versionierung.
36:49
Meines Codes irgendwo auch noch n stand, den kann ich Branchen
36:53
und dann über ne Hotfix stage direkt auf die Protz Stage
36:56
gehen, beispielsweise ne weil ich finde die Möglichkeit ja
36:59
genau, also nur mal ein Beispiel, da gibt es noch
37:01
verschiedene Sachen. Du kannst auch mit Feature Flex
37:03
arbeiten oder was auch immer, aber das ist ja ne Möglichkeit
37:07
die auch da ist und vor allem ist es auch n sehr häufiges
37:10
Problem wenn man zum Beispiel so mit Stages arbeitet.
37:13
Also das ist mir häufig mal vorgekommen, dass es dann heißt
37:15
ja, aber was machen wir denn dann ne?
37:18
Und deswegen also wichtiger. Dazu habe ich noch 2 Punkte.
37:21
Der erste Punkt Memo an uns Feature Flex ist auch ein sehr
37:24
spannendes Thema, das können wir auch mal behandeln und der
37:28
zweite Punkt ja, also wie deine ganze Struktur am Ende aussieht
37:32
ist wirklich bisschen Floating, also das muss dem Projekt
37:35
angepasst werden. Ich glaube es gibt nur eine
37:38
Grundregel, am Ende sollte mal die Prot Stage kommen, also das
37:42
ist halt schon wichtig, dass man da nicht halt.
37:45
Also ich finde so immer direkt auf prot.
37:48
Schwierig ja ja OK, aber lass uns das ganze mal so n bisschen
37:53
abrunden, zusammenfassen und das noch mal so n bisschen in den
37:57
def Ops Kontext eingliedern, warum dieses Staging jetzt
38:00
wirklich so wichtig ist? Weil wir haben ja am Anfang der
38:03
Def Ops Reihe auch erklärt, wie diese Bewegung entstanden ist.
38:06
Die Methodologie dahinter. Welche Methoden haben wir
38:11
angefangen zu erklären, was da alles drin steckt?
38:13
Und wie spielt das Ganze jetzt zusammen?
38:15
Dabei darf man halt 1 nicht vergessen, Def Ops guckt sich
38:18
immer den gesamten Software Lifecycle an, das ist halt auch
38:21
einfach Bestandteil davon, das heißt Wir haben die Entwicklung,
38:25
wir haben das Testen, das Deployen und den Betrieb am
38:28
Ende, das ist halt auch wichtig, ne die Prot Stage am Ende und
38:30
wenn man sich das alles zusammen anguckt ist staging ja im
38:34
Prinzip. Das Bindeglied wie komme ich von
38:37
ganz am Anfang, wie ich am Anfang diese Videospiel Analogie
38:41
gebracht hatte? Wie komme ich vom ersten Level
38:44
zum finalen Level und Spiele das Ganze quasi durch erfolgreich
38:48
und da greift halt Staging für mich rein, das heißt der End.
38:53
User ist der Endgegner. Genau den gilt es zu bezwingen,
38:57
Nein, zufrieden zu stellen. Es ist noch viel, viel
39:00
schwieriger, ihn zufrieden zu stellen als zu bezwingen.
39:04
Genau, also man redet halt immer über CI und CD.
39:07
Das sind so diese Buzzwords, aber am Ende ist Staging was
39:10
alles verbindet. Ja es ist ja.
39:12
Deswegen hatte ich anfangs gesagt, das ist.
39:14
Für mich halt ne Methodik auch irgendwo.
39:15
Ja also ich find immer. So Staging kann man noch so n
39:18
bisschen als Buffer nehmen und sagen so OK, du hast jetzt noch
39:22
mal dein, also du hast deine Entwicklung, du hast deine ganze
39:25
Automatisierung und du hast sozusagen dein Deployment am
39:28
Ende und dazwischen gibt es noch so n Buffering.
39:31
Dass du sagst, so OK ne, also du du schießt, du schießt deinen.
39:34
Dein neues Feature schießt du auf die Pipeline, das rasant
39:37
schnell wird durchgetestet, Zack der Zack und dann hast du noch
39:39
mal so n kleinen so n kleinen Buffer ne wo du noch mal sagen
39:42
kannst OK hier check ich noch mal kurz das Feature alles cool
39:45
ne und weiter Feuer so raus in die freie.
39:47
Welt. Das ist das, was in meinem Kopf
39:49
immer so für n Bild entsteht. Ist auch schön, ist auch.
39:52
Schön gefällt mir gut, ja, aber das Ganze hat natürlich auch
39:57
Herausforderungen. Die wir jetzt nicht unter den
40:00
Tisch kehren sollten, unter den Teppich oder Tisch.
40:03
Oh mein Gott ey, wir sollten das mit diesen Redewendungen sein
40:05
lassen, unter die Katze, und zwar hatten und ne genau wir
40:10
hatten ja schon gesagt, dass das mit Kosten verbunden ist.
40:14
Das heißt Projektabhängig sollte man auch nur so viel Stages
40:16
verwenden wie nötig und was sinnvoll ist und nicht sagen ey
40:21
hier, das Staging ist total geil, ich hab jetzt einfach 10
40:23
stages, bin aber alleine im Team und mach hier alles ganz
40:26
alleine. Ist da nicht so sinnvoll
40:30
wahrscheinlich, also da halt wirklich ans Projekt anpassen,
40:33
da halt der Betrieb von Staging sehr teuer werden kann.
40:36
Bestes Beispiel Blue Green Deployment Strategie, wenn ich
40:41
das machen will, dann muss ich 2 gleiche Umgebung schaffen mit
40:45
allem drum und dran, du hast ja sofort gesagt wenn man gutes
40:48
Monitoring hat und sowas kostet alles Geld und das muss halt
40:51
wirklich zweimal die ganze Welt existieren, sozusagen damit man
40:55
das machen kann. Und das ist jetzt nur so die
40:58
Spitze des Eisbergs. Selbst die ganzen.
41:00
Stages da drunter sind ja alle mit Kosten verbunden.
41:02
Ich finde ist jetzt zwar zwar nicht ganz wie sagt man
41:05
wissenschaftlich korrekt, aber ganz salopp gesagt, wenn du 2
41:08
stages hast, brauchst du sozusagen auch 2 Server.
41:12
Also wie gesagt, ganz salopp gesagt, aber also nur, dass man
41:14
sich jetzt mal ganz grob vorstellen kann.
41:16
Also wenn du ne du du brauchst ja 2 Einheiten ne und du
41:21
brauchst alles 2 mal, also bei 2 stages.
41:26
Ja, ja. Genau.
41:27
Und das. Muss ja auch alles gewartet
41:28
werden. Und das Gute an der Stelle oder
41:32
was natürlich auf jeden Fall ne Best practice ist, gerade wenn
41:34
man jetzt zum Beispiel also bei dieser Herausforderung angeht
41:36
und sagt, du musst jetzt alles noch mal aufbauen, ne, also so
41:40
angenommen, du sagst jetzt du hast ne prot Stage, du hast ne
41:43
QR Stage und du sagst ja ich will jetzt aber noch ne Death
41:45
Stage haben, so dann stellt man sich ja im Best Case nicht hin
41:48
und sagt Boah jetzt muss ich. Okay pass auf, ich lege mir noch
41:52
einen Server an, jetzt kommt noch eine Datenbank dazu und
41:54
dann klickst du dich da irgendwie durch durch deine
41:55
Infrastruktur und machst dies und machst das, sondern auch
41:59
hier natürlich wieder als Best Practice Infrastructure ist Code
42:06
auch, nur wird auch noch mal eine eigene Folge in unserer Def
42:09
Ops Reihe, aber so viel sollte schon mal gesagt sein, du kannst
42:12
deine Infrastruktur solltest deine Infrastruktur dann am
42:15
besten halt auch eben mit einfach nur einem Code Template
42:18
aufbauen können, das gibt es meistens in den Im Normalfall
42:22
gibt es so was, ist so was möglich und das sollte dann auch
42:24
genutzt werden, weil du dann halt eben ich sag mal auch
42:27
wieder ein bisschen salopp gesagt, aber auf Knopfdruck so
42:30
eine neue Instanz, eine neue Stage aufbauen kannst, ja.
42:35
Sehr wichtig. Dann hatten wir ja darüber
42:38
gesprochen, dass das Isolieren der Daten halt wichtig ist.
42:42
Aus mehrerer Hinsicht, auch aus Kostenhinsicht wieder schon,
42:46
dass du sagst, okay, ich habe nicht die.
42:48
Echten Services, sondern ich habe eine isolierte Umgebung,
42:51
die ich mir schaffen kann. Gerade auf Dev und QR Stage sehr
42:56
wichtiger Punkt, damit auch Produktivdaten niemals.
43:00
Mit Testdaten vermischt werden beispielsweise, das wär ja
43:03
wirklich so n Supergau wenn du sagst OK, auf meiner
43:05
Produktivumgebung kommt jetzt Test user 123 mit rein der
43:09
überall angezeigt wird oder sowas weißt du theoretisch kann
43:12
jemand sich so anlegen OK mag sein, aber mal angenommen du
43:15
schwemmst jetzt deine echte Umgebung mit tausenden Test
43:17
Usern oder so nicht cool. Dieser Service hat schon 5
43:22
Milliarden Millionen quatrilliarden User.
43:27
Das ist Server lahmgelegt. Genau.
43:30
Und der Kostenfaktor halt mit externen Services, die einfach
43:33
gegeben sind, dass man die minimieren kann, indem man sowas
43:36
halt einfach mit Dummy Services ersetzt.
43:41
Ja Ah, ein wichtiger Punkt sind natürlich auch sensible Daten,
43:44
da haben wir auch noch nicht so drüber gesprochen, auch wichtig
43:48
sensible Daten halt auf vorgelagerten Stages nicht
43:52
unbedingt mit verwenden, ja definitiv.
43:57
Und wie gesagt, so die Daumenregel insgesamt sollte
43:59
natürlich immer sein, dass die Produktionsumgebung natürlich
44:01
immer möglichst gleich der echten Umgebung sein kann, weil
44:05
wenn du jetzt zum Beispiel also angenommen, du hast jetzt
44:07
irgendwie nen nen irgendeinen Login Mechanismus oder so und
44:11
der wird so verfälscht, dass er zwar auf irgendeiner Stage
44:15
funktioniert, aber unter den echten Bedingungen eigentlich
44:18
nicht mehr funktioniert, dann ist es natürlich blöd.
44:20
Deswegen ist es natürlich klar, du kriegst es niemals
44:22
hundertprozentig 1 zu 1 hin. Aber es ist schon wichtig, dass
44:25
man oder ne, das ist, das sag ich mal, das große Ziel.
44:30
Am Ende sollte immer sein, dass die Produktivumgebung möglichst
44:34
simuliert wird. Na also je ähnlicher, desto
44:37
besser eigentlich. Ja genau, ja, da würde ich
44:44
sagen, haben wir das eigentlich sehr ausführlich besprochen.
44:48
Ich würde noch mal kurz zusammenfassen, ergänze bitte,
44:51
falls ich was vergesse und zwar hätte ich gerne noch so eine
44:55
kleine Take Home Message. Liebe, zuhören, liebe Zuhörer,
44:57
also die Key Points noch mal zusammengefasst.
45:01
Ich würde sagen warum Staging das ganze Mal zusammengefasst.
45:07
Erstens du kannst realitätsnahe Tests erzeugen mit zusätzlichen
45:12
Stages, das heißt du kannst so nah an deine produktiv Umgebung
45:15
kommen ohne. Sie zu beeinflussen und kannst
45:18
so frühzeitig einfach neue Features testen, Fehler
45:22
erkennen, vor allem ohne Deine produktiv Umgebung zu
45:25
beeinflussen. Und ja, du minimierst extrem das
45:30
Risiko dabei, das ist für mich so ein so ein richtig wichtiger
45:34
Punkt dabei, das spielt ja auch alles in die Qualitätssicherung
45:37
mit rein, dann würde ich sagen. Was man aber auch auf dem
45:45
Gegenzug sagen muss, ist diese Vorteile, die wirklich enorm
45:48
sind. Deswegen wird es ja auch
45:50
gemacht, muss man sich allerdings einkaufen mit
45:53
erhöhten Wartungsaufwand und erhöhten Kosten bis hinzu was
45:58
wir gesagt hatten, bei manchen Strategien hast du Sachen
46:00
einfach doppelt um das so leben zu können oder verwenden zu
46:04
können, definitiv was man sich. Natürlich noch Fragen kann als
46:09
Take Home Message. Angenommen, man sagt jetzt, na
46:12
ja, aber. Wieso sollte man jetzt noch mal
46:15
irgendwie was testen auf irgendeiner QR Stage oder sonst
46:18
was, obwohl man ja eigentlich schon vorgelagert diese ganzen
46:21
automatisierten Tests hat und wir ja eigentlich auf manuelle
46:24
Tests oder so verzichten wollen? Möglichst, das ist halt im
46:29
Endeffekt manchmal erfordert ein bestimmter Prozess etwas, dass
46:33
man zum Beispiel wirklich noch mal eine externe Instanz hat,
46:35
die bestimmte Features abnimmt und sagt, OK, passt fertig
46:39
gatekeeper mäßig, weiter geht es, ne.
46:42
Kann vorkommen. Genauso ist es manchmal so, dass
46:45
du wie gesagt bei irgendwelchen Tests, ob es jetzt Unit Tests
46:49
sind oder System Tests hast du ja manchmal einfach den Punkt,
46:54
dass du etwas mogst, etwas Fakes, externe Services,
46:57
irgendwelche Schnittstellen, was auch immer und genau diese
47:01
Sachen werden halt an dieser Stelle eben, sage ich jetzt mal.
47:07
Also diese diese Schnittstellen können nicht 1 zu 1 getestet
47:10
werden und an dieser Stelle schon und es ist auch eher diese
47:13
Stages sind doch eher so zu sehen finde ich, dass sie auf
47:17
jeden Fall immer parallel mitlaufen und das zum Beispiel
47:20
angenommen du hast in deinem Monitoring merkst du ey du hast
47:23
jetzt zum Beispiel auf der Produktivstage, eventuell merkst
47:26
du, irgendwie hast du etwas was schief geht, dann kannst du das
47:29
ja auf deiner QR Stage oder auf deiner Dev Stage genauso einmal
47:32
nachstellen um zu überprüfen ist dieser Fehler wirklich da?
47:36
Also es geht nicht immer nur darum, dass man sagt, um das
47:38
jetzt noch mal ganz kurz zusammenzufassen, es geht immer
47:41
nur präventiv darum, was vor sozusagen zu machen, sondern
47:46
vielleicht auch einfach mal bestimmte Sachen auszuprobieren,
47:49
parallel auch zur pro Stage sozusagen, oder irgendwelche
47:53
Sachen noch mal nachzuvollziehen, ob das
47:57
wirklich so ist oder nicht. Solche Sachen kommen halt damit
48:01
auch rein und auch sowas wie zum Beispiel Datenbank Migration.
48:06
Hatte ich vorhin schon mal angesprochen.
48:07
Wichtiger Punkt, das ist auch nicht immer alles ganz so
48:10
trivial und da macht es auch schon mal Sinn diese Datenbank
48:14
Migration einmal im Vorfeld zu performen, zum Beispiel auf
48:17
einer Dev Stage um zu gucken, ob wirklich alles richtig
48:20
funktioniert und es dann auf Prot loszulassen.
48:25
Und wenn dann noch was passiert, dann ist es halt so.
48:28
Ganz dick machen. Ja, okay ich würde sagen, das
48:32
Thema haben wir ausführlich besprochen.
48:33
Es hat mir eine Menge Spaß gemacht.
48:34
Danke dafür. Fabi Def Ops ist halt auch
48:37
einfach ein cooler Bereich und ja, deswegen bleibt uns nicht
48:42
mehr viel zu sagen, außer Liebe zur Liebe zur falls dir das
48:45
Thema gefallen hat oder du Anmerkungen dazu hast.
48:48
Unsere Mail findest du in den Show Notes.
48:50
Schreibt uns gerne, wir freuen uns über jedes Feedback, auch
48:52
wie wir allgemein den Podcast verbessern können
48:55
Themenvorschläge alles sehr willkommen meld dich gerne.
49:01
Ja, falls dir der Podcast gefällt und du ihn auf deinem
49:04
Provider der Wahl noch nicht bewertet hast, dann lasst auch
49:07
gerne ein paar Sterne da oder ein Like da empfiehl ihn weiter.
49:10
Das hilft uns ungemein, unser ganzes Vorhaben hier noch zu
49:14
verbessern und ansonsten würde ich sagen, hören wir uns alle
49:17
beim nächsten Mal wieder, habt eine gute Zeit und bis dahin
49:21
deine Coding Buddies gemeinsam. Besser.