Latest / Coding Buddies | Tech & Dev-Mindset / DevOps #4 - Gamechanger: Continuous Deployment

Transcript

DevOps #4 - Gamechanger: Continuous Deployment · Coding Buddies | Tech & Dev-Mindset

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