Also ich setz mich jetzt n Schneidersitz auf den Boden, wieso n kleiner Junge der die Geschichte hören möchte und bitte erzähl Coding Buddies dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen. Herzlich Willkommen zur neuen Folge des Coding Bodys Podcasts. Schön, dass du wieder eingeschaltet hast, deine Gastgeber und wie soll es auch anders sein, wie immer meine Wenigkeit, der Tino und auch der fantastische Fabi, der mich schon anlächelt durch die Kamera
Fabi Grüße dich was geht ab wie Hallo Tino, wie geht es dich nicht sehr verhalten noch sehr verhalten du musst jetzt zu den Podcast Moot kommen ich bereite es vorab sehr gut das ist der Spirit den wir hier brauchen. So n richtigen live Kommentator von irgend nem krassen Spiel. So diese Stimmung brauchst du weißt du du musst die Leute anheizen, ganz cosy alles entspannt cosy ich bin deutsch. Cosy zu wenig Kaffee getrunken heute? Ich bin noch.
Nicht ich hab tatsächlich auch gerade keinen am Start, also wird es wirklich n bisschen cosy heute. Ich weiß nicht. Ich glaube, ich habe heute einen Kaffee getrunken, was echt wenig ist für mich okay normalerweise wäre ich so bei. Zeit note Wir nehmen ihn nicht morgens um 5 auf, hier gerade den Podcast. Das ist schon ein fortgeschrittener Tag, das ist wirklich wenig für dich, fabi, muss ich mir Sorgen machen? Nee, Oh, das ist der Kaffee einfach alle.
Nee, eigentlich alles gut, zu wenig Zeit gehabt, um Kaffee zu trinken heute, ah, na gut, dann danach nach. Nachdem wir diese Folge aufgenommen haben, kannst du gleich 4 auf einen Kaffee ziehen 4 Espresso OK, dann würde ich sagen starten wir auch mal direkt damit du schnell zu deinem Kaffee kommst. Und zwar habe ich wieder n cooles Thema mitgebracht und zwar haben wir ja gesagt wir wollen heute also mit dieser Folge die Def Ops Reihe
fortführen. Und wir haben ja das letzte Mal über Continuous Integration gesprochen und auch schon so angeteasert, was das nächste Thema ist. Und da möchte ich auch heute dann mit dir drüber sprechen und zwar Continuous Deployment, schrägstrich delivery wohlgemerkt. Beide Sachen, also Deployment und Delivery, dass wir auch einfach mal, weil das war auch bei mir so n Punkt anfangs, dass man das einfach mal richtig separiert und sich unter beiden was vorstellen kann, weil.
Mir ist es auch schon begegnet, dass es oftmals als Synonym verwendet wird, aber eigentlich vom Prinzip her meiner Meinung nach stehen da 2 verschiedene Sachen dahinter, die zwar in die gleiche Richtung gehen, aber schon voneinander separiert werden können und das würde ich gerne mit dir heute machen und da mal n schönen Überblick geben über das gesamte CD Thema, dann finde ich gut, ja wollen wir das so machen?
Machen wir so. OK, dann gebe ich noch mal ne kurze Einleitung, bevor ich dann an dich abgebe und mir erstmal n Kaffee hole. Wir haben ja wie gesagt das letzte Mal über Continuous Integration gesprochen und wenn wir uns in unserer Def Ops Reihe reden wir ja immer von der Pipeline die man aufbaut. Wenn man jetzt noch mal das Revue passieren lässt, waren wir ja an dem Punkt, dass wir gesagt haben, OK, wir wollen kontinuierlich in unsere
Codebasis integrieren. Das heißt, wir wollen automatisiert Änderung einchecken. Darauf die Tests laufen lassen. Sowohl Unit Test als was auch
immer alles abgetestet wird. Wir haben auch so n bisschen über zum Beispiel statische Codeanalysen gesprochen, also alles was da so in den Bereich testen fällt und wenn das Grün läuft, dann soll es automatisch in die Codebasis integriert werden, sodass man halt schnell neue Stände, die zuverlässig die richtig sind integrieren kann und nicht quasi in großen Batches arbeitet um das noch mal ganz kurz zusammenzufassen.
Dann sind wir ja an dem Punkt. Wir haben das jetzt integriert und da würde ja eine normale Pipeline jetzt nicht enden, sondern dann gehen wir ja schon so in diesen CD teil, um den es heute gehen soll. Über was ist für dich an der Stelle jetzt essentiell und was also wo beginnt für dich dann
der CD teil sozusagen? Der CD teil ist dann für mich, wenn man weiß okay der Code oder die Code Basis der Stand des Codes den man jetzt hat oder der Anwendung ist getestet und funktioniert und dann muss der Code gebaut werden, dass du so eine Art Artefakt hast, dass du sozusagen ausliefern kannst und dann wird es im Endeffekt auch ausgeliefert und da ist aber
dann noch so ein kleiner. Unterschied zwischen Delivery und Deployment und da können wir gleich noch mal n bisschen, dann auch näher drauf eingehen, dass man das Ganze noch mal voneinander separiert und ich, du hast es wahrscheinlich schon geahnt, dass jetzt noch ne kleine Analogie Analogie kommen wird. Wir also ganz ehrlich, ich hätte mich auch enttäuscht, wenn du jetzt nicht ne Analogie mitgebracht hättest zu dem Thema.
Also ich setz mich jetzt n Schneider Sitz auf den Boden, wieso n kleiner Junge der die Geschichte hören möchte und bitte erzähl. Ich seh alles ne, also ja also das Ding ist ich. Ich find das wirklich auch interessant oder oder gut wenn man noch mal so ne Analogie bringt, weil ich auch genauso wie du damals eigentlich nicht wirklich gedanklich separiert hab, dass es ja was anderes ist. Also Deployment and Delivery und dachte OK, das ist eigentlich
ist doch das gleiche so, ja und? Ist das Gleiche, ist richtig, Entschuldigung. Und im Endeffekt kann man sich das so vorstellen. Wenn du jetzt zum Beispiel, ich weiß nicht, irgendwie fangen viele Analogien mit Restaurants an. Ja, wenn du so dein Ding. Wenn du genau, wenn du ins Restaurant gehst und dir ein Essen bestellst und dann hast du zum Beispiel den Prozess, wie zum Beispiel der Koch, bereitet das Essen vor, also implementiert zum Beispiel die Software das neue Feature, wie
auch immer und. Dann wird ja vielleicht noch mal abgeschmeckt und geguckt, ob es vielleicht gut ist. So, und dann wird ja im Endeffekt das Ganze als Artefakt gebaut, das heißt auf dem Teller zusammen angerichtet und so weiter und dann wird dieser Teller vielleicht auf eine Zwischenablage gestellt und diese Zwischenablage ist dafür da, dass du dann zum Beispiel irgendwann als Gast vielleicht
sagst. Bitte bringen Sie mir jetzt das Essen, das heißt, du musst manuell sozusagen noch mal den Kellner oder die Kellnerin hinweisen darauf, dass dir das Essen auch wirklich gebracht wird, dass du es wirklich bekommst. Oder du musst es dir vielleicht selber abholen von dort ne. Ja. Das ist sozusagen dann wirklich an der Stelle Delivery und Deployment, um das jetzt kurz noch mal weiterzuführen, wäre an der Stelle, dass du nicht diese Ablage hast, sondern dass sobald
das Essen fertig ist. Es sofort, ohne, irgendwie dass du noch mal explizit danach bitten musstest, direkt an deinen Platz gebracht wird so einmal, um das ganz kurz auf dieser Ebene zu haben. Das bedeutet also eigentlich, dass Continuous Delivery ist, dass deine Software gebaut wird und das Artefakt vorbereitet wird, so dass es rein theoretisch jederzeit veröffentlicht werden kann, das heißt zum Beispiel ein neues Feature, was in deine Software reinkommt. Dein Featureset erweitert sich.
Und du hast aber eine Anwendung, die sozusagen gerade läuft. Verwendet wird, wie auch immer und das neue Feature Set wird aber nicht direkt eingespielt, das ist sozusagen live verfügbar ist, sondern so ich sag mal Gestaged zurückgehalten an einem bestimmten Punkt und wenn du jetzt aber als Entwicklerteam zum Beispiel sagst okay, wir wollen jetzt aber zu diesem speziellen Zeitpunkt manuell sagen. Das Artefakt, was gebaut wurde, wird jetzt auch sozusagen live
geschaltet. Dann sind wir an dem Punkt, dass wir natürlich, also das ist sozusagen dieses Delivery, das heißt, du gehst nur bis zu dieser Stage, aber es wird noch nicht automatisch ohne manuellen Eingriff weiter ausgerollt und Deployment geht genau diesen Schritt weiter, dass man sagt, okay, wir haben dieses gebaute Artefakt und wir müssen jetzt aber keinen manuellen Schritt mehr machen, sondern es wird. Wenn man jetzt diese ganze Pipeline immer durchgeht, du
committest etwas. Dein neues Feature Set, es wird getestet, es wird integriert, es wird gebaut und dieser neue Stand wird sofort ausgerollt und das ist im Endeffekt so grob mal zusammengefasst. Delivery und auch im Vergleich zu Deployment, also CI, also CD, Continuous Delivery, Continuous Deployment. Ja, also das heißt bei deiner Analogie. Es wird halt soweit vorbereitet. Das heißt, das Essen wird an, also es wird nicht nur gekocht, es wird am auf dem Teller angerichtet, sodass es
verzehrfertig ist. Sagen wir mal ne genau, ich dich jetzt richtig verstanden hab und ob man sich das jetzt selbst holt oder nen Kellner aktiv entscheidet dir dieses Essen zu bringen ist ja dann im Prinzip die Delivery.
Also dieses Typische, es wird hier klingelt hier essen, Tisch 13 fertig ne, das ist sozusagen die Vorbereitung, es ist alles bereit ausgeliefert zu werden, da steht jetzt dieser Teller mit diesem köstlichen Essen und das finde ich halt ganz cool als Analogie, dass du sagst, jetzt muss aber jemand noch entscheiden, ob das jetzt wirklich zu dir an den Tisch kommt, genau wie man die Analogie auch aufbauen möchtest, entscheidest du selbst, dass es du, dass du es dir jetzt holen
möchtest oder der Kellner es dir bringt. Deployment wäre ja im Prinzip, wenn das jetzt vom Koch angerichtet wird und per keine Ahnung liefer automatische Lieferung an deinen Tisch gefahren wird, ne also beim Fließband oder so keine Ahnung hier so Running Sushi weißt du. Das ist. Doch ein gutes Beispiel, weil dann fährst du einfach an dir vorbei oder kannst du sagen, ja danke, es ist direkt deployed, das gefällt mir. Ja, aber cooles Beispiel, vielen Dank dafür genau.
Und das bringt nämlich jetzt mich auch zu dem Punkt, weil du hast das jetzt schön differenziert, was der Unterschied ist. Die Frage ist doch jetzt wann.
Also sagen wir mal so, Delivery hat natürlich noch den extra Schritt aktiv zu entscheiden, wann es rausgeht, das Update oder das Essen in der Analogie. Das heißt du hast noch so ne Art Stage wo noch mal geprüft werden kann, genau richtig, das heißt da kann noch mal jemand mit Fingerspitzengefühl rangehen, sich das noch mal anschauen, noch mal n bisschen validieren ob alles in Ordnung ist und dann so die aktiv diese Entscheidung
treffen jetzt raus damit. Das hast du ja beim Deployment nicht, weil den Schritt versucht man sich natürlich auch noch einzusparen, weil der Vorteil dabei ist ja, dass du schnell veröffentlichst und demnach auch schneller Feedback wieder kriegst. Dazu logisch, je schneller es sag ich mal auf den Markt kommt, umso schneller wirst du ja Feedback erhalten. Da merkt man aber, dass CD auch
extrem abhängig von CI ist. Meiner Meinung nach, weil du brauchst ja jetzt ne ne richtig gute Continuous Integration. Die dir unfassbar viel Zuversicht gibt, um überhaupt sagen zu können, ich automatisiere jetzt mein Deployment, weil alles was integriert ist, ist so gut, dass es Produkt, also produktiv sein kann.
Es hat eine Qualität, um als fertiges Produkt zu gelten oder als Update und das finde ich ist halt auch n spannender Punkt, dass man noch mal ganz kurz auf das CI Thema kommt, nur noch mal um. Quasi herauszustellen, wie wichtig das am Ende dann ist, um überhaupt vernünftig CCD leben zu können oder aufbauen zu können.
Definitiv. Also ich find das auch gut, dass du es noch mal ansprichst, weil rein theoretisch kannst du ja auch CD machen ohne CI, das ist ja möglich, du kannst ja einfach sagen, OK, ich hab irgendwie meinen meinen Code den ich habe, also CI im Sinne von dem was wir ja in der letzten Podcast Folge besprochen haben. Ne, also du kannst natürlich
einfach deinen Code pushen. Force ohne Tests, ohne alles, dann hast du natürlich irgendwie diese Integration hinter dir, weil du musst ja irgendwie sagen, OK, ich möchte jetzt irgendwie neue Sachen in den Code, in in die Codebasis integrieren. Logischerweise, wie gesagt, das ist ja nicht das CI, über das wir reden und dann kannst du ja trotzdem einfach sagen, OK, der aktuelle Stand den ich jetzt hab, den deploy ich einfach, also ich bau quasi ich baue den
Code und ich. Rolle diesen dieses neues neue Erzeugnis sozusagen einfach aus. Ne ja, aber ist gut, dass du es noch mal sagst, weil damit das wirklich gut funktioniert, muss oder sollte auf jeden Fall der CI teil nicht fehlen, ne genau.
Wenn wir jetzt noch mal von der Pipeline schauen, du hattest ja gesagt, okay, für dich kommt erstmal das bauen und dann das Deployment beziehungsweise Delivery, dann gibt es noch einen Schritt, nur der Vollständigkeitshalber, der danach noch sehr wichtig ist, weil wir den jetzt schon angerissen haben, ist natürlich das Monitoring, um dieses Feedback auch zu kriegen, um quasi zu sehen, hat das jetzt
erfolgreich. Geklappt, um eine neue Auslieferung läuft alles so wie es soll, ist natürlich noch n wichtiger Schritt für die gesamte Pipeline. Das heißt du hast halt wie gesagt den CCI am Anfang, dann der CD teil mit Bauen und ausliefern, je nachdem Delivery oder Deployment, da würde ich gern gleich noch mal mit dir n bisschen tiefer 3 einsteigen und danach auf jeden Fall als letzten Schritt quasi dieses Monitoring um mal so ne Pipeline darzustellen. Ja ja.
Auf jeden Fall ist es auch n wichtiger Bestandteil am Ende auch. Gerade auch im DEF Ops Bereich logischerweise, und da wird es auf jeden Fall noch mal eine eigenständige Folge drüber geben, über genau diesen auf jeden Fall ringteil definitiv gut, aber dass du schon mal an Teaser ist, weil im Endeffekt ist das auch wirklich essentiell, genauso wie es sie eigentlich fehlen sollte, sollte am Ende das Monitoring auch nicht fehlen, weil sonst.
Ja, ist ja kein Fire in Forgot ne, ist ja nicht so, dass du sagst, ich deploy das jetzt und nach mir die Sintflut, ob der Kunde jetzt verärgert ist oder nicht. Ich arbeite an den nächsten Features und Knall die Ihnen gleich noch mal um die Ohren. So sollte jetzt CICD am Ende nicht gelebt werden. Halt ne definitiv guter Punkt. Also wenn man das jetzt noch mal kurz n bisschen zusammenfassen möchte, ist es ja so, dass bei Continuous Delivery haben wir ja
im Endeffekt wirklich eine. Ich sag mal manuelle Freischaltung eines, nennen wir es mal Software Updates. Das heißt du möchtest neue Software, also neue Funktionalität in eine Software reinbringen und dieses Update nenne ich es jetzt mal. Das musst du manuell noch mal freischalten, man kann sich das ja wirklich so vorstellen, dass man zum Beispiel die ganze Zeit neue Features entwickelt und.
Du willst jetzt aber zum Beispiel nicht sagen, ey, ich hab jetzt zum Beispiel ein Feature und dieses Feature, was neu ist, wird sofort an die Kunden ausgerollt, sondern du möchtest zum Beispiel sagen Feature 1234 und 5. Damit warte ich erstmal bis ich einen Stand habe, wo alle diese 5 Features vielleicht drin sind und erst dann kann ich sozusagen mein Software Update ausrollen, also wirklich releasen ne und genau und und und damit das dann funktioniert musst du dann
vielleicht sagen. Je nachdem, wie du es machst. Aber das einfachste, um sich das vorzustellen ist, du hast einen Klick irgendwo und sagst okay und jetzt bitte wirklich live schalten. So kann man sich das ja vorstellen und bei Deployment ist es halt so, dass genau dieser Schritt eben nicht notwendig ist. Das heißt du sagst okay ich mache ein neues Feature, pushe das, es läuft durch die Pipeline durch und danach ist es eben auch oder wird es auch in der Software an den Kunden oder an
die Kunden ausgerollt und. Damit hast du natürlich aber auch das Verhalten, dass du in dem Fall dann nicht solche Releases in dem Sinne erzeugen kannst, dass du sagst, ich möchte jetzt zum Beispiel mehrere neue Features auf Imar Releasen, sondern du released ja wirklich sehr, sehr iterativ. Ne. Ja, ich möchte einzelne, genau jede einzelne Änderung, jedes einzelne neue Feature oder auch Anpassung von Features. Genau.
Also es sind sehr kleine Änderungen, die direkt ausgeliefert oder ausgerollt, wie man auch so schön sagt, werden ne. Genau. Und im Endeffekt also sowas bringt natürlich auch irgendwie so vor und Nachteile mit sich. Ne also. Auf jeden Fall. Wenn du nämlich zum Beispiel mal fangen wir noch mal bei Delivery an, wenn du dir jetzt überlegst, was könnten so Vorteile sein? Also du hast halt ne gewisse Flexibilität auch in der Planung für Veröffentlichung.
Also du kannst zum Beispiel sagen, ich möchte jetzt meinetwegen alle 3 Monate so n größeres Release raushauen, was jetzt zum Beispiel bei größeren Softwarelösungen Desktop Applikationen ja öfter der Fall ist, dass es jetzt nicht.
Also gehen wir jetzt mal nicht von irgendwelchen Hotfixes aus oder so. Bugfixes ne, also irgendwas kritisches, sondern wirklich neue Features die reinkommen, dann bist du ja oft an dem Punkt, dass du sagst, ich will jetzt nicht jedes kleine Feature, was also so ne Teilmenge meiner gesamten Planung für das nächste Release ist, immer direkt an den Kunden raushauen. Ja ne, weil n absolut wichtiger Punkt ist ja auch zu sagen.
Wann nerv ich denn meinen Kunden, wenn ich jetzt die ganze Zeit offensichtlich Updates von ihm forder? Also wirklich so hinsichtlich die Anwendung zeigt an EY, es gibt ein Update, möchtest du updaten? Du denkst ja ja mach ich und am Ende des Arbeitstages ey es gibt ein Update, willst du updaten so also dann kommst du an einem Punkt wo der Kunde auch verärgert darüber ist.
Beispielsweise also da hast du halt einfach diese Flexibilität, du kannst das besser aufplanen ja auch meinetwegen hinsichtlich, dass du neue Features für die neue Version bewirbst und. So dass du sagst, Hey, guck mal dann und dann hauen wir n neues Release raus und dann sind die und die neuen Funktionalitäten da drin, die heiß erwartet sind oder die auf jeden Fall super geil wären. So du hast da halt einfach wie gesagt Spielraum.
Und die Frage ist natürlich, wie stabil ist deine gesamte Pipeline und deine ganze Infrastruktur, weil du ja wie gesagt diesen einen Schritt noch hast. Das heißt, jemand muss ja manuell noch ne Art Freigabe geben, indem man auf den Knopf drückt auf diesen virtuellen Knopf. So jetzt bitte ausliefern, das heißt du hast da noch mal ne Instanz zu sagen. Lass uns das noch mal checken, lass uns hier noch mal gucken.
Manuelle Tests vom User vielleicht ne, also nicht von dem Endverbraucher, sondern so einer der das anwendet, vielleicht aus dem aus dem Unternehmen, aus dem Projekt, das ist. Das gibt dir natürlich auch ne höhere Stabilität und Zuversicht am Ende, falls du sie benötigst. Das ist halt deswegen wohlgemerkt, das heißt nicht, dass das andere instabil ist, sondern du hast einfach nur noch eine. Also ein Einsprungspunkt mehr. Also das ist genau das. Kann aber halt genauso.
Natürlich aber auch wieder ein Nachteil sein, dass du zwar sagst okay man kann bis dahin erstmal sagen okay dieses die die neuen Updates sind verfügbar in diesem Bild sage ich jetzt mal und du kannst zu diesem Bild ziehen, kannst vielleicht auf eine Stage drauf zugreifen, die diesen Bild verwendet, wie auch
immer. Hat Vorteile, kann aber eben genauso gut den Nachteil haben, dass du sagst, na gut, du musst aber noch diesen manuellen Freigabeprozess, den hast du halt, was auch gleichzeitig wieder bedeutet, dass natürlich, wenn du kritische Updates reinbringen möchtest, hast du natürlich den Nachteil, dass die eventuell halt auch wieder
länger dauern, ne? Genau deswegen hab ich sie eben ausgeschlossen, weil das war so das idealste Szenario, dass du sagst, das sind nur so neue Features, aber das kann dir natürlich in die Suppe spucken, wenn es halt wirklich kritische Sachen gibt und du dann vielleicht so n großen Prozess da zur Freigabe noch drum rum hast und nicht einfach automatisch die Ployst, dann ne diese.
Fixes also, was ich zum Beispiel auch schon mal hatte, was ich auch schwierig finde und auch wirklich n tatsächlich irgendwie ne Art Nachteil ist, wenn man oder? Zumindest in dem Fall war so von der Infrastruktur, wie wir sie hatten, schon n bisschen der Nachteil von diesem.
Also wir haben in dem Fall Continuous Delivery gemacht, das heißt, Wir haben immer bis auf eine bestimmte Stage deployed, die aber nicht prot war, also das heißt, es wurde nicht produktiv, wurden bestimmte Features noch nicht freigegeben.
Weil halt eben auch die Anforderung war, dass, und das darf noch nicht oder soll noch nicht oder wie auch immer, also es kann ja auch sein, dass du zum Beispiel ein Feature was du freigeben möchtest oder was du ausrollen möchtest, vielleicht noch nicht vollständig ist, weil ein Feature zum Beispiel in Teil Tasks unterteilt ist beispielsweise, und dann hast du aber auf einem bestimmten Stand, hast du jetzt, sagen wir mal ich nenne es jetzt mal ein Drittel Feature oder ein dreiviertel
Feature, was auch immer das ist noch nicht ganz fertig dreiviertel Feature und jetzt kommt aber irgendwie ein kritischer irgendwas rein, was wirklich kritisch gefixt werden muss, dann ist ja die Frage, wie kommst du jetzt auf Prot?
Also wie kannst du diesen diesen kritischen dieses kritische Update auf die Produktivumgebung schalten, dass der User auch das bekommt, ohne dass du aber gleichzeitig die dieses dreiviertel Feature sozusagen schon die mit Deploys und das sind dann finde ich so Herausforderungen, die sich auf jeden Fall da auftun an der Stelle.
Ja, auf jeden Fall. Das ist ein sehr guter Punkt, dass du dann halt nicht weißt, also was für ein Stand kann ich denn jetzt hier gerade quasi ausliefern, was ist jetzt da drin, was ist vielleicht noch nicht komplett fertig, aber jetzt müssen die Fixes raus, wie du gerade so schön gesagt hast. Das ist halt dann einfach auch wieder der Nachteil am Ende.
Und gleichzeitig kommen wir immer auf die andere Seite von Deployment, da wiederum der Vorteil, weil es ist ja alles, was integriert wurde, auch schon ausgeliefert. Genau. Das heißt, du bist wieder auf so einer Kleinen, also bist so fein granular unterwegs mit deinen Deployments, dass es immer kleine Änderungen sind, die du ausrollst. Aber die sind dann halt auch wirklich quasi schon am Endkunden angekommen und das Feedback ist eingeholt. Weil du wirst ja merken, ob es
funktioniert oder nicht. Im Prinzip ne genau und genauso schnell kriegst du dann auch die Fixes quasi veröffentlicht und auch das Feedback, ob sie denn wirklich Fehler beheben und das ist halt dann da auf jeden Fall n großer Vorteil, dass du einfach diese ja ich sag mal schnelle Markteinführung hast. Genau. Und du hast halt auch einfach diese höhere Effizienz, weil du halt eben auch nicht mehr daran
denken musst. Also du, du hast ja irgendwo eine gewisse Art von Planung, die du bringen musst.
Wenn du sagst, okay wir wollen bestimmte Features dann und dann freischalten und wenn du das manuell machen musst, dann musst du natürlich, du hast halt einen viel größeren Planungsaufwand, weil du ja sagen musst okay wann kommt das rein, haben wir jetzt so viel, du musst ja ein bisschen mehr noch sage ich mal schedulen, was dann am Ende einfach wegfällt und halt dadurch natürlich die Effizienz steigert.
Weil du dich halt genau um diesen Kram nicht mehr kümmern musst, so. Du sagst halt OK. Ich bau n neues Feature und das geht raus und dann ist es auch da. Ja das. Ist natürlich n Nachteil bei dem Delivery, das haben wir jetzt nicht so explizit genannt, aber es ist n manueller Schritt und da kann halt natürlich auch was schieflaufen.
Ne also im Sinne von Anwendungsfehler, dass derjenige der es freigibt Mist macht, muss man ja einfach so sagen, ist natürlich auch immer n Risiko dabei, dann definitiv. Aber genauso hast du ja auch dann Nachteile beim beim Continuous Deployment, weil gerade wenn du sowas sehr automatisiert machst. Dann ist es natürlich auch irgendwo wichtig, dass du das ist ja das, was du am Anfang
auch schon gesagt hast. Deine Testabdeckung muss wahrscheinlich sogar noch höher sein, wenn du nicht noch mal irgendwie auf einer gewissen Stage, manchmal gibt es ja so Stages, die vor der Produktivstage kommen, die nennen sich dann manchmal so. Quality Assurance Stage oder ne Qualitätssicherung Qualitätssicherung genau, also sowas gibt es ja und das braucht man ja vielleicht nicht
unbedingt. Kann man machen, muss man aber nicht, aber Fakt ist ist ja es kommt ja direkt auf prot sozusagen und damit hast du ja genau den Punkt, dass im Normalfall, zumindest ist das für mich ne ganz logische Sache, ne höhere Testabdeckung da sein muss oder vielleicht auch nicht ne höhere Testabdeckung, aber man sollte sich mehr Gedanken um seinen ganzen. Seine ganzen Tests drumherum machen, dass sie halt, dass man sich auch wirklich auf die Tests
verlassen kann. Ja, ist absolut essentiell dabei, weil wenn jetzt quasi bei jedem zweiten Deployment irgendwas durchrutscht oder so, dann wirst du die Kunden am Ende nicht sehr glücklich stimmen damit. Das muss halt wirklich echt ne saubere Sache sein und ja ne hohe Testabdeckung haben ganz klar was man auch sagen muss was n Nachteil ist oder was einem zumindestens bewusst ist,
bewusst sein muss so rum. Ist natürlich, dass du im Verhältnis zum Delivery auch ne komplexere Pipeline hast und Infrastruktur, weil du halt einfach noch mehr automatisierungsschritte hast. Das muss man an der Stelle auch sagen. Also diese Vorteile musst du dir erkaufen durch zusätzliche Arbeit zusätzlichen Aufwand einfach ne diesen Vorteil von automatisches Ausrollen. Also ich mein klar hast du dann wahrscheinlich erstmal ne einmalige Mehrarbeit, die sich hinterher wahrscheinlich gar
nicht so also. Du musst ja diese Infrastruktur erst mal aufbauen. Die, die ja dann deutlich komplexer ist. Aber wenn du sie hast, ist ja erst mal gut. Es kann natürlich sein. Du hast mehr Wartung, auch ne, das muss man auch sagen. Also die Wartung wird natürlich durch ne komplexere Infrastruktur auch höher sein, gerade wenn denn mal was da drin
ist. Aber trotzdem denke ich auch wie du gerade so schön gesagt hast, dass dieser Aufwand, den du dann initial reinsteckst, dass du das wieder mit Plus hinten raus bekommst, sozusagen. Also, dass du die Zeit, die du dann einsparst. Irgendwann, dass sich das Dolle rechnet, sozusagen ne. Ich hoffe du weißt wie ich das meine, ich hab es glaube ich gerade n bisschen.
Komisch. Ausgedrückt, ich finde aber viel essentieller bei dieser ganzen Thematik ist, dass beides natürlich vor und Nachteile hat, aber hat. Aber es gibt für mich keinen klaren Gewinner an der Stelle und das haben wir auch schon n bisschen angeteasert und das möchte ich noch mal explizit jetzt sagen. Es muss halt einfach zu deinem Produkt passen, am Ende auch und. Ins passt in dem Moment zum Produkt, wenn es zu deiner potenziellen Usergruppe passt.
Also wenn du auch weißt, wie deine User, was die für n Update verhalten erwarten oder auch gerne hätten. Ja, wie das Stichwort werden Sie bombardiert mit Updates und sind sind genervt oder sind die Updates wirklich so fein granular, dass sie es gar nicht mal unbedingt mitbekommen?
In ihrem Daily Business sage ich mal ne, also du hast also zum Beispiel Websites, Web, 123, Websites, Websites, deutsch, Englisch immer hier websites oder also so Web Services, darauf wollte ich eigentlich hinaus, da können sich ja Sachen ändern, die du gar nicht in deinem Daily Business mitbekommst, weil sie dich nicht tangieren und trotzdem sind
diese. Updates zum Beispiel im Frontend, da ja. Ich finde halt zum Beispiel, also das ist also das, das bringt es eigentlich ganz gut auf den Punkt, also der das Beispiel mit Webseiten einfach aus dem Grund, weil du. Du im Endeffekt ja nicht. Du musst keinen manuellen Schritt auf deiner Seite durchführen oder wirst eigentlich auch nicht darüber benachrichtigt, ob sich jetzt was ändert.
Es passiert einfach und das ist ja der große Vorteil, weil wenn du jetzt zum Beispiel wirklich so n Update angezeigt bekommst und das heißt es gibt ne neue Version hallo ne, da musst du ja hast du ja n paar Schritte, du musst zum Beispiel sagen OK. Dann installieren wir die neue Version dann. Meistens wird es runtergeladen, installiert, du musst noch mal die Anwendung neu starten und so weiter wenn du das natürlich
extrem oft machen musst. Es ist natürlich fraglich, ob das so angenehm dann sozusagen immer ist. Ne, aber bei gerade bei Webseiten beispielsweise kannst du das super machen, weil keiner irgendwie kein User diesen Aufwand hat irgendwas damit zu tun, es passiert halt einfach und das ist der Vorteil, aber es ist gut, dass du sagst, also das ist natürlich wirklich die Frage. Wie möchte man das? Also passt es zum Produkt, ne. Genau, weil jetzt nimm mal das Gegenbeispiel wo Delivery dann
gut ist. Wenn du jetzt zum Beispiel in deinem eigenen Projekt ne gewisse Toolchain verwendest, oder oder gehen wir mal als Entwickler von deiner IDE aus und du bist in deiner Projektphase wirklich gerade am performen, sag ich mal, du codest die Features runter, hast deine feste Entwicklungsumgebung. Und die ID würde jetzt sagen, ja, aber ich schaue hier die
Updates, die automatisch rein. Also es gibt jeden Tag ist mal ein Button woanders, dann ändert sich hier mal eine Farbe, das sind ja alles Kleinigkeiten die dich aber triggern könnten oder vielleicht einfach nur du hast so automatisierte Workflows, die sich dann ändern auf einmal. Also dass du quasi Updates automatisch bekommst ohne irgendwelche, so wie bei der bei der Website ohne irgendwelche Hinweise.
Das würde dich ja einschränken und das willst du in dem Moment als User in der Regel nicht, sondern du sagst, ach weißt du, es gibt jetzt mal wieder ein Quartalsupdate, zum Beispiel bei unseren Geliebten Jet Brains IDES und dann weißt du einfach, OK, jetzt ist halt wieder soweit und jetzt kann ich aktiv entscheiden, möchte ich updaten oder nicht, ist gerade ein guter Zeitpunkt mich damit zu beschäftigen oder nicht, aber es wird ja nicht aufgezogen und das sind halt so diese
unterschiedlichen Herangehensweisen. Ja, definitiv. Und. Was auf jeden Fall ein guter Punkt ist ist, du kannst ja auch im Endeffekt gucken, wie du deine Infrastruktur am Ende gestaltet, also genau auch auf diesen, auf die auf das Produkt
zum Beispiel angepasst. Weil genauso kannst du ja zum Beispiel sagen, Okay, angenommen, du möchtest aber immer den neuesten Stand auch direkt ausrollen, möchtest aber bestimmte Features vielleicht nicht gleich offensichtlich machen, dann hast du zumeist zumindest aber auch das.
Techniken, mit denen du arbeiten kannst, wie zum Beispiel sogenannte Feature Flags, die dir im Endeffekt zwar die Anwendung zur Verfügung stellen, die gesamte Anwendung mit allen neuen Features, aber du siehst halt vielleicht 3 oder 4 der neuesten Features nicht. Also das ist halt auch eine Möglichkeit, womit man aber wiederum gucken muss.
Hast das wiederum zum Produkt, weil wenn du dafür aber trotzdem zum Beispiel jeden Tag dein was weiß ich dein Schreibprogramm updaten musst, dann ist es natürlich vielleicht für den User auch wieder genau. Also genau diesen Trade auf muss man halt gucken oder sein seine User dann im Endeffekt kennen genauso und das finde ich ist auch ein interessanter Punkt,
wenn man jetzt sagt du hast. Ist Delivery beim Delivery kannst du sagen okay manueller Schritt, du released irgendwie was einen festen stand, vielleicht checkst du da vielleicht im Vorfeld noch mal ein bisschen genauer, was da passiert. Kann man das so ausrollen? Ist das jetzt wirklich ich sag mal Fail safe was auch immer beim. Continuous Deployment hast du
genau diesen Schritt ja nicht. Die Frage ist ja jetzt, was ist denn wenn du sagst okay ich hau ein neues Feature raus, das geht direkt an alle raus und jetzt hat das einen Fehler so und dann haben was weiß ich wie viele user man dann da draußen hat für seine. Millionen, Millionen Millionen. Oder ein Dutzend. Also du hast ja dann im Endeffekt diesen Fehler an alle deployed am Ende und.
Genau. Da ist natürlich dann vielleicht auch die Frage OK, gibt es denn vielleicht Techniken, mit denen man arbeiten kann, dass genau sowas nicht passiert, weil ich sag mal, Fehler kommen ja irgendwie immer, also treten ja immer mal irgendwann auf. Richtig, das ist n guter Punkt, da können wir auch noch drüber sprechen, wenn ich mich halt für dieses also CD, also im Sinne von Deployment entscheide, muss
ich 2 Punkte beachten dabei. Der eine Punkt, der ist sehr wichtig und der ist auch allgemeingültig.
Deswegen dem als erstes, ich muss mir immer überlegen, wie mein Rollback aussieht, also wenn angenommen es geht was schief, was ist meine Strategie um schnellstmöglich wieder auf den Stand zurückzusetzen der funktioniert hat mal so ein ganz allgemeiner Punkt der essentiell ist, weil wenn ich dann planlos bin und keine Ahnung habe ich dieses Update quasi zurück hole, dann habe ich richtig verloren auf jeden Fall.
Das mal als erstes und der zweite Punkt und ich denke da möchtest du jetzt auch drauf hinaus sind verschiedene Deployment Strategien die sich auch so etabliert haben, die man quasi auch in verschiedensten Lehrbüchern findet, weil sie auch einfach gut sind. Da gibt es ja beispielsweise um mal 2 gängige zu nennen, einmal das Blue Green Deployment, was sehr bekannt ist. Das könnten wir mal besprechen.
Und was ich auch sehr spannend finde ist der das Canary Deployment oder Canary Releases, weil es halt auch so ne schöne Analogie hat, die können wir auch mal nennen, warum es denn so heißt finde ich halt auch ganz witzig, aber über die beiden würde ich mal noch mal sprechen. Ja aber. Also das mal so noch mal anreißen. Genau. Ich hatte ja eben auch schon mal, also Feature Flags gehören auch in die Richtung, das hat die auch angerissen, aber wie gesagt, Lass uns auf jeden Fall da.
Abgehakt. Das ist sehr schön von Gäns sein schon. Genau, aber die beiden nehmen wir jetzt auf jeden Fall noch mal ein bisschen genauer unter die Lupe und ich finde das ganz cool, weil im Endeffekt kann man sich beide so vorstellen, dass genau man. Man sagt Okay, du hast irgendwie einen Fehlertritt auf und dann kann man genau in diesen Fehlerfällen.
Wenn irgendwas ist, kann man sagen okay ich, ich möchte irgendwie, wir deployen gerade ein fehlerhaftes System, wir müssen das wieder rückgängig machen und im Endeffekt ist das Blue Green Deployment um das kurz zusammenzufassen, so dass du sagst, du hast eine neue Version und sagst okay Pass auf, jetzt gehe ich auf die neue Version, also zum Beispiel auf die. Die Blue Stage, ich weiß gerade,
ich krieg die mal durcheinander. Du gehst von Blue auf Green oder von Green auf Blue. Also du hast eine Blue Stage und du hast eine Green Stage und wenn deine aktuelle Version auf der Blue Stage läuft, dann gehst du auf die Green Stage rüber so und lässt jetzt alle User die Green Stage benutzen und wichtig ist hier das Monitoring was wir vorhin schon angesprochen haben und wenn du da nämlich mitkriegst irgendwas geht schief, zum Beispiel die User können sich nicht mehr auf dein
System einloggen oder was auch immer das.
Dann musst du das ja irgendwie mitkriegen und dann in diesem Fall, wenn du das mitbekommen hast, kannst du wieder zurückgehen auf das alte System und sagen okay, das war es, wir müssen jetzt noch mal gucken, dass unsere neue Änderung, die hatte irgendwas, das ist blöd und der Canary Release ist ja so, dass du im Endeffekt sagst okay wir shiften den Traffic ein bisschen, das heißt, du sagst zum Beispiel erstmal, du hast neue Features. Oder eine neue Version deiner
Software und lässt aber erstmal nur einen Teil der Anwender und Anwenderinnen diesen diese neue Version verwenden. Und wenn du dann aber merkst, oh guck mal hier, die neue Version ist eigentlich gar nicht so schlecht, dann kannst du sozusagen darüber shiften. Wenn du aber merkst, oh keine Ahnung, die 10% der Anwender haben jetzt vielleicht irgendwie einen Fehler, was du wieder Monitor musst. Mitkriegen musst. Dann kannst du wieder zurückgehen und sagen, die neue Version ist nicht so gut.
Der Vorteil ist natürlich hier, dass beim Canary Release wenn was schief geht, nicht alle das mitkriegen, sondern halt im Endeffekt eigentlich nur ein kleiner Teil deiner User Gruppe. Weißt du eigentlich warum es Canary. Release heißt, ich habe es mal gehört, aber ich glaube du kannst es besser erklären. Weil ich find das ist ne ne sehr
coole Geschichte dabei. Das geht darauf zurück, dass Minenarbeiter in Kohlemin Kanarienvögel mitgenommen haben, weil es im Prinzip die Vögel ne Art Frühwarnsystem für schädliche Gase waren, weil die Zwitschern ja so vor sich hin und haben Spaß. Hoffentlich den Aspekt lassen wir mal aus, wie es dem Vogel dabei ging.
Aber im Prinzip war es n Frühwarnsystem, wenn er aufgehört hat zu zwitschern, bis hin, dass er vielleicht sogar von seinem Stock gefallen ist und gar keinen Mucks mehr von sich gegeben hat, weil dann sind die Minenarbeiter auf jeden Fall rausgerannt. Das war n Anzeichen dafür, dass Gase austreten, die du weder sehen noch riechen konntest, im Prinzip aber die tödlich enden können.
Und da deswegen haben sie quasi diese Vögel mitgenommen und genauso nutzt du quasi bei dieser Deployment Strategie so ne Art Frühwarnsystem, dass du erstmal dich so vorsichtig hinein tastest, sozusagen ne und guckst läuft es OK, es läuft, es kriegen noch n bisschen mehr user, es läuft immer noch und irgendwann hast du die Zuversicht, wenn du zum Beispiel schon 50% der User umgestellt hast zu sagen, OK, all in jetzt können alle. Ja, aber wenn die Mina weiter
rausgelaufen sind. Dann haben die aber die Vögel mitgenommen, oder? Wenn sie noch am LEH waren, hoffe ich, dass sie die Vögel mitgenommen haben, sonst brauchen sie ja auch jedes Mal neue Vögel. Das wäre gar nicht cool. Das rentiert sich nicht. Das rentiert sich nicht. Die armen Vögel. Aber ja, coole Geschichte, auf jeden Fall. Aber im Endeffekt kannst du ja dieses Canary Release auch nicht nur für Fehler nutzen, sondern zum Beispiel auch zu wie nennt
sich das zum. Zu Analysen also du kannst ja n neues Feature zum Beispiel deployen und dann erstmal nur ne gewisse Usergruppe an diesen Featuren teilhaben lassen. Also selbst wenn du weißt oder ne sagen wir mal, gehen wir mal davon aus, dass es jetzt keinen Fehler gibt, aber du kannst zum Beispiel 10% deiner User einfach mal das neue Feature testen lassen und auch einfach Rückmeldung kriegen.
Und zum Beispiel im Endeffekt auch merken, ob die User dieses Feature in Angriff, also in Anspruch nehmen, in Anspruch nehmen oder halt sagen, Oh, ist ja irgendwie blöd. Also wie gesagt, hier auch trotzdem wieder Monitoring irgendwie, dass du genau diese Informationen wieder zurückspiegeln kannst und damit arbeiten kannst.
Aber im Endeffekt dient das ja zu verschiedenen Möglichkeiten, ne, aber das blöde natürlich bei zum Beispiel diesem Blue Green deploymentist du kannst das genauso damit auch machen, nur das blöde ist, wenn du angenommen. Ein Update aus Rollst und alle kriegen das auf einmal und alle finden das wirklich richtig schlimm.
Dann kannst du natürlich dadurch vielleicht sogar auch deine Anwendung irgendwie begraben, weil auf einmal die, sagen wir mal, das Vertrauen in dieser Anwendung von allen Usern auf einmal einbricht, also da muss man dann gucken, dass es natürlich für verschiedene wieder für verschiedene Möglichkeiten, auch verschiedene, wie sagt man Release Strategien gibt. Also es gibt ja verschiedene nicht weil. Es gibt das, und das gibt es auch noch, und das ist besser als das.
Und meistens hast du ja im Endeffekt immer diese Daseinsberechtigung für die verschiedenen Strategien, die es halt eben gibt. Ja, also bei dem Blue Green hast du natürlich den Vorteil, wenn jetzt auf Blue quasi der ganze Traffic ist, also die alte Version und auf Green deine neue, du hast ja wirklich die komplett parallel liegen. Samt Infrastruktur, was halt auch n Nachteil ist.
Das ist sehr teuer am Ende beides, also dass du wirklich ne Duplikation hast, die du dann abänderst ne, aber du hast ja theoretisch die Möglichkeit auch Leute auf, also nicht jetzt von deinen End Usern, aber vielleicht hast du n Test User Kreis, Beta User oder vielleicht aus deinem eigenen Unternehmen Leute die einfach sag ich mal auf die. Grüne Seite gehen, indem sie die richtig adressieren und dann quasi auf die geupdatete Version kommen und das Grün lesen
können. Kommen auf die grüne Seite. Genau das geht ja theoretisch, aber wenn du dann sag ich mal den Traffic umlegst, was ja am Ende zum Beispiel wirklich nur ne Umadressierung ist, das ist einfach auf einmal DNS mäßig oder so aufs Richtige, zeigt auf das neue und dann gehen alle dahin, das ist halt der Knackpunkt am Ende ne und da.
Kann es halt sein, dass das denn doch nicht so cool ankommt, hast aber den Vorteil, dadurch, dass du ja wirklich beide, also diese Infrastruktur gedoppelt hast, kannst du jederzeit sehr sehr schnell komplett zurückschalten, weil das andere noch exakt so da ist, wie es vorher war. Das heißt Thema Rollback, was ich vorhin angesprochen habe, ist die Strategie recht simpel, du legst quasi wieder einen Schalter um, so gesehen und gehst wieder auf die alte Umgebung, das.
Das ist halt da schon ein großer Vorteil, muss man sagen. Allerdings hast du halt hohe Kosten dahinter. Definitiv ja. Und das andere ist halt einfach auch viel Granularer. Also du kannst halt einfach viel genauer dein, sagen wir mal evaluieren, wie zum Beispiel auch deine Anwendung zum Beispiel auf verschiedene, also wie die zum Beispiel skaliert. Also du kannst jetzt zum
Beispiel sagen. Angenommen du hättest beim Blue Green Deployment das Problem, dass du sagst, oh, ich habe jetzt irgendwas eingebaut, wo meine ganzen Server unter einer gewissen Last zusammenbrechen, dann kannst du aber theoretisch auch nicht herausfinden, ab welchem Punkt ist es denn vielleicht soweit? Das kannst du beim Canary Release rein theoretisch gut machen, weil du ja rein theoretisch Floating sozusagen an 1020 3040. Wie auch immer viel viel Prozente ausrollen kannst der
User, wenn du es möchtest. Vorausgesetzt, du hast so ein gutes Monitoring dahinter, weil bei Canary ist natürlich ein Nachteil, dass das Monitoring sehr komplex ist, weil du einfach beides monitoren muss, weil es parallel existiert auf der gleichen Umgebung. Wenn du jetzt die Infrastruktur bei Blue Green hast, ist alles gedoppelt, das heißt du kannst einzeln die Dinger überwachen, sozusagen sowohl Blue als auch Green und bei Canary hast du natürlich diesen Mix, wenn das
natürlich super funktioniert kannst. Ganz klar, dass du es, dieses langsame Ausrollen, dir eine unglaubliche Zuversicht gibt, dass es funktioniert, wenn du denn schrittweise quasi, sage ich mal, die User erhöhst. Aber du hast halt diesen Nachteil, dass das komplexer und aufwendiger wird. Auf jeden Fall das Monitoring. Das ist ja leider oft so, dass wenn du sagst okay du möchtest mehr, sagen wir mal Features reinbringen, dann wird es meistens halt irgendwie auch komplexer.
Ne, leider. Leider ist das so und ein Punkt, den man auf jeden Fall auch sagen musste.
Den Nachteil haben aber in meinen Augen beide dadurch, dass es immer 2 Versionen gibt, also oder beziehungsweise nicht immer, aber dass man von 2 Versionen spricht, Blue Green sind sie parallel, Canary ist irgendwie so eine Koexistenz sage ich mal, dass ein Paar haben schon die neue Version, paar nicht, je nachdem das Verhältnis shiftet ja dann wie ist denn das so hinsichtlich Infrastruktur auch so Richtung? Datenbanken oder so da, da sehe ich halt auch Probleme.
Wenn du sag ich mal so ne Art Migration auch hast, weil du was kritisches oder so Breaking changes mäßig änderst, dann hast du bei Blue Green hast du es zwar parallel, aber wenn sie zum Beispiel auf die gleiche Datenbank am Ende zugreifen oder Third Party mäßig. Hast du da auf jeden Fall auch ne Menge zu beachten? Nicht dass du sagst, oh ich mach n royback, ich geh zurück und hast aber schon irgendwas migriert, was denn gar nicht mehr passt und Blue ist am Ende
dann auch zusammengebrochen. Mal so worst Case und das gleiche natürlich auch bei Canary ne, weil da hast du es ja sogar wirklich. Da muss ja beides gleichzeitig da sein, sozusagen. Definitiv. Das ist auch ein sehr, sehr spannendes und interessantes Thema. Würde jetzt wahrscheinlich aber auch den Rahmen sprengen und zwar Datenbank Migration, wenn wir darüber auch mal eine Podcast Folge machen sollen.
Ich hoffe, dass der liebe Zuhörer, lieber Zuhörer, du jetzt nicht schreiend ausmachst diese Folge, weil es jetzt das böse Wort Datenbanken gefallen ist. Genau, aber wenn ihr Interesse dazu da ist, dann können wir dazu auch gerne eine Folge machen. Schreibt uns gerne auf unserer Podcast Mail.
Genauso könnt ihr uns auch schreiben, was eure favorisierten Release Strategien sind oder ob ihr zum Beispiel mal eine Release Strategie gehört habt, die ja auch noch mal gern thematisiert haben wollt.
Immer raus damit finden wir auf jeden Fall super spannend genau, aber hier haben wir jetzt genau diese 2 mal einmal ein bisschen unter die Lupe genommen, ein bisschen genauer und ich würde einfach jetzt auch sagen, ich würde vielleicht noch mal das Ganze ein bisschen zusammenfassen um noch mal zurückzukommen auf Continuous Delivery, Continuous Deployment. Weil im Endeffekt haben wir jetzt gesagt, Okay, es gibt diese beiden Varianten, die genommen werden.
Für CD. Kommt halt drauf an, unter welchen Bedingungen, das sollte man auch vielleicht ein bisschen genauer überprüfen, was braucht man eigentlich genau, es ist nicht einfach nur ja, nimm jetzt Continuous Deployment und dann bist du sozusagen ganz. Oben ganz vorne dabei. Sondern es muss halt immer ein bisschen genau, also es muss angepasst werden auf das, was auch wirklich benötigt ist.
Und wenn man jetzt zum Beispiel sagt, Okay Continuous Delivery bietet natürlich mehr Flexibilität beziehungsweise Kontrolle darüber, was wann released wird oder veröffentlicht wird und eignet sich halt auch im Endeffekt für Umgebungen, denen Benutzererfahrung sorgfältig
gesteuert werden muss. Also wenn du jetzt wirklich sagst, okay, wir wollen jetzt nicht immer gleich immer alles rausballern, sondern zum Beispiel gucken okay, wir haben jetzt ein neues Feature Set, das wird jetzt released und da gucken wir jetzt mal ganz genau, wie das jetzt ankommt so.
Und wenn du jetzt aber sagst okay, wir sind aber eher so ein Team, was eine versucht, eine hohe Automatisierung und eine schnelle Veröffentlichung für ganz schnelles Feedback und sehr klein granular halt eben zur Verfügung zu stellen, wenn man also wenn man das machen möchte, dass wenn das das Ziel ist, dann ist natürlich Continuous Deployment sehr gut. Man sollte aber wie gesagt hier auch darauf aufpassen, dass man natürlich eine robust Infrastruktur braucht, um.
Und auch meistens eine komplexere Infrastruktur und am besten auch einen höheren Fokus auf die Tests. Also Fokus auf Tests sowieso immer da, aber sogar vielleicht noch ein bisschen mehr. Sehr gut, sehr gut, sehr gut zusammengefasst. Ja würde ich sagen, können wir die Podcast Folge auch beenden oder? Also wir haben glaube ich jetzt alles was wir uns vorgenommen haben heute mal besprochen zu dem Thema, alles weitere würde jetzt den Rahmen sprengen und werden mal noch extra folgen.
Im Zuge der Def Ops Reihe. Definitiv also Tino auf jeden Fall danke für diesen netten Talk, mal wieder. Auch dir danke. Und wenn wir noch irgendwas vergessen haben oder dich noch was weiteres gerade in zu diesem Thema interessiert, liebe Zuhörerin, lieber Zuhörer, dann lass es uns wissen und genauso, ob dir diese Podcast Folge oder generell unser Podcast gefällt, lass uns das auch wissen. Kannst du uns über unsere Podcast Mail mitteilen.
Vergiss auch nicht eine kleine Bewertung auf der Plattform, auf der du gerade hörst da zu lassen. Einfach mal super einfach mal 5 Sterne da lassen oder was du möchtest. Ansonsten. Dezenter Hinweis, aber. Ansonsten, wenn du irgendwie sagst, der Podcast ist total cool. Ich folg den beiden auch auf Twitch oder auf den anderen Plattformen ist alles in den Shownotes verlinkt. Und du möchtest uns noch n bisschen mehr supporten?
Dann hast du die Möglichkeit das über ne kleinen kleinen Spenden ne kleine Spende zu machen, auch die den Link zur Spende findest du auch in den Shownotes und ansonsten würde es uns super freuen, wenn du einfach mal den Podcast an 2 deiner Freundinnen oder Freunde empfiehlst und in dem Sinne würde ich sagen, hören wir uns beim nächsten Mal wieder deine Coding. Buns gemeinsam besser.