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