#143 Ship It! Deployment-Strategien und Anti-Patterns auf der letzten Meile

Dein Code ist nichts wert, bevor er nicht in Produktion ist!

Viele Software-Entwickler*innen haben sich bereits in der Situation gefunden, wo wir immer und immer wieder über den eigenen Source Code iterieren, um diesen noch schöner zu machen. Soviel Spaß dies auch macht … ist das schönste Gefühl jedoch, wenn jemand meinen Source Code wirklich nutzt. Und das geht nur, wenn wir diesen auch deployen.

Oder etwas direkter gesagt: Dein Source Code ist solange nichts wert, bis dieser nicht in Produktion ist und vom Kunden genutzt werden kann. Klingt hart, ist aber Fakt.

Deswegen geht's in dieser Podcast Episode um das Thema Deployment.

Wir sprechen über Anti-Patterns wie manuelle Deployments, Big-Bang Deployments und Deployment Monolithen. Wir schauen uns an welche Herausforderungen wir bereits in unserer beruflichen Laufbahn bei Deployments gesehen haben, wie zB Caching, CDNs, Deployment unter Hochlast oder das Einspielen von Datenbankänderungen und geben mal eine Tour durch verschiedene Deployment-Arten, mit u.a. Canary Deployments, der Blue-Green-Stratgie, Feature Flags oder Shadow Deployments bzw. Dark Launches.

Final bringen wir die Frage auf den Tisch, wann du das letzte mal deinen Rollback getestet hast.

Bonus: Wie macht man eine Podcast-Episode über Deployment ohne Continuous Delivery und Continuous Deployment (CD) zu erwähnen?

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:04) Der Wert von automatisierten Deployments

(00:04:46) Werbung/Info

(00:05:46) Der Wert von automatisierten Deployments

(00:13:40) Datenbank-Deployments und Rollbacks

(00:19:04) Anti-Pattern: Komplizierter Deployment Prozess

(00:24:47) Anti-Pattern: Big-Bang-Deployment

(00:30:10) Ein schneller Feedback-Cycle

(00:32:45) Anti-Pattern: Deployment-Monolith

(00:42:28) Herausforderungen beim Deployment: Caching, CDN und Traffic

(00:52:24) Deployment-Strategien

(01:08:34) Metriken für deinen Deployment-Prozess

(01:13:18) Nicht jede Software braucht 5 Deployments pro Tag

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:00 - 00:00:04)

Weil ich jetzt gerade die Tage wieder über das Thema Deployments gestolpert bin.

Andy Grunwald (00:00:04 - 00:00:08)

Moment, du warst gerade in Tirol auf Urlaub oder fast in Tirol auf Urlaub. Wie kommst du da auf Deployments?

Wolfi Gassler (00:00:09 - 00:00:42)

Ich war im Allgäu. Von Duisburg fährt man halt sechs, sechseinhalb Stunden dahin. Da hört man ziemlich viele Podcasts und da wird das Wort hier und da mal erwähnt bei den Podcasts, die ich höre. Meine Frau kann es nicht mehr hören, weil bei uns haben wir die Regel wer Auto fährt, bestimmt die Podcasts. Das bedeutet natürlich auch, dass ich, wenn ich Beifahrer bin, auch sowas wie Kaulitz Hills und sowas hören muss. Zweitausendein. Aber nun gut, ist ja eine gute Bildung. Regeln sind Regeln im Auto. So passt das. Auf jeden Fall bin ich über das Thema Deployments mal wieder gestolpert und da habe ich mir darüber ein bisschen Gedanken gemacht, bei einer Hundebergrunde sozusagen. Und deswegen möchte ich eine Frage an dich weiterleiten. Was fällt dir als erstes beim Begriff Deployments ein?

Andy Grunwald (00:00:42 - 00:01:11)

Ja, du hast einen sehr interessanten Zeitpunkt erwischt, weil ich hatte wirklich gestern eine Diskussion über Deployments, eine sehr lange Diskussion über automatisierte Deployments, sowohl mit Admins wie auch Software Developer. Und ich war eigentlich wirklich erstaunt, wie kritisch das Ganze noch gesehen wird. Also dass das gar nicht vielleicht so hilfreich ist, automatische Deployments und die optimierte Deployment Pipelines zu haben und dass das auch gar nicht unbedingt etwas ist, was man verfolgen sollte. Ist es was, was man verfolgen sollte?

Wolfi Gassler (00:01:11 - 00:01:55)

Du, meines Erachtens nach kann das jeder so handhaben, wie er möchte. Also meines Erachtens nach sind manuelle Deployments ja auch in irgendeiner Art und Weise so eine Art Jobsicherung, wenn man, wenn man so gatekeeping macht. Ich bin ganz ehrlich, ich finde es einfach stinkend langweilig, manuelle Deployments zu machen. Sollte man automatisierte Deployments anstreben? Meines Erachtens 100 % ja. Es gibt natürlich verschiedene Ebenen und ich höre immer wieder und das höre ich jetzt auch aus deinem Gespräch so ein bisschen raus, dass automatisierte Deployments immer noch als Königsklasse gesehen werden bzw. Als Champions league und dass das vielleicht in der Cloud native Welt in anführungszeichen Standard ist, aber dass es sehr viele Firmen Systeme gibt, die bei weitem noch keine automatischen Deployments implementiert haben.

Andy Grunwald (00:01:55 - 00:02:16)

Aber du sagst ja schon richtig Cloud native. Und dieses Argument höre ich sehr, sehr oft, dass das ja nur was für diese Cloud ist, für die Cloud native Leute, für große Firmen, die da 100 Nodes auf einmal irgendwie mit demselben Rollout machen, also bespielen müssen und solche Dinge. Also nur für große Projekte eigentlich das ganze gedacht ist.

Wolfi Gassler (00:02:16 - 00:02:24)

Meines Erachtens nach kommt der richtige Wert von automatisierten Deployments gerade in kleinen Teams und in kleinen Firmen zweitausendein richtig zum Scheinen.

Andy Grunwald (00:02:24 - 00:02:24)

Warum?

Wolfi Gassler (00:02:24 - 00:03:28)

Naja, du hast fünf Mitarbeiter, vier Softwareentwickler und einen Systemadministrator oder jemand, der sich um den Betrieb kümmert. Und ich gehe stark davon aus, dass es konstant Änderungen an der Infrastruktur gibt, wie z.B. mail Server, Google pusht irgendwie SPF und wie heißt das, d Mark Sicherheitsstandard und so weiter. Und da muss alles rumkonfiguriert werden. Und wenn du die Betriebsperson, die konstant busy hältst mit irgendwelchen Deployments, zweitausendein, es tut mir leid, aber da wird dann zwischenzeitlich bestimmt noch mal gesagt, ja, ich habe jetzt keine Zeit und wir haben ja schon wieder 15 Uhr, weil um 16 Uhr mache ich Feierabend und deswegen wird das Diplom erst morgen gemacht. Also das blockiert ja ganz offensichtlich. Und deswegen denke ich, wenn es automatisiert ist, kommt es gerade bei kleinen Firmen, wo jede Mitarbeiterin und jeder Mitarbeiter wirklich gewertschätzt wird und wo es auf die Arbeitskraft auch wirklich ankommt, zum Vorschein. Nicht bei einer großen Firma, wo du auch mal einen Quiet Day machen kannst, wo ob der Ludwig und die Melanie jetzt arbeiten oder nicht, das ändert jetzt am Jahresprofit jetzt nichts, wohingegen bei der kleinen Firma halt schon.

Andy Grunwald (00:03:28 - 00:03:33)

Aber es kostet natürlich auch Zeit, diesen Deployment Prozess automatisiert einzurichten.

Wolfi Gassler (00:03:34 - 00:03:42)

Du kannst sagen, das kostet Zeit, aber du kannst das auch als Investment sehen. Und Investments gibt es ja einen Return in der Regel. Und Achtung, da hast du wieder die Zeit.

Andy Grunwald (00:03:42 - 00:03:46)

Hast du private Projekte, wo du der einzige bist, die komplett durchautomatisiert sind?

Wolfi Gassler (00:03:46 - 00:03:47)

100 %, ja.

Andy Grunwald (00:03:47 - 00:03:50)

Was? 100 % deiner Projekte oder nicht?

Wolfi Gassler (00:03:50 - 00:05:31)

100 % meiner Projekte, aber wenn ich mal wieder ein Zeitprojekt beginne, Achtung, Entschuldigung, ich habe mich versprochen, wenn ich mal wieder eine domain kaufe, dann fange ich in der Regel an, mich als allererstes um den Deployment Prozess zu kümmern. Und das habe ich mir zur Angewohnheit gemacht, wenn es eine Web App ist oder eine Web API oder eine Webseite, dann kümmere ich mich in der Regel, dass ich einen leeren Nginx Container schippe, wo dann die Nginx Status Seite oder diese Standardseite da kommt und erst dann anfange, eine hello World HTML Seite auszuspielen und dann erst anfange, mit PHP ein hello World dahin zu schreiben. Oder letztens auch wieder was mit Mobile Development gemacht, mit Flutter, ich habe nur einen hello World auf den Screen gepackt und habe mich dann erstmal durch iOS Deployments auf Mac gekämpft, damit ich das auf mein iPhone schicken kann etc. Weil nur dann bin ich wirklich ready, schnell zu shippen. Und ich nenne das immer, bzw. Ich klaue das jetzt, das Wort, was ich jetzt sage, ship fucking early. Viele Leute halten ihr Deployment immer so weit zurück, bis die App fertig ist, bis die App Kernfeatures hat und so weiter. Das impliziert für mich immer so ein bisschen, dass man denkt, die Welt wartet auf meine App. Nee, kauf eine domain, schieb das hoch, sorry, aber keiner geht auf die domain, keiner kennt die domain. Und wenn du doch was zu verheimlichen hast oder irgendwie das noch nicht der Welt zeigen möchtest, pack so ein HTTP Basic out da drauf, Passwortschutz oder was weiß der Geier nicht. Aber meines Erachtens nach sollte man bei neuen Projekten als aller aller allererstes den Deployment Prozess machen, weil jetzt kommt das Lustige, da kommen solche Diskussionen, wie du gerade genannt hast, nämlich gar nicht auf.

Andy Grunwald (00:05:31 - 00:05:56)

Okay, dann setzt du dir jetzt mal deine rosarote Brille von deinen Greenfield Projekten da ab, weil in der Realität sind solche Greenfield Projekte ja eher die Seltenheit und du hast ja mit bestehenden Projekten zu tun, die es also schon länger gibt, die vielleicht sogar aus der Zeit kommen, wo eben diese Automatisierung vielleicht sogar sehr schwer war. Und man hat es halt immer schon manuell gemacht und das ist ja super schnell, wenn man es manuell macht. Und jetzt müsste man irgendwie in diese Automatisierung investieren.

Wolfi Gassler (00:05:56 - 00:06:28)

Wir müssen mal ganz kurz feststellen bzw. In Anführungszeichen definieren, was denn eigentlich automatisierter Deployment Prozess heißt. Denn im Endeffekt haben wir gerade schon das böse Wort Cloud native genannt. Für mich ist ein automatisiertes Deployment eigentlich nur etwas, wo kein Mensch dauerhaft sechs Befehle ausführen muss. Also ich packe jetzt das Artefakt, meine App, in ein zip File und dieses Zip File packe ich dann auf FTP Server oder habe vielleicht ein Bash Script mit Air Sync und das läuft dann irgendwie über eine Schleife oder ähnliches.

Andy Grunwald (00:06:29 - 00:06:32)

Also ein Skript, was ich anstoße, wäre für dich auch automatisiertes Deployment.

Wolfi Gassler (00:06:33 - 00:06:43)

Ich kenne super viele Firmen, die packen einfach einen Zip auf irgendeinen Server, entpacken das und switchen irgendeinen Sümlink. Offen gesprochen, Trivago läuft, glaube ich, immer noch so.

Andy Grunwald (00:06:43 - 00:06:47)

Also was wäre dann manuelles Deployment für dich?

Wolfi Gassler (00:06:47 - 00:07:06)

Auch das Skript manuell anstoßen durch einen Menschen? Und dann daneben sitzen und das dauerhaft beobachten, ist für mich ein manuelles Deployment. Für mich ist ein manuelles Deployment gegebenenfalls nicht immer das, was der Mensch ausführt, sondern konsumiert effektiv Arbeit, Zeit eines Menschens ein Deployment durchzuführen.

Andy Grunwald (00:07:07 - 00:07:16)

Und was ist da das Problem dabei? Also es konsumiert Zeit, okay, aber Deployments konsumieren in irgendeiner Form immer Zeit. Man muss danach auch was prüfen, auch wenn es komplett automatisiert ist.

Wolfi Gassler (00:07:16 - 00:08:17)

Warum? Du hast doch ein Monitoring System und du vertraust deinem Monitoring System. Ja, das bedeutet, du bist ja wohl hast du jetzt eine HTTP App, dass du dann 200 zurückbekommst und also du musst deinen System ja schon vertrauen. Und wenn du den Systemen, die du selbst erzeugst, dein Monitoring System oder deine Applikationen, wenn du, wenn du dessen nicht vertraust, dann frage ich mich, was machen wir hier eigentlich? Auch wenn der Betrieb der Softwareabteilung, der Entwicklungsabteilung nicht vertraut, dann muss ich zugeben, vielleicht sollte man ein Bierchen trinken gehen oder einen Kaffee oder was weiß ich nicht. Aber das ist für mich immer so schwer verständlich, weil du hast ja Monitoring System und wenn was schief geht, dann hast du Achtung, wir entfernen uns. Kommt irgendwas nach der Champions League, Weltmeister vielleicht Weltmeisterschaft, dann nehmen wir mal automatisierte Deployments als Champions league und dann geht was schief und dann Achtung, dann hast du einen Rollback und das ist dann schon, wenn der auch funktioniert, kommen wir gleich gleich noch zu. Das ist dann vielleicht so ein bisschen die die Weltmeisterschaft. Also für mich ist manuelles Deployment eigentlich nur jemand muss aktiv Zeit aufwenden, jemand muss verfügbar sein, jemand muss da aktiv Arbeit reinstecken.

Andy Grunwald (00:08:18 - 00:08:27)

Jetzt kommst du mir mit einem automatischen Deployment und Monitoring. Das heißt, ich brauche ein gutes Monitoring, ich brauche ein gutes Testing und ich brauche automatisiertes Deployment.

Wolfi Gassler (00:08:27 - 00:08:31)

Testing hast du reingebracht. Ich bin so der YOLO Typ, aber.

Andy Grunwald (00:08:31 - 00:08:40)

Ja, aber dann musst du ja auch warten, wenn du der YOLO Typ bist, dann wartest du, bis das automatische Deployment durch ist und du dann eine Meldung bekommst vom Monitoring System, um möglichst schnell zu reagieren.

Wolfi Gassler (00:08:40 - 00:10:29)

Okay, und Wieso muss ich dann warten? Weil ich kann doch mergen, dann laufen vielleicht Tests oder halt auch nicht. Das überlasse ich den Hörerinnen und Hörerinnen als Übungsaufgabe zweitausendein und dann entwickle ich einfach weiter mit dem nächsten Bug. Und wenn mein Handy schält, mein Monitoring System beantwortet mir dann hey Andi, da ist was schief, dann reagiere ich. Aber das tue ich auch bei einem Incident bei einem Ausfall. Aber ganz allgemein für mich sind manuelle Deployments ein Anti Pattern. Ich hatte ja gerade schon erwähnt, die konsumieren Zeit von jemandem, also jemand muss verfügbar sein. Die viel größere Problematik ist aber meines Erachtens nach, dass manuelle Deployments dann irgendwie das manuelle Ausführen von Befehlen oder von ganz speziellen Operationen auch zu Inkonsistenzen führen kann. Da kopiert man mal einen falschen Befehl, man vertippt sich mal bei einem Befehl und drückt Enter und dann hat man irgendwas gelöscht, was nicht mehr gelöscht werden soll. Und wenn das eine Person ganz oft macht, dann klassifiziert diese Person das so vielleicht für sich selbst als dumme Arbeit und agiert so ein bisschen als Autopilot. Und das ist immer ganz gefährlich, denn wenn jemand was auf etwas auf Autopilot macht, dann wird es gefährlich, weil man das vielleicht nicht mehr ernst nimmt oder nicht mehr mit dieser gewissen Aufmerksamkeit durchführt. Ich meine, das ist ähnlich. Ich hatte mal einen Sportunfall, ich bin mal Wakesgate gefahren, sehr, sehr viel und bin dann über eine Rampe immer, immer und immer und immer und immer wieder. Es war drin, kann man so sagen. Ich habe das ganz oft gemacht und irgendwann habe ich es nicht mehr so ernst genommen. Baff, schiefgegangen, Unfall, zwei Monate krankenhaus. Also das, das [sos/eos], die Analogie zum Sport ist jetzt vielleicht ein bisschen hergeholt, aber wenn du die Sache, obwohl du die schon 1 Million mal gemacht hast, nicht ernst nimmst und nicht fokussiert bist, dann treten auch Fehler beim Deployment auf. Und natürlich dann auch mit einer Live Infrastruktur und je, ich weiß ja nicht, wie viel Geld dein Unternehmen macht, aber das geht dann wirklich auch rechts Geld.

Andy Grunwald (00:10:29 - 00:10:51)

Ja, ich glaube, das ist ja common knowledge. Also wenn du eine Routine reinbringst, dann passieren die Fehler. Das ist ja überall so. Also klassisch mit Unfällen ist es so, aber es ist eigentlich in jedem Bereich im Leben so. Und beim Deployment ist es genau dasselbe. Und es kostet noch viel Zeit. Gebe dir vollkommen recht. Jetzt hast du am Anfang schon Rollbacks erwähnt. Was ist das Problem mit Rollbacks? Rollbacks sind ja gut.

Wolfi Gassler (00:10:52 - 00:11:35)

Rollbacks sowie die Sushi Rolle. Nee, Rollbacks, ja, jeder träumt davon. Wir sollten mal einen haben. Das Problem ist, wie oft testest du den denn? Denn die Software wird ja weiterentwickelt. Zweitausendein. Jeder kümmert sich halt nur darum. Den neuen Teil der Software muss ja mit deployed werden. Dann bauen wir das noch mal kurz in den Deployment Prozess mit ein. Und meine Frage wä wann hast du das letzte mal dein Rollback getestet? Denn Software rostet, du arbeitest ja vielleicht an einem Formel Wagen und versuchst ja während des Rennen die Reifen zu wechseln, denn meines Erachtens nach sollte auch eine Rollback Logik regelmäßig getestet werden, denn in welchem Zustand ist dein System, wenn du den Rollback triggerst und der Rollback schlägt fehl? Ich würde sagen, nobody knows.

Andy Grunwald (00:11:36 - 00:12:04)

Bei Rollback muss ich ja immer als Datenbänkler vor allem die Datenbanken einwerfen. Das ist ja so das schwierigste eigentlich an Rollbacks, weil das docker Image kannst du ja schnell mal zurückdrehen auf die Vorversion und einfach deployen, aber wenn da drinnen schon eine Migration gelaufen ist und deine Datenbank upgedatet hat, kann das natürlich unter Umständen schon zu großen Problemen führen. Also auch Rollback ist zweitausendein in der heutigen Zeit, wo man eigentlich auf Docker und Container und sonstige Dinge setzt, nicht unbedingt das leichteste. Also das muss man schon auch immer im Kopf haben.

Wolfi Gassler (00:12:05 - 00:12:31)

Und Naja, also Datenbankmigrationen sind ja in der Zwischenzeit ein gelöstes Problem. Das bedeutet, willst du ein Feld löschen, dann wird das Feld erst renamed und irgendwie zwei, drei Releases später erst wieder gelöscht. Also da gibt es ja Methoden, wie du zwar dann, die dann mehr Zeit kosten, die das ganze aber sicherer machen, weil was du ja da machst, zweitausendein, du veränderst ja ein stateful System und immer wenn du state hast, dann hast du halt echt eine Herausforderung am beIN.

Andy Grunwald (00:12:32 - 00:12:40)

Ja, Migrationen sind halt sehr oft nach vorwärts gerichtet und selten zurück. Also ganz oft gibt es gar keinen Rollback für eine Datenbank Migration.

Wolfi Gassler (00:12:40 - 00:12:42)

Bei welcher Operation gibt es denn dann kein Rollback?

Andy Grunwald (00:12:42 - 00:13:13)

Ja, es geht eher darum, ob du ein Rollback implementierst oder das Framework ist automatisch implementiert. Aber es kann natürlich schon sein, dass wenn du wirklich irgendwelche Werte in der Datenbank änderst, bei einer Migration zweitausendein und zurückrollst, dass die alte Software Version nicht mehr mit den neuen Werten umgehen kann in der Datenbank und da müsstest du alle Werte wieder irgendwie zurückschreiben, falls es überhaupt geht. Also es ist ja nicht nur immer füge ein Feld hinzu, es kann ja auch was sein, du änderst gewisse semantische Informationen oder Definitionen in der Datenbank.

Wolfi Gassler (00:13:13 - 00:13:48)

Verstehe ich. Nach meiner Erfahrung gibt es aber für alle Datenbank Migrationen ein mehrschrittiges System bzw. Eine Lösung, wie du sowas dann auch umgehen kannst. Beispiel, du möchtest die Daten, die du in Tabelle A geschrieben hast, jetzt in einem neuen Format schreiben, dann leg Tabelle B an, schreib für eine gewisse Zeit die Daten in Tabelle A und in B in jeweils zwei verschiedenen Formaten und irgendwann, wenn du sicher bist, dass alles funktioniert, vielleicht über drei, vier Deployments, dann nimmst du Tabelle a raus, renamest die, entfernst die und so weiter. Das dauert dann auch alles Zeit, aber so hast du halt rollbackfähige Datenbankmigration meines Erachtens.

Andy Grunwald (00:13:48 - 00:14:58)

Und ich würde mal sagen, das findest du in einem einstelligen Ÿousand Prozentwert von Softwareprojekten, diese Art von Migration und Datenbank Handling, weil ganz oft ist es einfach ein easy Statement, was aufgerufen wird, falls es überhaupt in der Migration innerhalb von der Version stattfindet und nicht mit einem Systemadministrator, der sich auf der Datenbank einloggt, irgendwie ein Feld hinzufügt oder ändert oder irgendwas und gleichzeitig noch die neue Version deployed oder so, was in der Realität immer vorkommt. Und da muss ich schon auch sagen, es ist gar nicht so leicht, weil Ÿousand so komplexe Datenbank Migrationen zu machen, da musst du schon viel verstehen von der Datenbank und da hast du dann aber vielleicht auch eigene Leute, vor allem wenn du in so einem Scale arbeitest, aber ein kleines Team, was natürlich nur irgendwie dann Object Relation Mapper drinnen hat, ist es natürlich vielleicht schon dann schwierig. Also das könnte ich noch am ehesten verstehen, aber auch da kann man ja sagen, okay, ich bin mir ja bewusst, dass jetzt diese Version vielleicht schwieriger ist, ein Rollback zu machen, zweitausendein und dann behandle ich das noch mal anders als mit dem Standard Fall, wo man einfach was rauspushen kann und das wird einfach deployed. Also es passiert ja ganz, ganz selten, dass du so einen harten Change in der Datenbank auch hast.

Wolfi Gassler (00:14:58 - 00:15:05)

Ich hatte schon etliche Fälle, wo man mal eben schnell eine Query ausführt, Daten ändert und dann der where Selector falsch war.

Andy Grunwald (00:15:05 - 00:15:11)

Ja, das ist eine andere Sache, dass du die auf Datenbankserver gar nie einloggen solltest. Ja, das ist ja noch mal eine andere Sache.

Wolfi Gassler (00:15:11 - 00:15:20)

Das war damals zu einer Zeit, da hat der Entwickler das Query geschrieben, an den Betrieb geschmissen, der Betrieb hat es ausgeführt, ja, und dann später festgestellt, oh.

Andy Grunwald (00:15:20 - 00:15:29)

Ja, was glaubst du, wie oft mir das schon passiert ist in meinem Leben? Schnell mal einloggen, where Statement hin und her, select, update, delete irgendwo und dann. Klassiker.

Wolfi Gassler (00:15:29 - 00:15:35)

Genau. Und dann hatten wir auch schon so Aktionen, oh, wir haben die Daten dann wieder aus einem Backup rausgekramt und solche Geschichten.

Andy Grunwald (00:15:35 - 00:15:41)

Und du musst es positiv sehen, weil du kannst dann deinen Backup Prozess mal testen, wird eh viel zu selten gemacht.

Wolfi Gassler (00:15:41 - 00:15:45)

Ist eigentlich ja dein Restore Prozess. Der Backup Prozess funktioniert wahrscheinlich überhaupt der Rest.

Andy Grunwald (00:15:45 - 00:15:47)

Genau, der Restart Ÿousand.

Wolfi Gassler (00:15:47 - 00:17:00)

Aber genau da ist halt die Krux und da habe ich halt wirklich gelernt, dass es mir völlig egal, wie schnell auch nur das where Statement gehen würde und nur die Query schreiben. Ich gehe leider den extra Weg, denn das Restore vom Backup und die entsprechenden Datensätze rauszuholen, kostet mich in der Regel mehr Zeit. Aber wenn wir unbedingt schon bei Datenbank Upgrade sind oder Datenbank Deployments, dann kommt natürlich noch eine andere Herausforderung dazu. Und zwar sind das in place Schema Änderungen. Denn diverse Schemaänderungen sind einfach Blocking. Und wenn du die Tabelle erweiterst oder einen Datentyp von einem Feld änderst, dann kann das einfach sein, dass alle Records der Tabelle je nach Änderung natürlich durchgegangen werden müssen und je nach Größe der Tabelle, wenn da mehrere Millionen Einträge sind, dann können für die Zeit keine Inserts gemacht werden oder Updates. Also schreib und wenn das vielleicht sogar ein lesebeschränkter Zugriff ist, dann könnte es auch sein, dass auch Lesezugriffe blockiert werden. Und das ist natürlich dann superkritisch, weil eigentlich dann kein Zugriff für die Länge der Operation auf die Tabelle möglich ist. Und wenn das dann eine Session Tabelle ist, bedeutet das z.B. niemand kann sich mehr einloggen oder ähnliches oder E Commerce, niemand kann mir das verstehen. Ist natürlich auch eine harte Nr. Dann da muss man auch ein bisschen aufpassen.

Andy Grunwald (00:17:00 - 00:17:54)

Es gibt auch schon relativ lange dieses Problem und es gibt sehr viele Tools, zumindest im MySQL Bereich, die probieren, dieses Problem zu lösen. Und da habe ich mir schon öfters gedacht, das kann es doch nicht sein. Irgendwann macht die Datenbank das selbst, dass die Datenbank da Möglichkeiten anbietet. Die neuen MySQL Versionen haben da teilweise Möglichkeiten, dass du angeben kannst, wie Updates vom Schema gemacht werden. Und da gibt es ein paar unterschiedliche Herangehensweisen, damit du eben weniger blocking bist. Aber es ist seit, ich glaube seit 20 Jahren ist es jetzt ein Thema und es kommt jedes Jahr ein neues Tool heraus oder eine neue Version zumindest von von von Online Schemas. Changing Tools ist mir ein Rätsel, aber scheint einfach zu nischig noch zu sein, dass die Datenbank sich selber darum kümmert. Aber wenn wir bei diesen ganzen Anti Patterns jetzt sind, was gibt es sonst für Anti Patterns im Deployment, die du als alter Deployment Freak und SRE so gesehen hast bisher in deinem Leben?

Wolfi Gassler (00:17:54 - 00:19:42)

Ich hätte jetzt eigentlich noch drei Anti Patterns zur Verfügung, über zwei gehe ich mal relativ schnell drüber. Und zwar der erste ist ein extrem komplizierter Diplomat Prozess. Wir kennen das vielleicht noch von früher, diese klassischen PHP Applikationen, ein Zip Archiv schiebt man hoch, entpackt, schiebt man in den richtigen Folder und Abfahrt. Man muss ja den Apache zwei Web Server neu starten. Aber es gibt auch Deployment Prozesse, wo du ganze Maschinen austauscht, aka immutable infrastructure oder was auch immer während des Deployment Prozess gemacht werden muss. Dann müssen Third Party Systeme Bescheid gegeben werden, dass dann Deployment losgegangen ist und so weiter. Und wenn der Deployment Prozess einfach so unglaublich komplex ist, dass nur bestimmte Personen oder bestimmte Teams ihn verstehen und auch durchführen bzw. Ändern können oder im Fehlerfall reagieren können, dann hast du dir natürlich ein Bass Factor geschaffen und deine Reaktionsgeschwindigkeit auf Probleme ist natürlich echt minimiert. Denn ich hatte gerade nach dem Zustand einer Applikation gefragt, wenn Rollback schief geht, aber was ist denn, wenn ein Deployment Prozess schief geht? Das bedeutet zweitausendein er hat 50 % ausgeführt, dann hast du ebenfalls so ein inkonsistentes System. Also halt die ganze Sache so einfach wie möglich. Jetzt hatten wir vorhin schon gesagt, Cloud Native ist die Lösung, ist es natürlich nicht. Was man aber leider schon sagen muss, dass jegliche Art von Container, sei es System, DNS One Container, Docker Container oder von mir aus auch LXC Container oder von mir aus auch virtuelle Maschinen, weil im Endeffekt sind virtuelle Maschinen ja auch einfach nur riesige isolierte Environments, die muss man schon leider sagen, die machen die ganze Sache einfach einfach. Denn wenn du nämlich mal so einen Container oder eine VM als, ich sag mal SIP Archiv oder RAR Archiv siehst, dann ist das ein Paket, was du irgendwo hinschmeißt und dann machst du damit. Deswegen die ganze Sache einfach halten und alles rausnehmen, was man wirklich nicht braucht, ist glaube ich eine super Sache.

Andy Grunwald (00:19:42 - 00:20:39)

Es ist auch das große Problem, wenn man jetzt unter Anführungszeichen manuelle oder wie du es nennst automatisierte, aber mit einem Skript automatisierte Deployment Prozesse hat, die vielleicht gar nicht so kompliziert sind, aber ich bin der einzige Developer oder war mal der einzige Developer oder zu zweit und wir warten dieses Ding und das ist ein irgendein Skript, das könnte jemand anderer auch aufrufen. Aber der Klassiker und das passiert mir auch in kleineren Teams ganz oft, dir fehlen dann irgendwelche Libraries auf deinem lokalen Rechner, irgendwelche Linux Tools, die die anderen halt klassisch installiert haben auf ihren Linux Maschinen. Dir fehlen diese Teile, dann fangst du so Debuggen an, bis du diesen Deployment Prozess mal bei dir irgendwie aufsetzen kannst. Und wenn du es nicht komplett durchautomatisiert hast auf irgendeinem Server, dann hast du da das richtige Environment und bist natürlich auch viel, viel schneller, wenn jetzt deine zwei Kolleginnen da auf Urlaub sind, die das warten und dann kannst du natürlich auch dementsprechend schneller deployen oder es geht überhaupt komplett automatisch.

Wolfi Gassler (00:20:40 - 00:21:29)

Wo du gerade Libraries gesagt hast, eine Sache, die ich mir inzwischen angewöhnt habe, weil da bin ich auch schon etliche Male drüber gestolpert, sich auf externe Tools bezieht. Keine Ahnung, während des Deployment Prozess kompilierst du irgendwann mal deine Anwendung oder zippen, ja, oder zippst das, was ich immer mache, bevor ich den Befehl ausführe. Das bedeutet, wenn ich jetzt eine Go Applikation kompiliere oder was zusammen zippe, dann mache ich oft Go Version oder zip Version, dass ich mir von dem Tool die Version im Deployment Prozess Logs einmal ausgeben lasse, damit ich wirklich später beim Debuggen sehe, welche Version habe ich denn da? Denn auch Java. Was ist, wenn ich die falsche Java Version habe beim Deployment Prozess, aber lokal mit einer höheren arbeite? Badum, ich nutze ein neues Feature. Badum, warum crasht das live? So der Klassiker.

Andy Grunwald (00:21:29 - 00:22:02)

Was natürlich auch geht, ist, dass du wirklich deinen Deployment Prozess innerhalb von einem Docker Container, den du dir gepinnt hast, mit den ganzen Versionen natürlich, dass du den verwendest und dort drinnen dann das ganze bauen, sippen, alles was du so machst, machst und dann das irgendwo auf den Server schiebstausend. Das kann dir natürlich auch wahnsinnig helfen und hat mir würde sagen, in letzter Zeit schon viele Probleme vom Hals gehalten mit diesen ganzen externen Packages und Tools. Und dann bist du auf dem Mac und hast wieder ein Problem und dann bist du wieder andere Linux Version und also das kennt man ja wirklich dieses Problem.

Wolfi Gassler (00:22:02 - 00:22:31)

Wir hatten ja gerade von Champions League Weltmeisterschaft gesprochen. Das, was du da gerade ansprichst, ist für mich höher als Weltmeisterschaft, wenn man das gleiche, was man zum Deployment Artefakt bauen nutzt und zum Deployment halt jeden Tag in der Entwicklungsumgebung hat. Also wenn man das gleiche Setup hat. Du sagtest gerade Docker Container, wie es auch immer aussieht, weiß ich nicht, kann auch so eine so ein Cloud Development Environment sein. Viele Firmen machen ja irgendwelche cloud Maschinen und entwickeln sich da, damit die z.B. ein iPad entwickeln können oder ähnliches.

Andy Grunwald (00:22:32 - 00:22:43)

Es liegt ja auch alles sehr nahe zusammen. Wenn du ein Dev Environment hast, dann ist das Prod Environment ja meistens ähnlich. Wenn du das über Container machst, kannst du da ja auch die Dinge möglichst synchron halten. Also es hilft dir ja auch alles.

Wolfi Gassler (00:22:43 - 00:24:25)

Ÿousand genau. Also das ist natürlich ein Traum. Das zweite Anti Pattern sind Big Bang Deployments. Und das ist fast egal, ob wir manuell oder automatisch deployen. Es kommt halt immer wieder vor, dass wenn sehr, sehr viele Änderungen aka Pull Request, aka Comics auf einen Schlag online gehen, also wenn das Change Set zur vorherigen Version einfach riesig ist, denn ich habe mich schon in so vielen Debugging Sessions wiedergefunden, wo ich die Comets zwischen der neu deployed Version und der alten Version auseinandernehme, nur um zu verstehen, welcher Change jetzt genau das Problem verursacht hat. Sei es eine Performance Regression, sei es ein bug oder ähnliches. Bei der hohen Anzahl an Änderungen verlierst du einfach ganz klar den Überblick. Und dann kommt es nämlich ganz schnell angenommen du hast was 100 Changes sind online gegangen auf einmal, weil du letzte Woche nicht deployed hast oder zwei Wochen nicht, ist ja völlig egal. Irgendwas funktioniert nicht oder verhält sich komisch. Auch gut, keiner weiß wirklich, was komisch ist, aber es verhält sich komisch. Und während der Zeit, während da ein Team debuggt, gehen ja neue Changes online, also oder nicht online, werden aber in den Haupt Entwicklungsbranche gemerged. Vielleicht hast du eine tolle Tagging Strategie, vielleicht tagst du jedes Deployment und willst dann später von deinem Tag noch mal wegbranchen, um den Bugfix einzuspielen. Ja, gibt es alles, verstehe ich, ist aber auch kompliziert. Und dann könnte natürlich das Thema von Code Mercuries wieder aufkommen. Hatten wir mal in Episode 109 besprochen, warum manchmal dein Code eine Pause braucht, besonders solche Situationen. Ist das, ist das vielleicht denkenswert? Oh, wir haben eine kaputte Live Instanz, machen wir eben mal eine Pause. Ab wann würdest du denn sagen, ist ein Deployment zu groß? Weil zu groß ist ja auch echt subjektiv.

Andy Grunwald (00:24:25 - 00:25:52)

Ich glaube ja, dass das auch gar kein Anti Pattern ist zweitausendein ein Big Bang Deployment, sondern es eigentlich ein Symptom ist von ganz vielen anderen Dingen, die nicht korrekt sind oder nicht gut laufen. Weil der Klassiker, warum du ja Big Bang Deployments hast, ist, dass du eben nicht schnell deployen kannst, dass du nicht schnellen Feedback Cycle hast, dass du dir nicht sicher bist, kann ich das auf produktiv überhaupt ausrollen? Das heißt, deine Tests sind vielleicht nicht gut oder du hast keine sauberen Code Reviews davor oder die Code Reviews sind zu langsam, dadurch hast du dann Big Bang Deployments. Also ich glaube, das sind ganz viele Schritte davor, die dann zum Big Bang Deployment führen. Und die musst du natürlich zu Beginn fixen, damit du überhaupt deine Zyklen nach unten bekommst, damit du öfters deployen kannst. Und das Beste ist natürlich, dass du jede Änderung möglichst schnell deployen kannst. Also wirklich jeden PR oder jedes Commit quasi. Aber da muss natürlich der gesamte Rest stimmen. Es muss schnelles Deployment sein, es muss automatisiertes Deployment sein, es muss gutes Monitoring sein, es muss getestet sein in deinem Deployment Prozess im Vorhinein schon. Also diese Dinge musst du alle abhaken können, weil sonst hast du ja kein gutes das Gefühl, wenn du tagtäglich da irgendwelche Deployments nach draußen schießt. Und dann führt es dazu, dass du dann halt Big Bang Deployments hast, weil du sagst, ja, wir müssen das ja auch alles testen sauber und wir haben vielleicht QA Leute oder die eigenen Devs. Das wird dann natürlich nicht jeden Tag gemacht, sondern nur dann alle zwei Wochen und dann hast du dieses Problem.

Wolfi Gassler (00:25:52 - 00:25:56)

Ist eine faire Challenge, würde ich auch so annehmen. Danke dafür.

Andy Grunwald (00:25:56 - 00:25:59)

Ja, ist gar keine Challenge, ist einfach Umdefinition.

Wolfi Gassler (00:25:59 - 00:26:46)

Weiß ich nicht. Ich habe auch vor kurzem einen Vortrag gesehen, wo jemand von der deutschen Börse über die Infrastruktur ein bisschen erzählt hat. Und die deployen z.B. immer nur außerhalb der Handelsspanne. Also von Montag bis Freitag deployen die eigentlich nicht, weil die deployen halt irgendwie Freitag nach Börsenschluss und fixen oder deployen dann auch Samstag und so weiter. Da kann es natürlich auch sein, dass während der Woche ganz viele Changes reingehen. Offen gesprochen, deren Testsystem ist wohl sehr gut, sagten sie. Und da kommt es natürlich genau zu dem, was du gesagt hast, Ÿousand. Ja, ich weiß auch z.B. dass die Sparkassen Informatik, Finanzinformatik heißt es ebenfalls, nur an ganz speziellen Tagen eine neue Software Version von irgendwelchen Finanzsystemen ausrollt. Und da geht es jetzt nicht um die Software von irgendwelchen Geldautomaten, sondern halt von den Office Leuten.

Andy Grunwald (00:26:46 - 00:27:53)

Ja, das ist natürlich verständlich. Wenn du den Luxus hast, dann kannst du das natürlich machen, in den Fenstern zu deployen, wenn weniger los ist oder wenn die Software gar nicht genutzt wird, wie bei der Börse, ist eh klar, wenn du diese Möglichkeit hast, dass du das machst. Wobei natürlich das auch dann wieder bedeutet, und das hatten wir in der Codefreeze Episode auch, dass du dann halt erst merkst, wenn wirklich ein großes Problem ist, das merkst du dann halt erst Montag, Dienstag, bist vielleicht wieder aus dem Kontext draußen, die Leute sind vielleicht mittlerweile in den Urlaub gegangen, die das am Samstag deployed haben. Also du hast dann da schon auch Schwierigkeiten und es gibt da ja auch dieses klassische Beispiel in der Geschichte jetzt, kannst es leider nicht mehr komplett rekonstruieren, aber es war auch Finanzgeschäfte, Börsen, wo das eben genau das Problem war, das so selten deployed wurde und dann der Feedback Cycle so kurz war, dass die Leute das nicht mitbekommen haben mit den Problemen. Und da sind wirklich Millionen oder hunderte Millionen von von Dollar damals flöten gegangen durch dieses Problem. Und das ist eigentlich zurückzuführen auf genau dieses Problem, dass man eben so selten die hat. In diesem Fall. Kannst gerne nochmal raussuchen.

Wolfi Gassler (00:27:53 - 00:28:02)

Ich hoffe doch mal für uns alle, dass die deutsche Börse, wenn die am Samstag deployed, Fehler nicht erst am Dienstag feststellt. Das hoffe ich wirklich für uns alle.

Andy Grunwald (00:28:02 - 00:28:06)

Hoffen wir mal, aber in der Realität bin mir nicht so sicher.

Wolfi Gassler (00:28:06 - 00:29:42)

Aber das, was du gerade angesprochen hast, schnelles Feedback, beziehungsweise den Feedback Cycle, aber das, was du gerade angesprochen hast mit dem schnellen Feedback Cycle, das ist ja essentiell wichtig für mich zumindest in meinem Entwickleralltag oder auch als Engineering Manager, dass mein Team einen schnellen Feedback Cycle hat. Eine schnelle Rückmeldung von deiner Arbeit ist für mich key. Du musst das so sehen, du fixt einen Bug und wenn der erst in zwei Wochen online geht und der Bug ist nicht ganz gefixt, weil der z.B. auch bei einem Code Review übersehen wurde und du hast einen Edge Case vergessen und der tritt in Produktion auf, nach zwei Wochen hast du keine Ahnung mehr, wie der Code aussieht etc. Und wenn du aber heute den Bug fixt, das Deployment morgen online geht, du hittest den Edge Case in Produktion, dann sagt die Entwicklerin, ah ja, Moment, stopp, ich weiß genau wo es ist, ich gehe mal ganz kurz rein, fix das, mache einen neuen Pull Request auf einen neuen Code Review und dann ist der Bug relativ schnell gefixt, weil du den Kontext noch hast, weil der Feedback Cycle so kurz ist oder so schnell ist. Wenn du jetzt aber alle Woche deploys oder alle zwei Wochen, ich weiß ja noch niemals mehr, was ich vorgestern gegessen habe, dann muss der Edge Case wieder dokumentiert werden, zweitausendein, dann wird ein Jira Ticket erstellt, dann wird wieder im Backlog Planning besprochen oder Backlog Grooming und dem nächsten Scrum Cycle wieder gefixt, aber da muss sich jemand wieder einarbeiten. Die sogenannte Rüstzeit, wie man das in der Wirtschaftsinformatik nennt, also die die Vorbereitung, um sich für die Arbeit da einzuarbeiten, den Kontext zu holen und so weiter, ist halt enorm hoch, wenn du halt ein langsames Deployment hast, weil der Feedback Cycle nicht gegeben ist. Und das ist natürlich enormst teuer.

Andy Grunwald (00:29:42 - 00:30:41)

Und das Feedback kann natürlich auch beschleunigt werden, wenn du saubere Tests hast, die du ja dann eher brauchst, wenn du ein automatisches Deployment machst. Also du wirst dazu gezwungen, eigentlich auch gewisse Tests mit einzubauen. Und ihr habt es auch noch mal jetzt nachgeschaut. Also was ich da erwähnt habe, das war 2012 so ein Softwarefehler bei Night Capital und die haben $440 Millionen verloren innerhalb einer Nacht, weil ihr System dann angefangen hat, irgendwas wild zu kaufen. Und schlussendlich hat sich herausgestellt, das war einfach auch ein Problem mit manuellem Deployment, was einfach deployed wurde. Und wenn die nur rudimentäre Tests gehabt hätten und ein automatisches Deployment, hätte man das mit ziemlicher Sicherheit verhindern können. Also es muss nicht automatisch sein, dass das unsicherer wird dadurch, weil du ja eben dein gesamtes System auch festigst und härtest, weil du zusätzliche Tests einführst, vielleicht dein Monitoring verbesserst, weil du darüber nachdenkst und weil du dann am Ende natürlich Zeit sparst und auch weniger Probleme hast, ist es definitiv ein Plus.

Wolfi Gassler (00:30:41 - 00:33:37)

Ja, eins müssen wir mal festhalten, ob du jetzt manuell deploys, automatisch deployst, alle 5 Minuten deploys oder einmal im Monat, das schützt sich vor bugs nicht. Wir verändern Software, wir sind Menschen, wir machen Fehler. Was aber und auch bei, auch wenn du ein gutes Testsystem hast, kannst du Edge Cases, Randtests, jeder kennt das Testen mit minus eins, null und eins dieseousand möglichen Ränder von deiner Logik, die die sind halt einfach da und die werden passieren. Was aber auch, um jetzt ein positives Beispiel zu nennen, vor kurzem habe ich einen LinkedIn Post von linear, das ist so eine Projektmanagement Software auf LinkedIn gesehen und die haben einen Screenshot geschickt und zwar hat ein Kunde über Support Ticket ein Bug gemeldet und innerhalb von 28 Minuten hatte der Engineer zweitausendein einen Bugfix online. Keine halbe H. Das natürlich. Ich kann jetzt nicht sagen, was das für eine Applikation war, ob das jetzt eine React App war oder irgendeine Backend APR, das weiß ich gerade alles nicht. Wie dem auch sei, wir haben bestimmt schon mal alle den Spruch gehört, das dauert ja nur 5 Minuten. Da kommt immer als Gegenwehr, das sage ich auch, nichts dauert in der Softwareentwicklung 5 Minuten. Aber so einen Fall zu sehen, dass man einen Bug reinkriegt von einem Kunden, der innerhalb von 28 Minuten gefixt werden kann und Deport werden kann, ist natürlich auch schön. Und da muss man ganz ehrlich sagen, das ist nur möglich dank des schnellen Feedback Cycles und dank eines schnellen Deployment Prozesses. Aber ich hatte vorhin von drei Anti Patterns gesprochen. Das letzte, da kommen die ganzen Microservice Helden gerade mal zur Sprache, ist, das ist der Deployment Monolith. Stell dir vor, du hast verschiedene Komponenten in deinem System, von mir aus verschiedene Applikationen und die müssen alle auf einen Schlag deployed werden, weil die sonst nicht kompatibel sind. Das bedeutet natürlich auch, dass gegebenenfalls Komponenten erneut deployed werden, die gar nicht geändert wurden. Ich rede jetzt extra von deployment Monolith, das heißt nicht unbedingt, dass das nur auf Microservices zugeschnitten ist, aber das kennt man halt. Man hat verschiedene Systeme, die miteinander zusammenspielen und die müssen alle als ein Bunch deployed. Das ist natürlich dann die Frage, warum hat man denn die verschiedenen Systeme? Natürlich hat man dann irgendwie Single Responsibility, dass ein System nur eine Aufgabe hat oder vielleicht hat man verschiedene Systeme, weil die von verschiedenen Teams betreut werden oder oder. Punkt ist aber, die komplette Flexibilität geht ja dadurch flöten, wenn du das alles alleine zweitausendein deployen musst. Denn das bedeutet, alles muss deploybar sein, alles muss grün sein, alles muss stabil sein, dass du deployen kannst. Und was ist, wenn jetzt ein Team gerade irgendwelche Fehler hat in ihrem Hauptentwicklungsstrang? Dann sind alle anderen Teams oder alle anderen Applikationen halt einfach geblockt. Und das ist natürlich dann schon ein Riesenproblem, weil die ganze Architektur dann eine zu enge Kopplung hat. Kann man natürlich API Contracts und Co. Vielleicht ein bisschen lösen, aber du blockst halt einfach die Deployments. Vielleicht sind die Deployments sogar langsamer bzw. Könnten schneller sein. Ich hatte gerade gesagt, gegebenenfalls werden Komponenten deployed, die gar nicht geändert wurden. Also das ist vielleicht noch ein weiterer Anti Pattern, was ich sagen würde, Deployment Monolith.

Andy Grunwald (00:33:37 - 00:34:11)

So, jetzt haben wir schon eine Zeit über Deployments gesprochen und ich kann es fast nicht glauben, aber wir haben bisher, glaube ich, das Wort continuous deployment noch gar nicht erwähnt. Was ja bei dir echt normalerweise kommen ja, wenn man über Berge mit dir spricht, kommt continuous deployment im zweiten Satz vor. Finde ich also sehr gut, können wir auch gerne dabei belassen. Aber wenn du jetzt schon die ganzen Anti patterns erwähnt hast, wie sieht denn ein guter Deployment Prozess jetzt deiner Meinung nach aus? Was sind denn die Anforderungen an den guten Deployment Prozess? Also wie kann man es besser machen, abgesehen jetzt von den Anti Patterns, die man natürlich nicht machen sollte.

Wolfi Gassler (00:34:11 - 00:35:33)

Ja, ich gehe da jetzt gar nicht so viel auf Technologie ein, denn meine Anforderungen an Diplom Prozess sind eigentlich relativ schmal. Ÿousand und zwar automatisiert. Das bedeutet, keine oder nur sehr wenige manuelle Schritte sind notwendig. Was meine ich damit? Wenn man jetzt gerade nicht seinen Main Branch deployed, vielleicht, dass man automatisch oder dass man manuell einen Tag erstellt, einen git Tag und diesen pusht und wenn ein neues Tag da ist, dass man das dann deployed. Ja, da ist die Tag Erstellung natürlich auch schon eine Art manueller Schritt, ein manueller Trigger. Das finde ich auch noch völlig okay, weil man dann den Zeitpunkt des Deployments vielleicht noch im unter Kontrolle hat. Dann, dass man den Deployment Prozess selbst monitort, dass man ein Monitoring System hat, was dann auch ein Exit Code beobachtet oder wie man auch immer seinen Deployment Prozess monitort. Auf jeden Fall, wenn da ein Fehler ist, schlag mal Alarm. Und Achtung, das Monitoring System sollte sich nur melden, wenn es einen Fehler gibt. Dabei handele ich mein Deployment und auch meine Infrastruktur sowie ein Linux System. No news are good news, vielleicht hast du es schon mal gesehen, wenn du einen Linux Befehl startest und da kommt keine Ausgabe, dann ist das in der Regel erfolgreich. Und wenn du einen Fehlerfall hast, dann kommt in der Regel eine Ausgabe. Es sei denn, du hast einen Prozess wie Cut oder less oder ähnliches, da distanzieren wir uns jetzt mal von. Aber Linux Systeme haben eine Regel no news are good news und news ist dann der Ausgabe. Und deswegen, das ist so meine Anforderungen an Deployment Prozesse.

Andy Grunwald (00:35:34 - 00:36:25)

Vielleicht noch als kleine side Note. Das Problem ist ja auch, wenn man sich immer die Information senden lasst von dem Deployment Prozess, dann kommt die sogenannte Change Blindness ins Spiel, dass wenn du jedes Mal eine E Mail bekommst, dann bekommst du gar nicht mehr so richtig mit, ob sich da was geändert hat, ob der fehlgeschlagen ist, weil du bekommst ja ständig irgendwelche E Mails. Das ist ja auch das Problem, wenn du bei Monitoring ständig E Mails bekommst, weil dann fällt dir gar nicht mehr auf, ob da in den 200 E Mails irgendwo ein Problem drinnen war. Das andere Problem ist natürlich, wenn du nur ÿousand ein E Mail bekommst oder eine Information, wenn was schief gelaufen ist. Es könnte natürlich auch theoretisch sein, dass irgendwas komplett crasht und du dadurch dann keine Info bekommst, aber das ist schon wirklich ein Edge Case, den man gerade beim Deployment wahrscheinlich weglassen kann, weil ja der Deployment Prozess auch überwacht wird von einem externen Tool und der sich dann melden würde im Normalfall, wenn da was nicht stimmt.

Wolfi Gassler (00:36:25 - 00:37:47)

Ja, diese e Mail, die immer versendet wird, es wurde eine neue Version deployed, die finde ich super und habe ich auch eine ganze Zeit lang gemacht und ja, ich stimme da 100 % zu, ich werde blind, weil die werden wahrscheinlich im E Mail Programm wegsortiert, wenn du sowas wie Inbox Zero oder ähnliches verfolgst oder du bist halt das andere Extrem, was ungelesene e mails hat, dann liest du die aber auch nicht. Somit ist das alles irrelevant. Was man aber schon empfehlen kann, ist, dass der Deployment Prozess irgendwie einen Record schreibt in eine Datenbank oder von mir aus auch nach Grafana schickt, womit du dann eine Annotation in Grafana machen kannst in deinen Monitoring Dashboards. Ich nehme jetzt einfach mal irgendwie Grafana, ist mir völlig egal, was ihr für ein Tool nutzt. Und dann siehst du nämlich, ah, der Graph ging, ging nach oben und da kannst du die Annotations anzeigen lassen und die Annotations sind dann in der Regel vertikale Striche, zu welchem Zeitpunkt ein Deployment stattgefunden hat. Und dann kannst du sagen, ah, dieser Anstieg des Graphens ist zurückzuführen auf dieses Deployment und da kann man da später reingucken. Also so eine gewisse Art von Tracking sollte schon da sein, aber von mir ist auch eine Flag Notification mit den Listen, alle Pull request, weil was auch immer super ist, nutze ich super oft bei uns in der Firma, wenn ich wissen will, wann ein Pull Request online ging, dann suche ich den oft in Slack, weil da gibt es eine Deployment Notification. Gibt es natürlich auch über Webhooks von Jira und so weiter und so fort. Ja, da gibt es ganz viele verschiedene Arten und Weisen und Systemen. Kannst auch Kommentare in Jira Ticket machen lassen und so weiter und so fort. Aber sowas würde ich dann halt schon in irgendeiner Art und Weise einstellen.

Andy Grunwald (00:37:47 - 00:38:39)

Es kann auch im Team ganz hilfreich sein oder ganz praktisch sein, wenn du einfach die Informationen an dein Team aussenden willst, hey, da wurde was deployed oder Ÿousand gerade wenn es jetzt nicht super ständig tagtäglich irgendwie stattfindet, dann ist es schon ganz cool, eine Message zu haben, weil die anderen Leute bekommen ja dann wahrscheinlich auch die Problemmeldung oder wenn es beim Monitoring irgendein Problem gibt und dann wissen die auch ah, okay, da wurde was kürzlich deployed oder so. Also das kann schon auch sehr praktisch sein. Andi ist ja so jemand, der über alle Commit Messages immer drüber geht bei uns im Slack. Ich ignoriere die immer, aber wenn ich irgendwas committe, kommt sofort eine Message von Andy. Moment, du hast da irgendwie ein Problem bei deinem Commit oder so. Also Andy hat es immer voll im Auge, aber ich kenne sehr viele, inklusive mich, die das gerne auch einfach ignorieren. Aber man hatte die Option, solange man das in einem Channel hat, wie weit man da reingeht und wie tief man das monitort.

Wolfi Gassler (00:38:39 - 00:38:50)

Das klingt jetzt so nach Micromanagement, aber bei diesem side Project Engineering kiosk muss ich weiß ja, mit wem ich arbeite und ich weiß ja, wie die Person Wolfgang arbeitet. Ja, deswegen. Und wir haben ja hier schon gesagt.

Andy Grunwald (00:38:50 - 00:38:53)

Also QA ist wichtig und Testing ist auch wichtig.

Wolfi Gassler (00:38:53 - 00:38:59)

Ja, wenn es nicht automatisiert geht, dann machen wir es halt manuell, aber der Deployment Prozess ist automatisiert. Aber nun gut, da haben wir auch.

Andy Grunwald (00:38:59 - 00:39:12)

Eine eigene Episode übrigens über unseren kompletten automatisierten Prozess in Episode 111 side Projects. Zwei Entwickler over engineeren einen Podcast. Wobei das jetzt nicht heißen soll, dass automatisierte Deployments over Engineering ist.

Wolfi Gassler (00:39:12 - 00:39:29)

Ich weiß nicht, warum du Over Engineering immer so als negativen Teil siehst, denn ich glaube, da kommt so ein bisschen eine österreichische Natur raus. In Deutschland sagt man ja, wenn man nicht meckert, ist das schon ein großes Lob. Ja, und du sagtest ja mal, Österreich ist immer Deutschland durch 10, also 1/10 von von Deutschland.

Andy Grunwald (00:39:29 - 00:39:31)

Vielleicht kommt auch eine Einwohnerzahl zumindest.

Wolfi Gassler (00:39:31 - 00:40:24)

Ja, hattest du nicht auch mal gesagt Bruttoinlandsprodukt und so weiter? Irgendwie gefühlt alle Metriken. Aber wie dem auch sei, vielleicht kommt da die eine Negativität her. Aber für mich als Wirtschaftsinformatiker muss ich, habe ich natürlich auch ein bisschen den Lehrauftrag, hier mal so ein bisschen Business Speak reinzubringen. Ein schneller Deployment Prozess reduziert nicht nur die Rüstzeit, wie wir gerade gesagt haben, zweitausendein, weil wir den kompletten Loop sparen. Es ist aber natürlich auch so, dass es die sogenannte Time to market reduziert, besonders wenn du in einem hochkompetitiven Umfeld in einer Branche unterwegs bist, dass du natürlich dann vielleicht auch hier und da einen Wettbewerb Vorteil hast, wenn du schneller schippen kannst. Falls sie also mal irgendwelche Argumente für eure Vorgesetzten brauchen. Time to market ist da der Begriff, den man Google sollte und von anderen Sachen wie Incident response und teure Fehler zweitausendein schnell beheben und feature Requests von Kunden mit Firmen Reputation, dass sie positiv werden kann und so weiter. Kennt ihr alles.

Andy Grunwald (00:40:24 - 00:40:34)

Also es geht alles schneller am Ende. Vor allem ist die Headline von von diesen ganzen Punkten. Aber gibt es auch Herausforderungen, wenn wir jetzt von von Deployment sprechen?

Wolfi Gassler (00:40:34 - 00:40:36)

Wo fange ich an?

Andy Grunwald (00:40:36 - 00:40:37)

Hast du schon mal am Anfang einfach.

Wolfi Gassler (00:40:37 - 00:40:40)

Mal Andi, hast du schon mal ein Pferd kotzen sehen?

Andy Grunwald (00:40:41 - 00:40:42)

Nein.

Wolfi Gassler (00:40:42 - 00:41:04)

Ja, bei Deployment sieht man das aber in der Regel. Also Ÿousand, ein paar Stories, über die ich schon gestolpert bin. Caching. Ich habe mal ein paar Webseiten betrieben, die zur Hochlast nicht ohne Caching auskamen. Die Server haben die Anzahl der Anfragen nicht bearbeiten können, wenn die Daten aus der Datenbank geholt hatten, wenn wir nichts zwischen Cached hatten in den Redis oder Memcache und ähnliches.

Andy Grunwald (00:41:04 - 00:41:11)

Moment, du sagst es so beiläufig. Ein paar Webseiten. Wie viel Traffic war auf den Webseiten? Nur um das einzuordnen, diese Projektgröße.

Wolfi Gassler (00:41:11 - 00:43:31)

Ich habe mal früher in einer Agentur gearbeitet, da haben wir unter anderem für Bitburger diese Kronkorken Aktion gemacht und da kommt, oder wenn da Fernsehwerbung gestartet wurde zu EM und solche Geschichten. Also da ging es halt teilweise schon um zweieinhalb, drei, 4000 Requests teilweise in der S, wenn das so Peak dinger waren. Aber das ging damals, also das war vor 10 Jahren, 2012, 2011, so die Ecke rum, da war das schon eine Hausnummer. Und jetzt kommen wir zum Thema Caching und Deployments. Denn Caching funktioniert nur mit cache Keys. Und wenn du etwas Variables in den cache Key packst, z.B. die Version von deinem Deployment, dann resettest du bei jedem Deployment den Cache. Sollte man sich mal Gedanken machen. Oder wenn du die Datenstruktur des Caches änderst in der neuen Version, dann hast du noch alte Daten im Cache, aber die Applikation möchte schon neue lesen, eine neue Datenstruktur, Bam, Bug oder Failure oder was weiß der. Geil. Also wenn du Caching hast, Caching ist ähnlich wie die Datenbank ein stateful System in deiner Gleichung hier. Das musst du leider auch genauso betrachten. Eine andere Geschichte ist Content Delivery Networks, denn wer nutzt sowas heute nicht? Seine JavaScript Dateien holt man von npm, js oder wie heißen die ganzen Content Delivery Networks? Seine eigenen Bilder pusht man auf irgendwelche CDNs, damit die näher beim Kunden liegen. Und da ist ja die Frage, ich habe ja gerade schon gesagt, pusht, wie viele Versionen deiner Assets hältst du denn auf dem CDN vor? Denn entweder pusht du während des Deployment Prozess deine Bilder, deine JavaScript, deine CSS Dateien, vielleicht sogar deine Videos oder deine mp dateien auf das cdN. Vielleicht lässt du diese Assets vom Cdn von deinen Servern pullen. Wie dem auch sei. Da haben wir, sind wir mal im Detail eingegangen in Episode 67 die netzentlastung des Internets. Zum Thema content delivery networks haben wir so ein paar Strategien auch mal benannt. Aber das musst du immer im Hinterkopf halten, denn wenn du immer nur die letzte Version da hältst, dann funktioniert ein Rollback ja nicht mehr, weil auch bei einem Rollback du auf deine alten JavaScript Dateien zurückgreifen möchtest. Und aber du möchtest ja auch nicht so viele Versionen haben, dass du ganz viel Speicherplatz beim CDN verbrauchst, weil das geht natürlich in deine Anführungszeichen Cloud Kosten, weil CDN ist ja auch nur Cloud. Also hab das mal auch im Sinn. Und Achtung, du invalidierst natürlich auch den Client Cache von dem Browser durch die URLs. Wie ist deine URL aufgebaut?

Andy Grunwald (00:43:31 - 00:44:11)

Was natürlich voraussetzt, dass du überhaupt eine unterschiedliche URL hast. Wenn du nur den Inhalt änderst und die Datei dieselbe bleibt, der Dateiname, dann hast du da ja auch ziemliche Probleme mit der mit der CDN. Aber Andi, du bist ja iPhone User, darum hätte ich da gleich eine Frage an dich. Ich habe ja neulich gelernt, dass scheinbar, wenn diese große Apple Konferenz und das Announcement von irgendwelchen neuen Spielereien bei Apple wieder ansteht, dass die ihren kompletten Store irgendwie abschalten, weil sie sagen, sie müssen da irgendwie das neue Zeug reinbringen, was ja schwer nach Caching klingt. Aber hat eine große Firma wie Apple das nicht im Griff, dass sie das dementsprechend technisch lösen können? Ich kann mir das ja fast nicht vorstellen. Ich glaube ja, dass das eine Marketingaktion ist.

Wolfi Gassler (00:44:11 - 00:44:41)

Du wirst sogar lachen. Ich habe noch nie in meinem Leben ein Apple Event geschaut. An dem Tag, an dem das Apple Event war, wollte ich aber mal nachgucken, welche iPods es gibt oder was, was diese Kopfhörer von den Kosten und solche Geschichten. Und ich konnte nicht draufgehen auf den Apps. Was ist denn hier los, was sie gemacht haben? Also Marketing, ja, vielleicht. Ich denke, das ist so ein bisschen, macht dich rar, weißt du, so ein bisschen FOMO. Okay, da kommt was großes, one more thing, wie Steve Jobs immer sagte, ich denke, das ist so ein bisschen so.

Andy Grunwald (00:44:41 - 00:44:49)

Den Hype hochfahren, weil rein technisch gesehen, oder? Also ich bin der Meinung, es wäre handlebar für so eine große Firma in irgendeiner Form.

Wolfi Gassler (00:44:49 - 00:44:56)

Ja, hundertprozentig. Aber die haben sich auf jeden Fall für die gute alte Wartungsseite entschieden. Eine Wartungsseite wird geschaltet und die App wird vollständig offline genommen.

Andy Grunwald (00:44:56 - 00:45:06)

Das haben wir übrigens noch gar nicht erwähnt. Das ist ja eigentlich auch ein klassisches Deployment, oder? Ich schalte eine Wartungsseite und macht dann ganz gemütlich in dem Fenster mein Deployment. Apple macht es vor.

Wolfi Gassler (00:45:06 - 00:47:55)

Genau. Der Nachteil ist halt, die wollen sich anscheinend leisten, dass du genau für diesen Tag oder für diese paar Stunden keine Sales über den App Store machst. Also nicht App Store, wo man Apps runterladen kann, sondern Apple Store, wo du Hardware kaufen kannst. Das finde ich schon faszinierend bei der Größe. Aber hey, anscheinend ist der Marketing Effekt größer. Und jetzt kommen wir nämlich auch zur dritten Herausforderung. Das Deployment unter Hochlast bzw mit zero downtime Herausforderung. Denn das hast du ja gar nicht, wenn du eine Wartungsseite schaltest. Du sagst Achtung, wir sind machen hier gerade Wartung. Ja, die nennen das vielleicht wir bereiten alles für das Apple Event vor. Aber was es ja wirklich gibt. Es ist die Herausforderung Deployments unter einer Spitzenzeit oder unter Last. Und zwar haben wir da habe ich da auch eine tolle Story. So zwei 1402 15 zweitausendein haben wir bei Trivago immer Fernsehwerbung geschaltet, ganz viel. Und dann war das wirklich so, dass ganz viele Leute vor dem Fernseher saßen und auf die Webseite gegangen bist. Deswegen hattest du abends immer so Rush Hour. Und wenn man da noch einen Fehler fixen wollte und ein Deployment gemacht hat, dann kam es immer zu Fehlern. Und was war der? Was war das Problem, wie wir deployed haben? Wir haben eigentlich ein SIP Archiv gemacht, haben das auf die auf die Maschine hochgeladen, haben es entpackt und haben dann symlink geändert, Linux Sim Link. Und während der Zeit, wo man den Linux symlink von der alten Version auf die neue Version gedreht hat, damit der Webserver die neue Webseite nimmt. Also wir haben damals PHP gemacht und Apache oder und Apache oder Nginx. Ich glaube, Apache war das noch. Aber das Problem hatte mit dem Web Server relativ wenig zu tun wie dem OS. Genau in diesem Moment, wo wir den Symlink immer gedreht haben, haben wir immer er im Monitoring System gesehen, also Server internal Server Error. Somit haben wir auch er ausgeliefert für diese Zeit. Das waren zwar nie viele Request, aber es nervt halt, weil es keine gute Customer Experience ist. Und Ende vom Lied war, wenn du einen klassischen Sümlink umdrehst, dann ist die Operation selbst, also mit ln s, nicht atomar. Und weil die nicht atomar ist, vergeht da Zeit dazwischen. Die Lösung war also, dass du einen neuen Symlink erstellst, new version, und dann mit einem Move den neuen mit dem alten überschreibst. Denn eine Move Operation in Linux ist atomar. Und solche Thematiken, damit beschäftigt man sich, wenn man unter Hochlast deployen möchte. Natürlich ist das eine Optimierung, da muss man sich fragen, okay, möchte man die, weil so viele er Fehler haben wir nicht ausgeliefert, aber es ist halt möglich und es ist halt auch lösbar. Und vielleicht sind die User auch darauf getrimmt, auf Webseiten einfach reload zu drücken. Aber ich möchte nur noch mal so die die Spannweite von diesem Problem, die man da hat, zweitausendein darstellen. Wir haben in den Shownotes auch einen kleinen Link, wie man Sümlings atomar wechselt, falls das irgendwer das Problem hat.

Andy Grunwald (00:47:55 - 00:48:10)

Wenn man es natürlich ganz sauber lösen würde, würde man den wahrscheinlich kurz aus dem Load Balancer rausnehmen, komplettes Update machen, die Maschine, dann wieder den Load Balancer reinsetzen. Aber ist natürlich zu der Zeit mit viel Metall und Oldschool Load Balancer auch schwieriger, als man so denkt.

Wolfi Gassler (00:48:10 - 00:48:16)

Unabhängig davon, ob das jetzt schwierig oder leicht ist, zweitausendein, meines Erachtens nach erhöht das die Komplexität sehr.

Andy Grunwald (00:48:16 - 00:48:43)

Ja, ganz oft ist es ja heutzutage eher das Problem, dass du dann auch Cache invalidieren musst auf der eigenen Maschine und Nginx hat einen internen Cache und so weiter, dass es da oft einfach leichter ist, die gesamte Maschine durchzutreten. Und wenn du jetzt im Cloud Native Bereich bist, dann machst du das sowieso anders, dass du wirklich das komplett neu deployst, wahrscheinlich das gesamte Image, den gesamten Node, weil das wahrscheinlich einfach ist und du hast dann dadurch gar keine side Effects mehr. Aber natürlich in dem speziellen Case Zweitausendein ist es eine sehr gute Variante.

Wolfi Gassler (00:48:43 - 00:49:31)

Wir reden hier von Champions League bei automatisierten Deployment Prozessen. Meines Erachtens nach ist auch nicht jeder in der Cloud. Es gibt noch super viele Firmen, die on premise fahren und die vielleicht noch einen alten Proxy am Laufen haben, der vielleicht schon super lange end of life ist. Aber genau darum geht es. Du kannst und musst nicht immer alles aus dem Load Balance herausnehmen. Ich habe bisher noch kein Deployment Prozess implementiert, wo ich etwas aus dem Load Balance herausnehme aber aber ja, ist möglich. Meines Erachtens nach ist das schon komplex, weil was ist, wenn der Deployment Prozess fehlschlägt? Dann ist die Node der Server aus dem Load Balance heraus und dann musst du den manuell wieder reinfriemeln, denn du kannst den Deployment Prozess ja nicht neu starten, weil die Node aus dem Load Balance herausnehmen schlägt ja dann fehl, weil die Node ist ja nicht im Load Balancer. Also verstehst du, da musst du dann manuell eingreifen, weil du ja einen inkonsistenten Zustand hast. Also ich sehe da schon wieder ganz viele Probleme.

Andy Grunwald (00:49:31 - 00:49:45)

Ja, also ganz klassisch jetzt im Cloud Umfeld wird man ja einfach neue Nodes dazusetzen mit der neuen Version und wenn man dann genug neue Version Nodes hat, fängt man an, die alten wieder rauszutreten. Aber das ist natürlich ein viel dynamischeres Umfeld. Aber wir sind schon.

Wolfi Gassler (00:49:45 - 00:49:57)

Hast du nicht gesagt, ich habe die rosarote Brille auf. Jetzt kommst du hier, Cloud Umfeld ist ja alles immutable infrastructure, da schießen wir einfach Notes durch, machen einfach, wir haben ja infrastructure as code, das läuft ja alles.

Andy Grunwald (00:49:58 - 00:50:08)

Ja, wir sind ja jetzt schon in dieser Episode im Teil, wie man das perfekt machen kann. Da muss ich natürlich die die guten Sachen natürlich auch dementsprechend erwähnen, wie es aufgebaut sein kann.

Wolfi Gassler (00:50:08 - 00:50:20)

Ich möchte nur noch mal für alle Hörerinnen und Hörer sagen, der Wolfgang ist freiberuflicher Berater. Falls ihr also die perfekte Lösung wollt, den Wolfgang kann man entweder hier stundenlang zuhören oder professionell dafür bezahlen.

Andy Grunwald (00:50:20 - 00:50:44)

Ist schön, wenn du als Deployment Professionalist, schwieriges Wort, mich empfiehlst. Vielen Dank dafür. Aber wir sind schon voll im Deployment Prozess drinnen, den verschiedenen Deployment Arten. Wir haben jetzt schon aus dem Load Balance heraustreten und so weiter gehabt. Also was gibt es denn für Möglichkeiten abseits von der Wartungsseite, die wir jetzt besprochen haben und Deployment architekturen würde ich mal nennen.

Wolfi Gassler (00:50:44 - 00:51:34)

Ich möchte nur mal ganz kurz erwähnen, ich bin super fan von der Wartungsseite. Ich habe damals auch beim bitburger Intranet sehr viel die Wartungsseite geschaltet, weil es gibt einfach nichts bequemeres. Du kannst während des Diploms einen Kaffee holen, manuelle Daten Migration durchführen. Wahnsinn. Naja, was gibt es noch? Es gibt natürlich die All or Nothing oder die Big Bang Deployments, wenn man so möchte. Big Bang Deployment meine ich jetzt nicht ganz viele Change Sets live schieben, so wie wir es gerade als Problem hatten, sondern eigentlich die neue Version auf einmal. Auf die komplette Produktionsumgebung auszurollen. Wer hat es gemacht? Crowdstrike vor kurzem, wer es gehört hat, mit einem Security update irgend so eine Kernel Windows Geschichte getriggert und ganz viele Flughäfen und Ämter lahmgelegt. Das war so eine All or nothing Big Bang Deployment. Vorteil ist natürlich, ist einfach, ist schnell. Nachteil Risiko eines kompletten Systemausfalls.

Andy Grunwald (00:51:35 - 00:51:38)

Was wäre die Alternative, wenn man nicht alles sofort updatet?

Wolfi Gassler (00:51:38 - 00:52:23)

Die einfachste Alternative wäre so eine Art rolling deployment, dass du sagst okay, du hast ein schrittweises Deployment, nimmst immer alle, sagst z.B. nur fünf Server alle 10 Minuten. Ist halt den Nachteil, dass du halt dein Deployment Prozess relativ in die in die Länge ziehst. Anzahl der Server alle 10 Minuten und so weiter. Kannst aber natürlich dann hast Ÿousand 10 Minuten Monitoringzeit, um zu verifizieren, dass die neue Version funktioniert. Also das Risiko von Ausfällen wird dann reduziert. Bei Fehlern kann das Deployment gestoppt werden. Du hast aber auch den riesen Nachteil, dass die vorherige und die aktuelle Version kompatibel sein müssen, da du ja sonst potenzielle Inkonsistenten zwischen den alten und den neuen Versionen hast. Ja, ich habe gerade von Cash Keys geredet und so weiter und so fort und ist natürlich ein Tick komplexer.

Andy Grunwald (00:52:23 - 00:52:51)

Also vielleicht, wenn es noch nicht ganz klar war, nur noch mal zur Klarstellung. Wir sprechen jetzt natürlich von Setups, die mehrere Knoten, mehrere Computer beinhalten und jetzt nicht nur einen Server, der in irgendeinem Eck steht. Aber ehrlich gesagt, das gibt es ja eh immer weniger, weil fast jede Software mindestens mal auf zwei Knoten läuft und du dann schon eigentlich eine gewisse Skalierung hast und dadurch mehrere Knoten mit bezüglich Ausfallsicherheit ist ja heutzutage eigentlich auch fast Standard, würde ich sagen.

Wolfi Gassler (00:52:51 - 00:54:37)

Was du natürlich auch machen kannst, auch wenn du nur einen Knoten und mit Knoten meine ich Server oder Endpunkt hast, also jetzt nicht 20 Server, dann kannst du natürlich auch in irgendeiner Art und Weise dein Deployment sicherer machen. Und zwar ist eine Subsparte vom Rolling Deployment, wo du nach und nach alle 10 Minuten fünf Server durchtrittst, z.B. oder Updates ist das sogenannte canary Deployment. Ist eine sehr, sehr ähnliche Geschichte, nur da geht es ein bisschen anders. Und zwar wird die wird die neue Version nur an eine kleine Benutzergruppe ausgeliefert, z.B. 5 % des Traffic Ÿousand und du merkst schon, es ist ähnlich wie das Rolling Deployment, aber die restlichen Nutzer verwenden dann weiterhin die alte Version und die neuen Nutzer bleiben auf der neuen Version. Vorteil ist halt ebenfalls ein geringes Risiko. Nachteil ist halt erfordert mehr Infrastruktur und Monitoring und diese Art von schrittweise Freigabe. Und warum sage ich, du kannst es natürlich auch mit einer Node fahren? Da kommt die ganze Logik dann auch. Bei einer Node setzt du vorher einen Load Balancer. Der Load Balancer kann ja auch auf derselben Node laufen, auch bei einem Server und dann splittest du da einfach zwei Environments und über den Load Balancer steuerst du halt, wie viel % des Traffics auf welche Version geht. Ein Beispiel ist halt irgendwie Social Media Plattform führt ein neues Feature ein und aktiviert das nur für 1 % der Nutzer oder ähnliches. Oder es gibt auch klassisches Beispiel von sogenannten Kohorten Deployments, z.b. mehr Mandanten Systemen, wo dann Free Tier User oft eine neuere Version bekommen anstatt die Enterprise User, weil Enterprise User meist Stabilität präferieren und Free Tier User, da sagt man ja, die zahlen ja nichts für SaaS, deswegen shippen wir, testen wir einfach alles auf den Free T Usern. Das ist so Klassiker von canary Deployments in mehr Mandantensystemen.

Andy Grunwald (00:54:37 - 00:55:46)

Man könnte natürlich dann auch noch einen Schritt tiefer gehen. Also das, was du jetzt erwähnt hast, ist, dass man Load Balancer hat und dann mehrere Versionen auf einem Server. Man kann aber natürlich auch innerhalb einer Softwareversion verschiedene Variationen, nenne ich es mal, testen. Nennt sich dann Feature Toggles oder feature Flags, dass man also wieder für 5 % der User oder 50 % der User gewisse Features einschaltet oder abschaltet. Also auch da wieder das Free Tier z.b. was anderes bekommt als die Enterprise User oder einfach wie gesagt prozentuell, dass man mal was austestet. Vielleicht am Anfang sogar eben nur 1 % der User bekommen mal die neue Version, um überhaupt zu testen, funktioniert dieses Feature? Also gibt es irgendwie bugs, gibt es Probleme und ich kann das dann auch super schnell abschalten wieder. Also wenn ich irgendwo Bug sehe oder irgendwie höhere Ladezeiten z.b. kann ich ganz simpel mit einem Feature Flag, ohne ein neues Deployment anzustoßen, meistens direkt in der Datenbank irgendwo ändern, okay, dieses Feature wird jetzt gerade wieder aktiviert oder für 0 % der User ausgespielt. Und so kann ich dann langsam die Prozentzahl nach oben schrauben und bekomme dann immer mehr User auf mein Feature und das läuft dann komplett in der Software ab.

Wolfi Gassler (00:55:46 - 00:55:49)

Ich liebe Feature toggles und Feature Flex und es ist.

Andy Grunwald (00:55:50 - 00:55:51)

Meinst du das jetzt ironisch oder?

Wolfi Gassler (00:55:51 - 00:56:24)

Nein, nein, ich meine das wirklich, wirklich ernst, denn ich denke, wenn du etwas in deinem System so implementiert hast, dann hast du ein sehr erwachsenes System oder auch ein sehr erwachsenes Team. Denn meiner Meinung nach, jedes neue Feature sollte hinter einem Feature Flex sein. Der Riesenvorteil von Feature Flex ist ganz einfach, dass du das Deployment von der Feature Aktivierung entkoppeln. Das bedeutet auch, du kannst halbfertige Features shippen. Aktiviere das Feature Flag einfach nicht. Und es erlaubt dir, neue Features im laufenden Betrieb zu testen und bei Problemen einfach wieder auszuschalten. Genauso wie du sagtest, du kannst ja.

Andy Grunwald (00:56:24 - 00:57:11)

Sogar, also nicht nur Live User das Feature einschalten, sondern du kannst sagen, nur für die Entwickler ist z.B. ein Feature. Also nur für den User XY ist aktuell dieses Feature aktiv. Und dann kannst du als Entwickler, Entwicklerin halt dementsprechend auch das Ganze testen. Man muss natürlich schon sagen, darum habe ich auch gefragt, ob du das ironisch meinst, weil es gibt natürlich schon ganz viele Nachteile mit dem Feature Flags, auch auf der Softwareentwicklungsseite. Und wir sind ja ein Softwareentwicklungs Podcast. Du musst dieses Feature dann, wenn es angenommen wird, in den normalen Code reinbringen. Das kostet wieder Zeit. Du hast Probleme, dass teilweise toter Code irgendwo rumliegt. Das wurde nie ordentlich ausgebaut. Also auf der Softwareentwicklungsseite kann das schon auch zu Problemen führen, auch auf der Administrationsseite. Aber ich will da gar nicht zu tief reingehen in das Thema, da könnten wir, glaube ich, eine ganze Episode damit füllen.

Wolfi Gassler (00:57:11 - 00:59:06)

Die Nachteile, die du erwähnt hast, die sind aber essentiell meines Erachtens nach. Denn die Verwaltung der Feature Flags, die werden auch ganz schnell mit dem Begriff Technical Debt in Verbindung gebracht. Wie lange darf dieses Featureflag noch drin bleiben und so weiter. Dann die zweite Geschichte ist, überleg dir mal, wie du dein Feature Flag überhaupt aktivierst. Deine App muss in irgendeiner Art und Weise sogenanntes Config Reload unterstützen. Je nachdem, wo du die feature Flags aktivierst, sei es in der Datenbank, in der Config Datei usw. Die Applikation muss den State ja neu laden. Und das ist natürlich dann auch ein bisschen komplex. Wenn man schon von Feature Flex redet, dann kann man natürlich auch ein bisschen über A b testing sprechen. Ist so eine Unterkategorie von einerseits Featureflex, andererseits auch Canary Deployment, je nachdem, auf welcher Ebene man die ganze Sache fährt. Es ist eine Unterkategorie von Featureflex. Wenn man jetzt einfach nur sagt, okay, ich tausche jetzt einfach den Button aus von, keine Ahnung, ich ersetze den Button durch einen Link, dann ist das ja auch ein Deployment eines neuen Features, aber man a b testet das und dann hat man natürlich zweitausendein die Aktivierung durch den Feature Toggle oder durch den Feature Flag und hat hinten dran das Messsystem. Man kann aber auch mit dem A b Testing die ganze Sache sehr ähnlich wie ein canary Deployment fahren und sagen, wir machen einfach mal AB testing auf unsere Caching Systeme. Das haben wir z.B. mal gemacht. Wir haben nämlich Memcache für den Session Storage genutzt von User Logins und sind immer an Probleme gestoßen. Geht um die Slap Allokierung, haben wir vielleicht irgendwann schon mal erwähnt, wenn nicht, tun wir das mal in Zukunft. Auf jeden Fall haben wir das dann mal einfach durch Redis ersetzt und haben das einfach nur auf 5 % des Traffics gejagt. 5 % des Traffics haben also Redis als Session Storage genutzt, 95 % haben weiterhin Memcache genutzt. Da haben wir so eine AB Testing Geschichte auf Infrastruktur gemacht. Ist natürlich super, wenn man datengesteuerte Entscheidungsfindung hat. Ist natürlich enorm komplex, erfordert robustes Monitoring, gegebenenfalls auch für eine gewisse Zeit. Zweitausendein doppelte Infrastruktur und somit natürlich doppelte Infrastrukturkosten.

Andy Grunwald (00:59:06 - 00:59:32)

Aber wir haben halt, Andi, wenn ich das mal kurz erwähnen darf, wirklich ein Problem mit unserer bingo Karte. Ganz wenige Passworts, continuous deployment, bist du mir nicht eingestiegen. Und da gibt es ja im Deployment Bereich auch noch dieses Passwort green. Ah sorry, jetzt habe ich schon falsch rum. Es heißt nicht green blue, sondern blue green deployment. Das hört man ja ständig. Ich kann mich erinnern, wie oft mich Leute gefragt ja, machst du schon blue green deployment? Also erklär mir mal bitte, was ist Blue Green Deployment?

Wolfi Gassler (00:59:33 - 01:01:08)

Ich will nicht sagen, es ist so eine Art all or nothing Big Bang Deployment, dass man eine Version einfach live schaltet, aber doch irgendwie. Also was man da tut, ist ganz einfach. Du hast eine komplette live Umgebung, auf der läuft die alte Version, das ist die blaue Version. Dann deployst du und setzt also eine neue Live Umgebung auf. Dort deployst du die neue Version, das ist die grüne Version zweitausendein. Dann führst du User Acceptance Tests durch, vielleicht hast du auch eine interne Freigabe oder ähnliches. Diese touren immer auf der neuen Version, auf der grünen Version rum. Und irgendwann, wenn du sagst, jo, die grüne Version ist stabil, das Monitoring sagt, alles ist grün, dann wird der Traffic einfach von der blauen auf die grüne umgeleitet. Vorteil ist, du hast keine Auswahlzeiten. Es ist ein sehr einfacher Rollback. Man leitet einfach nur den Traffic wieder auf die blaue Version und das ist natürlich super einfach zu implementieren in der Hinsicht. Voraussetzung ist natürlich ein Load Balancer vorne dran. Nachteil teurer, da du in der Regel zwei vollständige Live Umgebungen hast. Tricky Part ist natürlich die stateful Systeme, wie immer bei den Blue Green Deployments, die ich bisher gesehen habe, hat man hinten dran die Infrastruktur, Datenbank Caching, Mail Server und so weiter, alles geteilt. Da muss man natürlich wie immer aufpassen, auf welche Version rollt man back, wie macht man die Datenbank Migration, cache Migration, hatten wir ja gerade alles besprochen. Da ist das ganz, ganz essentiell. CDN, die klassischen Herausforderungen treffen da alle ein. Ist aber von der Implementierung meines Erachtens nach deutlich einfacher, als wenn du jetzt so eine Canary Deployment, also einen prozentualen Rollout hast oder ähnliches.

Andy Grunwald (01:01:08 - 01:01:23)

Wobei es natürlich schon sehr ähnlich ist zu Canary Deployment, nur es ist halt langsamer, aber im Prinzip hast du auch den Traffic Split auf zwei Infrastrukturen oder auf die auf die neuen Server. Also es ist schon, ich würde fast sagen Unterbereich.

Wolfi Gassler (01:01:24 - 01:02:13)

Ja, obwohl du natürlich beim Blue Green Deployment, ich sag mal, die Verifizierung der grünen Version anders machst als beim Canary Deployment. Beim Canary Deployment machst du die Verifizierung, dass du nur einen Teil % des live Traffics auf die neue Version schießt und dann einfach, ich sag mal, in Produktion testestausend. Beim Blue Green Deployment hast du so eine Art Freigabeprozess, Akzeptanztests oder UI Tests oder was auch immer und irgendwer sagt, jo, die grüne Version ist grün. Also da ist sehr ähnlich. Aber das sind jetzt diese ganzen Deployment Prozesse, die man aus allen Büchern kriegt und von mir aus auch bei Chat GPT und jeder Consultant, also auch Wolfgang, kann dir diese runterbeten. Mein absoluter Liebling sind jedoch sogenannte Shadow Deployments, nennt man auch Dark Launches. Dark Launches sind eine super geile Sache.

Andy Grunwald (01:02:13 - 01:02:14)

Ist sowas wie Dark Kitchen.

Wolfi Gassler (01:02:14 - 01:02:16)

Ich weiß nicht, was eine Dark Kitchen ist.

Andy Grunwald (01:02:16 - 01:02:35)

Ich glaube mittlerweile sind sie verboten, sogar in Deutschland, oder dass wenn du auf irgendeinem Bestelldienst dir deine Pizza kaufst und liefern lässt, dass es da gar keine echte Pizzeria gibt, sondern dass es nur eine Fake Brand ist, die in der Dark Kitchen hergestellt wird, in irgendeinem Keller, wo irgendwelche armen Leute sitzen und deine Pizza backen?

Wolfi Gassler (01:02:36 - 01:02:39)

Nein, dann haben Dark Launches und Shadow Deployments damit nichts zu tun.

Andy Grunwald (01:02:39 - 01:02:40)

Schade.

Wolfi Gassler (01:02:40 - 01:04:10)

Was passiert da? Und zwar willst du eine Datenbank Migration machen, willst du irgendein Feature ersetzen, refactoren oder ähnliches. Eine vorhandene Logik willst du neu implementieren. Du shipst diese Version neben deiner alten Version, führst beide Versionen aus, lässt also die Computation Power durch beide durchlaufen, verwirfst das Ergebnis deiner neuen Operation und lieferst einfach nur das Ergebnis deiner alten Operation zurück. Natürlich kannst du noch unter anderem vergleichen, sind diese beiden Ergebnisse von den neuen unterhalten Operationen gleich? Z.B. aber so kannst du schon mal deine neue Logik testen, kannst testen, gibt es da Performance Regressions, gibt es da bugs, weil du z.B. die Ergebnisse vergleichst und der Nutzer bekommt einfach weiter die alte Version. Das kannst du entweder auf feature Basis im Quellcode machen, das kannst du aber auch auf Infrastrukturbasis mit sogenanntem Traffic Shadowing testen. Das bedeutet, es gibt Load Balancer, die können den Traffic duplizieren. Der User geht einfach auf die alte Version, der Traffic wird durch den Loadbalancer auf die neue Version geschickt. Der Load Balancer verwirft das, kann aber sagen, da kamen 200 zurück. Ganz klassisch, wenn man eine komplette Migration fährt von einer alten App auf eine neue App oder ähnliches, dann macht man sowas. Oft sind alle Endpunkte da SEO oder Bookmarks oder man kennt das, man macht, man macht eine Migration und irgendwie die Hälfte der URLs funktionieren nicht mehr. Ich glaube, es gibt nichts beschisseneres, wo man was nachziehen muss. Aber das ist natürlich kann man auf Feature Ebene oder auf Infrastruktur Ebene machen.

Andy Grunwald (01:04:10 - 01:04:43)

Meine Lieblingsgeschichte diesbezüglich ist ja von Booking Dot com, die da immer einen SQL Proxy im Hintergrund hatten und den gesamten Traffic gespiegelt haben von ihrer Oracle MySQL auf ne mariadb, damit sie, wenn die Sales Jungs von Oracle vorbeigeschaut haben, dass die ein gutes Argument gehabt haben, dass hey, wir testen das alles mit MariaDB jederzeit. Wir testen den Speed, ob alles funktioniert und wir könnten von heute auf morgen auf MariaDB umsteigen. Also ist weniger eine Migration, aber auch eine coole Aktion mit mit so einem Proxy.

Wolfi Gassler (01:04:43 - 01:05:27)

Da muss man aber auch sagen, Booking ist ja auch kein kleiner Laden und Traffic Shadowing ist eine enorm komplexe Thematik, besonders wenn du mit mit Traffic, der hinter irgendwelchen Paywalls oder Zugangsbeschränkungen steht, da musst du theoretisch nämlich auch die ACLs Cookies und Authentifizierung, Autorisierung mit Shadow und das ist dann da wird schon sehr, sehr, sehr komplex. Und Achtung als Engineering Team kann man da sehr viel Zeit drin versenken. Deswegen, wenn ihr Scars an Ressourcen und in diesem Fall meine ich mit Ressourcen Menschen Engineering Power seid, dann ist das vielleicht zweitausendein nichts auf Infrastrukturebene, aber auf Feature Ebene, wenn ihr was refactoren wollt, eine Methode perfekt, muss ich zugeben, einfach daneben setzen und dann jetzt muss ich.

Andy Grunwald (01:05:27 - 01:05:58)

Aber doch noch mal einwerfen, dass da mein hinkender Vergleich zu der Tag Kitchen gar nicht so weit hergeholt ist. Ich kenne mich eine Pizzeria, die heißt, nennen wir sie mal Pizza Andi, die ist ganz normal, kannst hingehen, Pizza essen. Aber es gibt auch die Pizzeria Wolfi und die ist online zweitausendein und die gibt es nur online. Die verwendet aber den gleichen Pizza Backofen, hat aber andere Namen für die Pizza, andere Preise und die testen das quasi online bzw. Haben da eine komplett zweite Brand aufgebaut und Wolfi performt natürlich besser und hat höhere Preise, ist eh klar.

Wolfi Gassler (01:05:58 - 01:06:29)

Nicht aber nur, weil die Pizzeria Andi keine Laufkundschaft hat. Aber wer, wer so ein bisschen an Dark launches Shadow Deployments interessiert ist. Wir haben den Show Notes auch mal einen Link von Martin Fowler gepostet. Facebook ist meines Erachtens nach bekannt dafür, dass die anderen treibenden Kräfte dahinter waren, die das sehr, sehr früh und sehr, sehr viel auch machen. Ich bin ein mega Fan von, aber ich bin auch ein mega Fan von Feature Toggles, denn ich denke, man sollte viel mehr unfertigen Code schippen und den sehr früh testen, auch in Produktion, damit der Feedback Cycle so kurz wie möglich bleibt.

Andy Grunwald (01:06:30 - 01:06:37)

So und wie finde ich jetzt raus, ob mein Feedback Cycle wirklich verbessert wird, wenn ich jetzt mein Deployment automatisiere und verbessere?

Wolfi Gassler (01:06:37 - 01:08:32)

Ja, jetzt kommt natürlich immer der Punkt okay, woher weiß ich denn, dass mein Deployment Prozess schnell genug ist? Und woher weiß ich denn, dass ich alles richtig mache? Da sagt man immer Metriken und jetzt schlagt mich bitte alle. Aber die Dorametriken, die wir in Folge 87 ein bisschen durchdiskutiert haben, sind da leider ein ein recht guter Indikator. Und ich sage extra Indikator, das ist jetzt kein Allerheilmittel, aber so deployment Frequency, wie oft deployed man pro Woche, pro Monat oder ähnliches oder die Lead Time for Change oder die sogenannte Cycle Time sind da schon ganz gute, ganz gute Elemente, die man auf jeden Fall beobachten kann. Kurz zur Erklärung die Lead Time ist, wenn der Kunde ein Request macht, bis zu dem Punkt, wo du das Feature oder den Bugfix in Produktion hast, also der Kunde es nutzen kann. Das ist die sogenannte Lead Time. Ein Sub Element davon ist die sogenannte recycle time. Recycle time ist, wenn das Entwicklungsteam mit der Arbeit beginnt, bis zu dem Punkt, wenn das zum Kunden delivered ist. Das sind die zwei Zeiten, die man misst, wenn man die Feedback Cycle verbessern möchte, würde ich mal sagen. Da gibt es natürlich noch anderes, so meantime to recovery und die Change Failure Rate. Change failure rate ist dann gegebenenfalls ein Indikator, dass euer Code Review Prozess vielleicht nicht ganz so gut ist. Meantime to recovery hängt natürlich auch mit dem Deployment Speed und auch mit dem automatisierten Deployment zusammen. Desto schneller du deployen kannst, umso schneller ist die meantime to recovery. Ja, schaut euch einfach mal die Episode 87 noch mal an. Da haben wir das alles hoch und runter gebetet. Ob man jetzt den Vergleich mit anderen Teams, wie bei Dora üblich, machen muss, ob du zum Elite Team gehörst oder nicht, sei mal dahingestellt. Das lasse ich als Aufgabe für dich als Hörerin und Hörer. Aber ein bisschen datengetriebene Entscheidungen ist, glaube ich, nicht schlecht. Von daher, jetzt haben wir zu Beginn.

Andy Grunwald (01:08:32 - 01:09:33)

Begonnen mit den Anti Patterns, wo die Probleme liegen, wo die Vorteile von der Automatisierung liegen, wie man so Deployments machen kann, also wie man das Rollout macht und auch wie man das am Ende misst. Aber jetzt wollen wir ganz abschließend noch mal in ein praktisches Beispiel eingehen, Andi. Und da hätte die Frage an dich, weil wir sprechen da ja immer über Cloud Native und Web Apps und diese ganzen Dinge, die ja vergleichsweise einfach sind. Nehmen wir mal ein anderes Beispiel, um dich als Deployment Spezialist einmal zu challengen. Wie würdest du das aufsetzen bei so einem Unternehmen wie McDonald's oder Burger King? Die machen jetzt ein Update in ihrer Kassensoftware, also von diesen Terminals, die da rumhängen. Ich weiß gar nicht, ob da noch Menschen arbeiten, die man so ansprechen kann, ob das man Burger will. Ich war da schon seit 10 Jahren nicht mehr, aber ist ja egal. So ein Ding, was weltweit in allen Standorten steht. Wie würdest du dann Deployment machen, wenn du dir das jetzt aussuchen könntest?

Wolfi Gassler (01:09:33 - 01:10:13)

Ich würde einen Server im Backoffice haben, der die Software hat und den Content der Software, weil so ein McDonald's hat ja pro Region andere Burger teilweise und so viel ich weiß, ist McDonalds Franchise und somit kann der Gastronom selbst auswählen, welche Aktion der von McDonalds mitmacht und so nicht. Aber ich würde einen Server im Backoffice haben, einfach nur aus dem Grund, damit der Sales weiterlaufen kann, wenn es eine Internetstörung gibt oder wenn der zentrale McDonald's Server offline ist. Und ich würde eine Logik implementieren in einem Backoffice Server, der in irgendeiner Art und Weise ein Upgrade Mechanismus hat, wo dann der Gastronom selbst drauf drückt, weil der Gastronom weiß, wann der Rush Hour hat und wann nicht.

Andy Grunwald (01:10:13 - 01:10:20)

Jetzt hast du ja die komplette Automatisierung vorgeschlagen und jetzt schlägst du dann manuellen Ÿousand Prozess vor mit einem roten Button.

Wolfi Gassler (01:10:20 - 01:11:14)

Nein, nein, nein, nein, nein. So, und jetzt machen wir deine Bingo Karte mal völlig fertig. Hier die Begriffe Continuous Integration, Continuous Delivery und Continuous Deployment haben wir kaum erwähnt. Und jetzt kommt's. Ich habe gesagt, da gibt es einen Button, wo der Gastronom auf Upgrade drücken kann. Ich habe nicht gesagt, der muss dann 10 Befehle eingeben. Und was ist das? Das ist Continuous Delivery. Das Paket ist ready. Die finale manuelle Aktion ist aber notwendig, um das Paket auszurollen. Das ist Continuous Delivery. Continuous Deployment ist komplett automatisierte Auslieferung. Ich vertausche die Begriffe immer und ich kenne bisher keinen guten Leitsatz oder Merksatz, wo ich diese zwei Begriffe nicht vertausche. Aber im Endeffekt würde ich eine Continuous Delivery Lösung für so ein McDonald's machen. Und ich gehe stark davon aus, dass sie irgendein Content Management System hinten dran haben, wo man dann die Burger freischalten kann oder nicht. Weil wenn die. So würde ich es machen.

Andy Grunwald (01:11:14 - 01:12:02)

Ja gut, das ist die Administration von dem Ganzen. Aber es ist ja auch die Frage, wie oft man so Updates ausrollt. Ob das bei denen eher so eben alle paar Monate nur passiert oder ob da wirklich regelmäßig Updates reinfliegen. Wäre super interessant, wenn jemand da irgendwie Einblicke hat bei McDonald's, Burger King oder bei irgendeiner großen weltweiten Kette. Wäre natürlich super interessant. Ich persönlich würde es automatisieren und einfach außerhalb der Öffnungszeiten, weil es relativ easy ist in dem Fall. Aber wenn ihr da Infos habt, lasst uns das wissen. Schaut mal vorbei bei uns in der Discord Community. Da gibt es z.B. auch so Leute, die Software für Kreuzfahrtschiffe entwickeln. Also da könnt ihr dann gerne Deployment Prozesse auch in sehr eigenartigen Umgebungen diskutieren. Link findet ihr natürlich in den Shownotes, einfach unter Community, aber du sprichst ja.

Wolfi Gassler (01:12:02 - 01:13:07)

Einen guten Punkt an. Wir reden hier ziemlich viel von Web Software, Cloud native Software, vielleicht auch von Apps oder ähnliches. Aber je nach Art der Software, die du hast, hast natürlich andere Deploymentstrategien. Beispiel, wenn du eine mobile App hast, dann hast du immer die Gatekeeper wie den Google Store oder den App Store. Hast du ein Embedded System, dann ohne Internet, was vielleicht air gapped ist, dann ist das Deployment natürlich auch ein bisschen schwierig mit automatisiert. Da muss ja manuell jemand ans System ran. Hast du Betriebssysteme? Ja, ich glaube Mac kommt jedes Jahr einmal raus. Da hast du natürlich das Live Deployment nur in einem Jahr. Dann gibt es vielleicht spezielle Termine für Releases, wie bei der Börse, die wir vorhin erwähnt hatten. Oder halt sogenannte Enterprise Produkte, wo generell ein langsamerer Release Zyklus da ist. Also gegebenenfalls muss man nicht immer alles vollkommen automatisieren und Gegebenenfalls muss man nicht 23 mal pro Tag bei jeder Art von Software releasen. Den Kontext, den habt nur ihr. Aber Wolfgang, zum Abschluss dieser Episode meine Frage an dich ist Kubernetes die Lösung für all deine Deployment Probleme?

Andy Grunwald (01:13:07 - 01:13:13)

Kubernetes ist die Lösung für absolut alles. Früher war 42, vergiss 42. Kubernetes ist das neue 42.

Wolfi Gassler (01:13:13 - 01:14:12)

Ich habe mal geguckt, wir haben ja ziemlich viel über Deployment Strategien gesprochen. Canary rolling deployments, blue green feature toggles, shadow deployments und so weiter. Und ich habe ein GitHub Repository gefunden, wo jemand alles einmal mit Kubernetes implementiert hat. Verlinken wir euch auch. Sehr interessant. Anscheinend kann man da alles implementieren. Das macht das System aber auch unglaublich komplex und deswegen gibt es vielleicht auch Kubernetes Engineers inzwischen, die dann nur in ihrem Jammelmanifest darum hantieren. Aber nun gut, man muss natürlich nicht Kubernetes benutzen. Ihr könnt von mir aus auch rsync und FTP Uploads nutzen. Was ihr nutzt, ist mir völlig egal. Bei uns in der Firma machen wir ziemlich viel mit System d und endspawn Containern, also und nativen RPM Packages auf Federer. Da könnt ihr z.B. wenn ihr auf Linux unterwegs seid, auch Debian Pakete nehmen oder ähnliches und die ganzen normalen Package Server nutzen. Hat alles vor und Nachteile, aber muss nicht immer alles immer Docker, Docker, Docker sein. Nur mal, um mal ein bisschen den Horizont zu erweitern.

Andy Grunwald (01:14:12 - 01:14:48)

Andy, vielen Dank für deine wie immer weisen und vielen Einblicke in die ganze Deploymentwelt in der du ja definitiv tiefer drin bist als ich, meistens zumindestens. Wer noch immer nicht genug hat von dem ganzen Thema, können wir zwei Episoden empfehlen. Die 109. Episode, wo wir darüber sprechen, wann denn solche Update Zyklen und Deployment Zyklen unterbrochen werden können sollen oder wann das Sinn macht. Und der Andi hat es gerade angesprochen, wenn es um Metriken geht, die Dora Metrik ist eigentlich die Metrik, die da auch großen Einfluss hat. Haben wir in Episode 87 besprochen, hört gern mal rein, zweitausendein.

Wolfi Gassler (01:14:48 - 01:15:33)

In den Shownotes haben wir euch auch noch ein paar Links hingesetzt, z.b. diesen Softwarefehler von Night Capital, den Wolfgang erwähnt hat, z.b. wie Martin Fowler über Dark Launching denkt, z.B. den Talk von der deutschen Börse oder beziehungsweise von einem Systemadministrator bei der deutschen Börse, wann die deployen, wie die Infrastruktur aussieht und so. Und natürlich würde ich gerne mal wissen, wie du aktuell deployst. Deswegen schreib uns mal eine Mail oder auf den normalen Socials findet ihr uns bestimmt. Wenn ihr uns da nicht folgt, geht da mal rein, folgt uns mal eben. Und natürlich die Königsklasse, denn das ist ein religiöses Thema hier, die ganze Deployment Thematik. Lass uns mal in der Community ein bisschen rumstreiten. Kommt mal rüber und sagt uns mal bitte, wie das richtig geht. Das war's von uns diesmal, bis zur nächsten Woche. Bye bye.

Andy Grunwald (01:15:33 - 01:15:34)

Ciao.

Wolfi Gassler (01:15:34 - 01:15:34)

Ÿousand.