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.