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.
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.