Deployst du auch Freitags und während Black-Frida und /Cyber Monday?
Code Freezes verbieten, dass neue Änderung in den Hauptentwicklungszweig gemerged werden. Deployment Freezes verhindern das eine neue Software-Version an den Kunden ausgeliefert werden kann. Doch warum tut man dies? Denn eins steht fest: Software Engineers werden dafür bezahlt, Dinge zu ändern. Doch Code- und Deployment Freezes werden oft vom Management vorgegeben.
Welche Gründe für Code- und Deployment Freezes sprechen, welche Arten von Freezes es gibt, was ein Code Slush ist, wie das ganze in verschiedenen Industrien aussieht, das klären wir in dieser Episode.
Bonus: Wenn Software-Engineers durch Code-Freezes an ihrem Job gehindert werden.
Das schnelle Feedback zur Episode:
Sprungmarken
Hosts
- Wolfgang Gassler (https://mastodon.social/@woolf)
- Andy Grunwald (https://twitter.com/andygrunwald)
Feedback (gerne auch als Voice Message)
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Email: stehtisch@engineeringkiosk.dev
- Mastodon: https://podcasts.social/@engkiosk
- Twitter: https://twitter.com/EngKiosk
- WhatsApp +49 15678 136776
Transkript
Andy Grunwald (00:00:04 - 00:01:04) 
Software-Engineers und andere Leute im Tech-Bereich werden üblicherweise dafür bezahlt, Dinge, Code, Pipelines und Co. zu ändern, Bugs fixen, Features entwickeln, vielleicht sogar einen Bereich zu revolutionieren und zu disrupten. Was ist jedoch, wenn sie daran gehindert werden? Wenn sie keinen Code in den Main-Branch merken können und alle Deployments untersagt bzw. gesperrt sind, dann befindet sich die Organisation in einem sogenannten Code- bzw. Deployment-Freeze. Doch warum sollte eine Firma das tun? Wozu ist das gut, wenn man keinen Wert zum Kunden schippen kann? Nachteile fallen einem da bestimmt viele ein. Doch gibt es auch Vorteile? Betrifft ein solcher Freeze eigentlich alle und jeden? Und wie gehen unterschiedliche Industrien und Softwareprodukte damit um? Wir widmen uns heute dem Thema Codefreeze und Deploymentfreeze. Denn wir denken immer, wenn du freitags nicht deployst, hast du bereits einen Deploymentfreeze. Lieber Wolfgang, ich habe schon fast eine religiöse Frage an dich.
Wolfi Gassler (00:01:05 - 00:01:06)
Ich bin nicht religiös.
Andy Grunwald (00:01:06 - 00:01:08)
Bist du Atheist?
Wolfi Gassler (00:01:08 - 00:01:13)
Agnostiker. Atheist? Was ist das? Ich bin da immer verwirrt. Ich bin eines von den beiden.
Andy Grunwald (00:01:13 - 00:01:15)
Okay. Deployst du an Freitagen?
Wolfi Gassler (00:01:15 - 00:01:17)
Schwere Frage.
Andy Grunwald (00:01:17 - 00:01:20)
Religiöse Frage, habe ich doch gesagt. Also, deployst du an Freitagen?
Wolfi Gassler (00:01:20 - 00:01:21)
Es kommt auf den Kontext drauf an.
Andy Grunwald (00:01:21 - 00:01:24)
Setz dir den Kontext selbst. Deployst du an Freitagen?
Wolfi Gassler (00:01:24 - 00:01:31)
Die meiste Zeit schon, ja. Aber es kommt darauf an, was ich am Samstag vorhabe. Und ob es für ein größeres Team ist oder nur für mich selbst.
Andy Grunwald (00:01:32 - 00:01:37)
Fängt grandios an. Welches Szenario muss existieren, damit du Freitags nicht deployst?
Wolfi Gassler (00:01:37 - 00:01:45)
Ja, wenn ich am Samstag eine Skitour gehe, dann deploye ich vielleicht nicht noch irgendwann am Freitag. Wenn ich weiß, dass ich verantwortlich bin, aber nicht verfügbar bin.
Andy Grunwald (00:01:45 - 00:02:19)
Wundervoll. Und da hast du mich direkt zum heutigen Thema geführt. Und zwar sprechen wir heute mal über ein Thema, was ich glaube, viele schon mal erlebt haben, aber auch viele nicht mögen. Und zwar geht es eigentlich heute um Codefreezes bzw. Deploymentfreezes. Und du sagst es ja schon, du führst selbst bei dir freitags ein Deploymentfreeze ein, wenn du samstags für die Plattform verantwortlich bist oder ähnliches. Und meine Frage ist jetzt eigentlich, Warum hat dein Deployment am Freitag erst einen Effekt am Samstag?
Wolfi Gassler (00:02:19 - 00:02:31)
Ja, weil ich in meinen kleinen Projekten natürlich kein sauberes Testing, keine sauberen Pipelines habe. Wenn ich das natürlich in einem professionellen Umfeld, in einem Team oder sowas mache, dann schaut die Sache natürlich ganz anders aus.
Andy Grunwald (00:02:32 - 00:02:37)
Aber du hattest doch grad auch gesagt, wenn ein Team dahinter steckt, dann deployst du auch nicht an einem Freitag, oder?
Wolfi Gassler (00:02:37 - 00:02:48)
Es kommt drauf an, wie mature das Team ist und wie mature die Software und die Pipelines drumherum sind. Und wie wichtig vielleicht auch die Software ist. Und ob da On-Call dahinter steckt und, und, und.
Andy Grunwald (00:02:49 - 00:02:55)
Ich hör schon, ich hör schon. Wird schon wieder eine ziemliche It-Depends-Folge. Kommt immer darauf an und darauf an und darauf an.
Wolfi Gassler (00:02:55 - 00:02:59)
Aber ... Ich würd mal sagen, die Guten deployen am Freitag.
Andy Grunwald (00:02:59 - 00:03:01)
Du meinst, die eine ordentliche On-Call-Regelung für Samstag haben?
Wolfi Gassler (00:03:02 - 00:03:06)
Die guten Teams deployen am Freitag. Lehnen wir jetzt mal weit aus dem Fenster.
Andy Grunwald (00:03:06 - 00:03:23)
Und ich challenge das so ein bisschen in dieser Episode, denn es gibt nämlich auch Szenarien, wo Großfirmen wie Google, wie Shopify, wie GitHub und Amazon ebenfalls Codefreezes und Deploymentfreezes machen.
Wolfi Gassler (00:03:24 - 00:03:30)
Eben gesagt, die guten, die guten, die bleiben am Freitag, nicht Google, Amazon und so weiter.
Andy Grunwald (00:03:30 - 00:03:42)
Gut, wenn die Jungs nicht gut sind, ich hoffe mal, ich muss zugeben, ich weiß nicht, Disclaimer, ich habe noch nie für Shopify, GitHub, Amazon oder Google gearbeitet, deswegen kann ich nichts über die Testcoverage sagen.
Wolfi Gassler (00:03:43 - 00:03:54)
Also bitte, seitdem Google die, wie war der Spruch? Don't do evil things oder so ähnlich, seitdem dieses Motto gestrichen worden ist, sind sie offensichtlich nicht mehr die Guten.
Andy Grunwald (00:03:54 - 00:04:06)
Ich denke aber, dass deren Monitoring sehr professionell ist und dass da auch die Hiccups, die am Freitag deployed werden, nicht erst am Samstag auffallen. Ich hoffe natürlich auch, dass diese Firmen nicht nur einmal pro Tag deployed werden.
Wolfi Gassler (00:04:07 - 00:04:25)
Du kannst ja auch ein sehr gutes Testing-Team haben, das sich Kunde nennt. Und wenn du so viele Kunden hast, dass du innerhalb von Sekunden merkst, wenn etwas schief geht, weil du einfach Millionen von Kunden hast, dann ist es natürlich auch eine gewisse Art, Rückmeldung zu bekommen und Feedback zu bekommen und dann schnell zu reagieren.
Andy Grunwald (00:04:25 - 00:04:36)
Ich weiß jetzt nicht, ob du diese Kunden, die dir unter Umständen sogar mehrere Millionen pro Jahr einfach mal auf dein Bankkonto schieben, ob du mit denen sowas testen möchtest im Produktionsbetrieb?
Wolfi Gassler (00:04:37 - 00:04:40)
Im Idealfall nicht, aber wird bei vielen Firmen so gemacht.
Andy Grunwald (00:04:40 - 00:05:13)
Kommen wir mal ganz kurz zu dem Thema Codefreezes, Deploymentfreezes. Wir hatten es gerade schon angesprochen. Was ist das? Es geht um einen Zeitraum, wo a, nicht deployed wird und damit meine ich neuen Code auf Produktion geschippt wird oder B, wo auch keine neuen Änderungen in den Main Branch gemerged werden. Sowas nennt man umgangssprachlich Code Freeze, Change Freeze, Deployment Freeze. Es gibt auch Firmen, die nennen sowas Code Slush und Code Chill. Habe ich bei meiner Recherche mehr im amerikanischen Bereich entdeckt.
Wolfi Gassler (00:05:13 - 00:05:14)
Warum denn Slush?
Andy Grunwald (00:05:15 - 00:05:29)
Ja, Code Slush wird mit hoher Wahrscheinlichkeit kein strikter Freeze sein, sondern eher so wie so ein Slush Ice. Du kannst Changes mergen, die jetzt nicht kritisch sind, wie zum Beispiel Changes an Unit Tests oder ähnliches.
Wolfi Gassler (00:05:30 - 00:05:36)
Also, das ist eine super Definition. So wie ein Slush-Eis. Sagt mir das noch weniger. Was ist ein Slush-Eis?
Andy Grunwald (00:05:36 - 00:05:43)
Ein Slush-Eis ist halt kein Getränk. Ist halt so ein halbgefrorenes Getränk. Weißt du, so ein bisschen so eine halbgefrorene Suppe.
Wolfi Gassler (00:05:43 - 00:05:52)
Ah, du meinst, es ist ... Und damit ist es keine harte Verpflichtung, nicht zu deployen, sondern irgendwie so was dazwischen, so was Matschiges.
Andy Grunwald (00:05:52 - 00:06:35)
Genau, also ein Code Slush könnte auch sein, Du enablest das Team und lässt das Team komplett entscheiden, was die mergen und was nicht. Aber da kommen wir dann gleich nochmal ein bisschen zu. Also das ist nicht binär. Das ist sozusagen dein Quantencomputer. Code Slush kann mehrere Zustände haben, wo es normalerweise nur 0 und 1 gibt. Aber wenn ich dich jetzt mal fragen würde, ich meine, ich hab dich gerade gefragt, ob du an einem Freitag deployst und du hast mir auch Gründe genannt, warum oder beziehungsweise wann du an Freitagen deployst und wann nicht. Was würden dir denn für Gründe einfallen, die für einen Code Freeze sprechen? Warum solltest du dein Entwicklungsteam und auch deine Produktinnovation für einen gewissen Zeitraum, ja, man könnte schon fast sagen, fast lahmlegen?
Wolfi Gassler (00:06:36 - 00:07:49)
Ja, die Frage ist ja auch immer, was ist die Alternative? Wenn du jetzt davon ausgehst, von einem Freitagsdeployment, wenn wir jetzt einen Freeze machen übers Wochenende und am Montag deployen, verlierst du wirklich so viel in dieser Zeit? Also verlierst du diesen Pace, diesen Speed, mit dem du neue Sachen auf den Markt wirfst? Hilft dir das wirklich so viel? Also das ist mal eine Grundsatzfrage, die sich mir stellt. Ist es überhaupt nötig und was hat es für Vorteile für das Team? Auf der negativen Seite ist natürlich sicher, wenn du zu wenig Leute hast, in welcher Form auch immer und wann auch immer, die dieses Problem beheben können oder du dann ganz viel zahlen musst, weil du die aus dem Bett scheuchst oder on call Leute da Samstagnacht oder von Freitag auf Samstagnacht irgendwie aus dem Bett läutet und durchrotierst und zehn Leute dann irgendwie probieren, den Fehler zu finden. Das ist teuer. Das ist ungut für die Leute. Die Leute sind vielleicht gar nicht da. Die sind im Urlaub. Also sobald du da ein Problem hast mit den Personen, und das ist halt am Wochenende meistens so, wird es einfach schwieriger, das noch irgendwie zu rechtfertigen, meiner Meinung nach, wenn man es Montag auch machen könnte. Und da geht es jetzt gar nicht um Testing-Pipeline, sondern wirklich, ist es nötig, bringt es mir den Mehrwert?
Andy Grunwald (00:07:49 - 00:07:58)
Okay, also deine Frage ist eigentlich, was bringt es überhaupt für einen Mehrwert, wenn ich freitags deploy und können meine Changes nicht eigentlich auf Montag warten? Ist das richtig? Habe ich das richtig verstanden?
Wolfi Gassler (00:07:58 - 00:08:00)
Genau, warum das Risiko überhaupt eingehen?
Andy Grunwald (00:08:00 - 00:08:35)
Naja, also auf der einen Seite kann man natürlich immer sagen, was ist, wenn freitags noch ein Incident reinkommt, der behoben werden muss, dann musst du ja ein Hotpatch machen und den Hotpatch kannst du natürlich je nach Größe deiner Infrastruktur auch live machen, dann hast du modifizierten Source-Code, auf deinen Live-Servern, aber da kommst du natürlich auf das Environment an. Hast du eine Skript-Sprache, PHP oder Python, ist das relativ einfach. Gehst auf den Server, machst WIM an oder Emacs oder was weiß ich nicht und editierst das. Hast du eine Java-Binary oder eine Go-Binary, Rust-Binary, dann wird's schon wieder ein bisschen hässlich.
Wolfi Gassler (00:08:35 - 00:08:57)
Aber was du jetzt ansprichst, ist, dass du die Möglichkeit hast. Das heißt ja noch nicht, dass es dir einen Mehrwert bringt. Du kannst ja trotzdem die Möglichkeit haben, das schnell zu deployen an einem Freitag und auch sauber durchgetestet und so weiter, deine Pipeline einfach perfekt aufgestellt haben. Aber trotzdem zu sagen, standardmäßig deployen wir nicht, weil das Risiko trotzdem da ist und wir einfach ein gemütliches Wochenende haben wollen.
Andy Grunwald (00:08:58 - 00:10:16)
Klar, der zweite Grund wäre natürlich irgendein Groß-Event oder irgendein Solution-Architekt oder Sales-Manager ist auf irgendeinem Kunden-Event und muss irgendeine wichtige Demo machen und die wird natürlich in Produktion gemacht, denn so ein Sales-Mensch hat in der Regel keine lokale Entwicklungsumgebung auf und hat eine Dev-Branch laufen oder ähnliches. Oder man hat ein großes Sales-Event, AWS Reinvent oder die GitHub Universe. Ja, also und du kennst das doch. Ziemlich viele Features werden oft mit der heißen Nadel gestrickt und man hittet die Deadline vielleicht just in time für das Event. Also da gibt es natürlich schon noch Gründe. Der nächste Grund ist auch Du bist einfach mit deinem Team in einer sehr hohen Geschwindigkeit unterwegs. Und mit sehr hoher Geschwindigkeit meine ich wirklich, du bist es vielleicht gewohnt 4, 5, 20 mal am Tag zu deployen und wirklich konstant die Changes rauszuhauen. Dann ist natürlich ein Tag, an dem du nicht deployst, sind 20 Prozent deiner Deployments stauen sich dann auf. Somit wird natürlich dann das Deployment am Montag deutlich risikoreicher, weil du natürlich 20 Prozent deiner Continuation Changes aufstaust. Also eigentlich könnte man auch fast meinen, jeden Montag zittern viele, weil du dann schon so eine gewisse Art so ein Big Bang Deployment hast.
Wolfi Gassler (00:10:16 - 00:11:18)
Ja, sind natürlich alles faire Punkte und kann ich auch alle nachvollziehen. Meiner Meinung nach geht es aber immer wieder auf eigentlich so ein Grundproblem zurück. Und zwar, wie sicher ist meine Pipeline, mein Deployment-Prozess und wie schnell komme ich auf Fehler drauf und wie schnell kann ich reagieren. Und wenn man sagt, okay, wenn ich jetzt am Freitag deployen würde, Freitag früh, und es nicht schaffe, innerhalb eines Arbeitstages die Fehler zu fixen, dann würde das ja Montag ja auch nicht schaffen. Dann hätte ich das selbe Problem am Montag. Klar, der Dienstag ist der nächste Tag, aber realistisch, wenn ein Problem ist, eigentlich müsstest du dann am Montag noch länger arbeiten. Also dann hast du ein grundsätzliches Problem eigentlich, wie schnell du Fehler bemerkst. Und da stimme ich natürlich vollkommen zu. Das wird ganz oft verwendet als Argument, wenn wir es nicht können, also ein Deployment machen können am Freitag, dann haben wir ein Problem in unserer Pipeline, in unserem Prozess, in unserem Team. Und da stimme ich dir natürlich absolut zu. Das wird oft einfach als Proxy verwendet, als Proxy-Indikator, dass du ein Problem hast, wenn du dich nicht traust, am Freitag zu deployen.
Andy Grunwald (00:11:18 - 00:11:26)
Ich stimme dir schon zu, aber wir leben ja in der Realität, weil ich hab immer noch das Gefühl, du bist wieder auf deiner grünen Wiese, auf deinem.
Wolfi Gassler (00:11:26 - 00:11:29)
Happy Pass, weil... Nehmen wir Städten wie Kuh.
Andy Grunwald (00:11:29 - 00:11:48)
Macht Mo. Ist halt öfter in Österreich so der Fall, ne? Nehmen wir zwei Punkte. Ich würde mal sagen, an einem Montagabend oder Spätnachmittag ist es leichter, deine Arbeitsmannschaft von Überstunden zu überzeugen, als an einem Freitagnachmittag oder einem Freitagabend. Ist gerade nur so ein Bauchgefühl.
Wolfi Gassler (00:11:48 - 00:11:53)
Das ist die eine Baustelle. Aber das geht wieder darauf zurück, dass du ein Problem hast mit deinem Prozess.
Andy Grunwald (00:11:54 - 00:12:22)
Ja, die zweite Baustelle ist, angenommen, wenn du den Luxus hast, in einem Follow-the-sun-Team zu arbeiten, das bedeutet, wenn du in Europa ein Team hast, in Nordamerika oder auch in Südamerika in derselben Zeitzone und dann vielleicht noch irgendwo in APEC in Asien und Pazifik, Das bedeutet Australien, Neuseeland, Japan und so weiter. Dann hast du auch das Problem, dass Freitagabends, wenn Nordamerika den Hammer weglegt, natürlich ist dann auch Wochenende. Dann ist Wochenende weltweit.
Wolfi Gassler (00:12:22 - 00:12:25)
Du gewinnst halt zwölf Stunden oder so was maximal. Oder 24 theoretisch.
Andy Grunwald (00:12:27 - 00:13:18)
Genau, und am Montag kannst du dann einfach übergeben, weil dann die normalen Tagesschichten von denen anfangen. Die zweite Geschichte, das so ein bisschen gegen deinen Punkt spricht, und deswegen sag ich, du bist auf der grünen Wiese mit deiner Kuh, für mich ist Monitoring und Observability ein kontinuierlicher Prozess. Es wird niemals der Fall eintreten, dass du jeden kleinen Schluck auf in jedem Graphen siehst und dass du alles gemonitort hast und die Alerts richtig getweakt hast und was weiß der Geier nicht. Deswegen haben ja auch Top-Firmen wie Google, wie Amazon und wie sie alle heißen auch immer noch Inzidenz, weil die ändern die Plattform ja und müssen dann das Monitoring anpassen und Co. Deswegen, auch wenn du denkst, du hast ein perfektes Sicherheitsnetz durch Monitoring, Observability und Co. und du fühlst dich sicher beim Deployment am Freitag, das ist nie der Fall.
Wolfi Gassler (00:13:18 - 00:14:07)
Aber genau das habe ich ja gemeint. Willst du dieses Risiko eingehen? Also ich gehe davon aus, ein gutes Team hätte die Pipeline und kommt auch sehr schnell auf Fehler drauf, könnte aber sich trotzdem entscheiden, ab Freitag Mittag machen wir kein Deployment mehr, weil wie du sagst, irgendeine Kleinigkeit kann immer schief laufen. Und daher machen wir es erst Montag, weil wir haben keinen, außer klar, wenn da ein Sales Rep irgendwo rumläuft und unbedingt den Change braucht oder der CEO da bei dir über die Schulter schaut, kann das vielleicht mal nötig sein, unbedingt. Aber im Allgemeinen könnte sich das Team oder die Firma ja trotzdem dazu entscheiden, nicht zu deployen. Und da sind wir eigentlich beim Thema, weil sonst würden ja die Großen alle keine Codefreezes machen, die eine unter Anführungszeichen perfekte Pipeline und Deployment-Pipeline besitzen, dann gibt es ja keine Codefreezes bei denen.
Andy Grunwald (00:14:08 - 00:16:16)
Und ich hab mich für diese Episode mal ein bisschen umgeschaut. Was sind denn wirklich die Gründe für einen Codefreeze? Was sind die Gründe, dass auch große Firmen Codefreezes machen, obwohl die eigentlich die technischen Fähigkeiten haben, ein gutes Sicherheitsnetz haben? Auf der einen Seite, den hattest du schon genannt, du hast wenig Leute verfügbar, um kritische Fehler zu beheben. Key-Knowledge-Holder. Ich weiß, wir haben auch ziemlich oft im Podcast über Knowledge-Sharing gesprochen, aber es ist halt auch unrealistisch, dass jeder im Team jede Kleinigkeit weiß. Du wirst immer Leute haben, die Key-Wissen haben. Dann gibt es noch den Punkt, wo Firmen den hundertprozentigen Fokus auf Stabilität setzen und um halt einfach Umsatzeinbußen und Revenue-Einbußen aufgrund von Ausfällen zu minimieren. Da fallen mir so Sachen ein wie Black Friday, Cyber Monday und Co. Kommen wir gleich noch zu. Den dritten Grund, den ich gefunden habe, den hat man gar nicht so auf dem Schirm. Und zwar geht es da um Entlassungen beziehungsweise um Massenentlassungen. Und zwar hatte Twilio, das ist diese Firma, wo du per API Anrufe machen kannst und SMS verschicken kannst und solche Geschichten, die hatten Layoff Announcements. Und vor dem Layoff Announcement haben die einen Code Freeze gemacht. Der Grund war zweierlei. Auf der einen Seite Leute, die ihre Entlassung professionell nehmen, die sagen, okay, Twilio, Venture Capital gebacked, das ist das Spiel, kann funktionieren. Ich nehm das nicht persönlich, ich nehm das professionell. Die könnten gegebenenfalls dazu noch in der Lage sein, ihre großen Changes in Produktion zu shippen oder noch zu merchen, um dann später in ihrem Lebenslauf zu sagen, hey, pass mal auf dieses Keyfeature bei Twilio hab ich gebaut. Ja, ungetestet, beziehungsweise, ich sag mal, so ein Rush, um die letzten Änderungen reinzukriegen. Leute, die dann halt ihre Entlassung nicht so professionell nehmen, die könnten gegebenenfalls noch sich eine Backdoor einbauen. Ist jetzt leichter gesagt als getan bei so einer Firma mit Security und Compliance und allem drum dran, ja? Aber die dann halt, ich sag mal, in irgendeiner Art und Weise in Anführungszeichen Schaden an der Codebase anrichten. Und den Grund, muss ich zugeben, hatte ich nicht auf dem Zettel. Wenn man aber drüber nachdenkt, eigentlich auch nur ein Sicherheitsnetz, oder?
Wolfi Gassler (00:16:16 - 00:16:27)
Haben die das announced, wie sie die Layoffs announced haben, oder war das schon davor announced? Weil da müssen sie ja irgendwie einen Grund angegeben haben, warum sie jetzt ein Code Freeze einfach so irgendwie zufällig machen.
Andy Grunwald (00:16:28 - 00:16:36)
Also, soweit ich das gelesen hab, war das dann halt abgestimmt. Das bedeutet, als sie die Layoffs announced haben, just in dem Moment haben die dann den Code Freeze installiert.
Wolfi Gassler (00:16:37 - 00:16:47)
Könnte man auch wieder argumentieren, wenn du Angst hast um deine Sicherheit, dass da unzufriedene Mitarbeiter Ihnen dann irgendwas Böses machen, dann hast du vielleicht ein Problem mit deiner Security-Pipeline.
Andy Grunwald (00:16:47 - 00:17:15)
Ja, stimmt. Aber du wirst auch immer Leute haben, die die Regeln und auch deine Security-Pipelines übergehen können. Was ist denn, wenn du die Leute aus dem Security-Team, die deine Security-Pipeline bauen, entlässt? Oder zumindest zwei davon. Wenn du die Pipeline baust, kannst du die umgehen. Das ist halt der Fall. Du baust sie ja, ne? Also, merkste? Da irgendwo ist halt ... Ist halt auch die Frage, wer monitort das Monitoring, ne? Du kannst den Stack ja immer höher gehen.
Wolfi Gassler (00:17:15 - 00:17:51)
Also ich glaube grundsätzlich, so Layoffs, ich glaube, da versteht man am ehesten, warum man sowas macht, weil es halt wirklich so ein Event ist, was ganz außerordentlich ist. Wir haben ja mit dem Freitagsdeployment gestartet, aber im Prinzip hast du ja ganz viele ungeplante Events und vielleicht auch geplantere Events, die während dem Jahr passieren, wo man solche Codefreezes vielleicht andenken könnte oder sich Gedanken darüber machen sollte. Und Freitagsdeployments ist ja nur ein kleiner Es gibt ja wirklich viel einschneidendere Erlebnisse wie Events, wie Layoffs oder auch ganz klassisch einfach Ferien, wo vielleicht einfach 90 Prozent der Leute mal chillen wollen.
Andy Grunwald (00:17:52 - 00:18:57)
Ja, und da kommen wir schon in den Punkt, wann macht man eigentlich einen Cold Freeze? Du sagtest ja gerade. Ich glaube, in vielen Firmen wird die Zeit so Weihnachten bis Neujahr oder so als ruhige Zeit erwähnt. Und ich hatte auch schon den Satz gehört, ja, Dezember ist ja sowieso ein langsamer Monat. hatte ich so zuvor noch nicht gehört hat mich so ein bisschen gewundert so nach dem motto aha legt man dann jetzt im dezember fährt man da alles so ein bisschen runter weil ich meine kaum geschäfte werden da gemacht super viele leute sind schon im weihnachtsurlaub weihnachtsstress weihnachtspartys gehen. Naja, war auch neu für mich. Und ich arbeite für eine skandinavische Firma, für eine finnische Firma. Und was ich seit dieser Anstellung gelernt habe ist, zumindest die Finnen nehmen Urlaub ernst. Also ich meine, die nehmen das wirklich ernst. Bei denen ist das so im Mitte Juni, Juli, August. Da sind Leute einfach mal sechs bis acht Wochen weg. Also die nehmen da halt ihren Sommerurlaub. Und in fast jener skandinavischen Firma, so wie ich das jetzt mitgekriegt habe, ist das so. Also ich hab das Gefühl, in ganz Skandinavien legen die den Hammer zur Seite im Sommer.
Wolfi Gassler (00:18:58 - 00:19:01)
Du warst noch nie in Italien zur Ferragosta oder?
Andy Grunwald (00:19:01 - 00:19:02)
Nein, war ich noch nicht.
Wolfi Gassler (00:19:02 - 00:19:12)
Das sind zwei Wochen, wo ganz Italien steht. Da gibt es wirklich nichts. Und du solltest dich nicht auf den Autobahnen befinden, im Idealfall zu dieser Zeit. Es ist irgendwann Mitte August, glaube ich.
Andy Grunwald (00:19:12 - 00:19:34)
Und ich habe immer gedacht, Midsommar ist eine Erfindung von Ikea. Ist aber nicht. Das gibt es also wirklich. Das ist das Midsommarfest in Skandinavien. ist jetzt dieses Jahr wirklich Mitte Juni, 24. Juni. Und ab da beginnt halt deren Sommersaison. Das bedeutet dann für uns, wir überlegen dann, ob wir dann einen Code-Freeze machen oder einen sogenannten Code-Slush.
Wolfi Gassler (00:19:34 - 00:19:36)
Und, was macht ihr?
Andy Grunwald (00:19:36 - 00:20:31)
Im Sommer machen wir öfters wirklich einen Code-Slush. Also, hey, kritische Dinger wirklich nur, wenn du sicherstellen kannst, dass die Leute dann auch da sind und so weiter. Weil wir haben einfach dann weniger Manpower. Andere Events, die eigentlich so in den Sinn kommen, die haben einfach ganz klassisch mit Geld zu tun. Ja, ich rede hier von Black Friday, Cyber Monday. Shopify hat da auch einen Code Freeze. Weil wenn Shopify irgendeinen Bug hat zu Cyber Monday, Black Friday, ich glaube, dann verlieren die halt richtig Asche. Und oft ist das ja wirklich diese zwei Wochen. Die Woche vor Black Friday, die Woche nach Cyber Monday. Die anderen Geschichten sind so Amazon Prime Day, oder die Key-Konferenzen hier, Amazon reInvent, GitHub Universe, Apple WWDC oder halt wirklich auch mal so Fußball-Weltmeisterschaften. Da werden mit hoher Wahrscheinlichkeit die ganzen Streaming-Dienstleister auch sehr, sehr vorsichtig sein, was sie für Änderungen machen.
Wolfi Gassler (00:20:31 - 00:20:42)
Shopify hatte zu der Zeit, glaube ich, 61 Millionen Consumers, wenn ich das richtig sehe, und 4,2 Millionen Dollar Umsatz pro Minute. Sind dann schon ganz gute Größenordnungen.
Andy Grunwald (00:20:43 - 00:21:04)
Pro Minute. Ich glaube, da kann man noch mal ein bisschen Innovationspotenzial ein bisschen runterschrauben, um die 4, irgendwas Millionen pro Minute zu halten. Ja, aber ich meine, das gilt natürlich dann auch für andere große Firmen. Nehmen wir mal Stripe. Mit hoher Wahrscheinlichkeit wird Cyber Monday, Black Friday sehr viel Zahlungsverkehr über Stripe laufen. Ich gehe stark davon aus, dass die da auch versuchen, keine Changes zu machen.
Wolfi Gassler (00:21:04 - 00:21:11)
Und würdest du jetzt als CTO von diesen Firmen auch einen Code Freeze machen? Oder sagst du, die haben Probleme mit ihrer Pipeline?
Andy Grunwald (00:21:11 - 00:22:05)
Nein, da würde ich ganz einfach sagen, ist mir völlig egal, wie gut die Pipeline ist, bei solchen Events, da kann man mal ein bisschen runterschrauben, da machen wir einen Code Freeze, einen Deployment Freeze. Und falls wir doch einen Outage haben, also da würde ich wirklich einen Code Freeze machen und einen Deployment Freeze, denn Da würde ich wirklich sicherstellen, dass der Stand auf Produktion 1 zu 1 mit dem im Main-Branch ist, weil falls du ein Outage hast, damit du sicherstellen kannst, dass du shippen kannst, dass du deployen kannst. Weil wenn du nämlich nur ein Deployment-Freeze hast und die Changes gehen weiter nach Main rein und du hast ein Outage und du musst ein Hotfix machen, natürlich kannst du immer ein Branch machen und bla bla bla, aber wieso in einem Outage diese Komplexität noch einführen, dann würde ich wirklich einen Code-Freeze, einen Merge-Freeze und einen Deployment-Freeze einführen. Weil ich glaube, bei 4,1 Millionen Dollar gehe ich stark davon aus, Transaktionsvolumen pro Minute, also nennen wir mal ein Argument dagegen.
Wolfi Gassler (00:22:05 - 00:22:09)
Aber was wären denn dann Argumente gegen den Code Freeze überhaupt? Gibt es die?
Andy Grunwald (00:22:09 - 00:22:41)
Ja, natürlich. Also ich meine, auf der einen Seite stoppt das Produkt Development komplett, weil meines Erachtens nach bringen Softwareentwickler und Entwicklerinnen erst Value, wenn die Änderung beim Kunden ankommt. Wenn der Kunde, wer auch immer der Kunde ist, diese Änderung auch nutzen kann. All das, was du in deinem Laptop hackst und works on my machine, interessiert überhaupt keinen, solange dieser Code, der geändert wurde, nicht Value beim Kunden liefert. So, und das bedeutet, bei einem Merge Freeze und Deployment Freeze, stoppt das Produkt Development.
Wolfi Gassler (00:22:41 - 00:23:03)
Also das Development stoppt jetzt eigentlich nicht, das kann ja auch weitergehen, aber die Auslieferung zum Kunden stoppt in dem Sinne. Aber du könntest ja argumentieren, okay, dann passiert es halt eine Woche später nach dem Urlaub. Du hast dann klar die Woche verloren, aber du könntest trotzdem noch weiterentwickeln und das Produkt weiterentwickeln und du müsstest jetzt nicht automatisch stoppen, nur weil es nicht ausgeliefert wird. Die Auslieferung wird dadurch verzögert.
Andy Grunwald (00:23:04 - 00:24:04)
Genau, und da kommen wir nämlich zum zweiten Nachteil, wenn du nämlich einen Code Freeze machst. Der Tag nach dem Code Freeze. Die Merge Issues und die Rebase Kopfschmerzen. Stell dir mal vor, du hast ein Team von 20, 30 Leuten und die springen alle auf einem Repository rum. Die Changes staunen sich auf. Größere Changes, weil nicht jeder Change ist, nur zwei Zeilen, führen zu Konflikten. Natürlich hat GitHub jetzt sowas wie eine Merge Queue, alles toll. Aber deine Pull-Requests von vor einer Woche müssen gerebased werden. Dann hast du ein Konflikt und so weiter und so fort. Das bedeutet, da ist nicht einfach, oh, der Code-Freeze ist Ende und wir mergen alles nacheinander durch, sondern weil natürlich sich so viele Changes aufgestaut haben, desto mehr Entwickler du hast, je mehr Changes warten da auf den Merge. Das kann schon zu, ich sag mal, zu Konflikten beim Merge führen und wirklich zu Kopfschmerzen und es kann auch nervig werden. Kennst du das, wenn du machst ein Pool-Request und musst den dreimal rebazen, weil Sachen in der Zwischenzeit gemerged wurden? Ich krieg da immer die Kratzer.
Wolfi Gassler (00:24:05 - 00:24:07)
Du musst nur schneller sein. Der Schnellste gewinnt.
Andy Grunwald (00:24:08 - 00:24:58)
Uh, nächster Nachteil. A rush to get changes in, ja? Oh, mein Change muss als erstes rein, ja? Und, lups, werden die Reviews benachteiligt, vielleicht laufen einige Testpipelines nicht richtig durch, ja? Und dann wird einfach mal auf Merge gedruckt. Jaja, hab ich schon getestet während des Codefreezes. Und dann geht's richtig in die Nachteile. Weil wenn du nämlich ganz viel, ganz schnell so mercht, dann kommen auch locker eine Woche nach dem Merch Rush, nenn ich's mal. Kennst du noch den Gold Rush? Das ist jetzt der Merch Rush. Da kommen dann wirklich die Stabilitätsprobleme, ja? Neue Bugs, unvorhergesehene Verhalten tauchen auf. Nicht jeder Change ging durch manuelle Quality Assurance. Vielleicht ist die manuelle QA dann auch ein Bottleneck. weil du hast ja so einen Merge-Rush.
Wolfi Gassler (00:24:58 - 00:25:03)
Also, du bräuchtest einen Code-Freeze vom Code-Freeze noch mal, um den Merge-Rush zu verhindern.
Andy Grunwald (00:25:03 - 00:25:22)
Du musst dir wirklich überlegen, je nach Teamgröße, je nach Anzahl der Changes, die da warten, gemerged zu werden, wie gehst du damit um? Was ist denn, wenn du ein Monorepo hast? Ein Monorepo und 30 Entwickler, Code-Freeze von drei, vier Tagen, können locker zu über 100 Pull-Requests führen.
Wolfi Gassler (00:25:22 - 00:25:30)
Wobei die ja nicht automatisch im Konflikt stehen müssen. Jetzt nur weil es ein Monorepo ist, kann es ja auch sein, dass die recht unabhängig davon sind, also voneinander sind.
Andy Grunwald (00:25:30 - 00:26:26)
Das ist korrekt, aber was ist denn, wenn das Frontend bereits einen Button eingebaut hat, was noch vom API-Request geht und der API-Request ist noch gar nicht gemerged? Du kriegst natürlich auch neue Abhängigkeiten zwischen den Pull-Requests und die bauen sich dann auf. Es ist auf jeden Fall, es klingt leichter gesagt, als wirklich getan, einen Merge Freeze oder einen Code Freeze einzuführen. Aber was das alles wirklich für Konsequenzen hat, ist oft gar nicht so wirklich sichtbar. Weil du hast jetzt die Stabilitätsprobleme. Du hast den Code Freeze aufgelöst, die Leute fangen an zu mergen, da geht ein Deployment raus, und die nächste Woche bist du erst mal mit Bugfixing beschäftigt. Weil du ja jetzt erst die Änderungen von den anderen kriegst. Vielleicht hast du noch Seiteneffekte. Und eigentlich droppt dann auch die Produktivität für die Woche, nachdem der Codefreeze gelöst wurde. Für alle Hörerinnen und Hörer, der Wolfgang kratzt sich grad am Kopf, weil der denkt so, fuck, das Thema ist da viel komplexer, als ich dachte.
Wolfi Gassler (00:26:26 - 00:26:54)
Ich hab mir gerade überlegt, dass ich eigentlich bei allen meinen Teams, die ich bisher hatte, nie diese Diskussion mit Codefreeze hatte. Vielleicht war das einfach, weil ich immer gesagt habe, macht, was ihr wollt. Macht euch das selbst aus. Ihr müsst gerade stehen am Wochenende. Oder weil das nie so gut diskutiert wurde. Aber es hat natürlich schon weitreichende Folgen. Oder kann weitreichende Folgen haben. Du hattest wahrscheinlich mit allen deinen Teams diese Diskussion. Du warst immer in Ops-Teams. Das war wahrscheinlich immer ein Thema, oder?
Andy Grunwald (00:26:54 - 00:27:15)
Ja, es kommt natürlich immer auf die App an, was hast du, ne? Also, bei Trivago hatten wir mehr oder weniger saisonales Geschäft. Jede Travel-Booking-Website hat saisonales Geschäft. Oft im Sommer, oft im Winter. Und da gibt's natürlich dann auch Peak-Wochen. Und da wurde teilweise nicht deployed, beziehungsweise sehr, sehr selten.
Wolfi Gassler (00:27:16 - 00:27:21)
Ich glaub, meine Teams wollten immer deployen, und ihr aus der Ops-Ecke habt dann immer gesagt, nee, nee, nee.
Andy Grunwald (00:27:22 - 00:27:46)
Jetzt, wo ich bei einem Datenbank-As-a-Service-Provider arbeite, wir betreiben die Infrastruktur für ganz große Firmen, die dann natürlich auch Teil von Black Friday und Co. sind. Wir machen auch Codefreezes, aber unsere Architektur ist auch so gebaut, dass wir natürlich nur für Teilsysteme, also wir können weiter deployen, aber dass wir für Teilsysteme keine Änderung durchführen. Und das ist ganz interessant.
Wolfi Gassler (00:27:46 - 00:27:53)
Ihr habt ja auch nicht einen Mainbranch, ein Produkt, das immer deployed wird, oder? Sondern ihr habt da wahrscheinlich ja auch ganz viel Versionierung drin.
Andy Grunwald (00:27:53 - 00:29:23)
Das ist ja unabhängig vom Produkt, aber da geht es dann eher um Immutable Infrastructure und wie du deine Architektur wirklich machst und was rollst du aus. Also rollst du jetzt zum Beispiel ein Codechange automatisch auf alle existierenden Datenbanken aus oder nur auf eine sogenannte Managementplane? und propagierst den Change dann über Zeit auf deine Services und so weiter. Also da gibt es natürlich dann diverse Deployment-Schritte. Aber was auch faszinierend ist, wir reden jetzt hier immer nur von Web-Applikationen, die wir alle deployen. mal ganz kurz in die Mobile-Ecke gehen und da speziell auf Apple. Apple selbst gibt in der Dokumentation auch an, wenn es gegen Ende des Jahres geht, also jetzt hier Dezember, Weihnachten, dann geben die eine Deadline an, bis wann du dein Final App Release für dieses Jahr bitte submitten sollst, weil vom 22. bis zum 27. Dezember hat Apple auch weniger Ressourcen aka Menschen zur Verfügung, um deine App zu approven. Das bedeutet, du musst auch ein bisschen gucken, falls du Abhängigkeiten von App-Dienstleistern hast, dass du dann auch deine Deadlines entsprechend setzt, dass du dann gegebenenfalls in 2023 noch eine App rausbringen kannst. Vielleicht hast du es schon mal gesehen, viele Apps machen ja früher, wenn du die beim ersten Mal in 24 im neuen Jahr startest, ja hey, schau dir den Progress von 23 an oder Spotify rappt oder was weiß der Geier nicht. Das muss ja auch alles eingebaut und da musst du natürlich dann auch ein bisschen, bisschen hantieren.
Wolfi Gassler (00:29:24 - 00:29:46)
Das war in den guten alten Zeiten natürlich immer einfacher, wenn du dein Produkt als CD ausgeliefert hast und eine neue Version als CD, dann hattest du auch keine Codefreezes. Beziehungsweise eigentlich hattest du trotzdem Codefreezes. Du hattest Featurefreezes und Codefreezes, ab wann du dann wirklich mit dem Testing beginnst und erst dann ist das Ganze released worden oder per CD ausgeliefert worden.
Andy Grunwald (00:29:46 - 00:31:03)
Die gute alte AOL-CD. Jetzt haben wir aber so viel über die bösen Sachen gesprochen, die Nachteile. Und wenn wir jetzt mal über die Vorteile eines Codefree sprechen, da sticht natürlich einer hervor und zwar die Verfügbarkeit und die geringeren Ausfälle. Ich glaube, das ist relativ klar. Facebook hat mal eine gute Studie rausgebracht, ich glaube so 2016 oder 2015 ging die Studie rum. Und zwar haben die mal herausgefunden, was deren Outages eigentlich triggert, also wer ist verantwortlich für diese Outages und dann war die Antwort von dieser Research Study, das sind die Softwareentwickler bei Facebook, denn am Wochenende, als keiner gearbeitet hat, waren hauptsächlich weniger Outages und die Gründe der Outages waren dann meist Hardware-Failure. Und der Rest war primär dann Config Changes. Das heißt natürlich nicht, dass nur wenn du einen Code Freeze oder einen Diplomate Freeze hast, keine Outages passieren können. Es gibt natürlich immer noch sowas wie, wie gesagt, Hardware Failures, Traffic Spikes, wo irgendwie wirklich eine ganze Menge Leute auf einmal kommen. Oder auch, Achtung, deine Dependencies zu anderen Firmen. Google Cloud hat ein Outage, weil du hostest es da. Oder du sprichst mit irgendeinem Tracking-Anbieter und der hat ein Outage. Oder du loggst vielleicht auch deine Fehler nach Sentry und die hatten ein Outage. Also das kann natürlich auch zu Outages führen.
Wolfi Gassler (00:31:03 - 00:31:44)
Wobei, weil du Facebook angesprochen hast, Facebook war ja eigentlich immer berühmt, dass die sich geprüft haben, dass sie alle Entwickler ihnen einfach deployen lassen. Ich glaube, du hattest nur die Auflage, dass mindestens eine andere Person irgendwie in der Firma verfügbar sein musste, die das zurückrollen kann, die reagieren kann, egal wer das jetzt war, wer da zuständig war, aber dann hast du als Einzelperson bereits deployen können. Also dieses Rapid Release, wie sie es genannt haben. Keine Ahnung, ob sie immer noch so flexibel sind und das machen, aber damit haben sie sich eigentlich die letzten Jahre immer gebrüstet, dass sie da einen perfekten Prozess haben und dass sie auch Fehler halt einfach deployen. Kann ja mal passieren.
Andy Grunwald (00:31:44 - 00:31:47)
Du meinst das interne Motto move fast and break things.
Wolfi Gassler (00:31:47 - 00:31:50)
Genau, das hat sich dann natürlich dementsprechend so geäußert.
Andy Grunwald (00:31:50 - 00:31:56)
Wir haben 2024, ich habe gerade mal nachgeguckt, seit 2014 wird das Motto nicht mehr intern verwendet.
Wolfi Gassler (00:31:56 - 00:32:12)
Also die klassischen Papers und Talks rund um dieses Thema habe ich auch so eher in Richtung 2020 gefunden, keine neueren. Also vielleicht sind sie da auch schon ein bisschen von dem Weg abgedriftet. Wenn es jemand weiß, schickt uns gerne in unserer Discord-Community eine Info dazu.
Andy Grunwald (00:32:12 - 00:32:22)
Also soviel ich weiß, haben die wirklich das Motto wohl fallen lassen und es wurde nie ein Grund genannt. Ich spekuliere jetzt einfach mal. Facebook ist einfach zu groß geworden und da steckt dann einfach viel zu viel Geld hinter.
Wolfi Gassler (00:32:23 - 00:32:38)
Ja, wobei die haben natürlich auch immer nur Teile ausgerolltes auf gewisse Anzahl von Benutzern und so weiter. Also die haben natürlich da schon einen sinnvollen Prozess dahinter gehabt. Und ich glaube fast, dass das immer noch in einem ähnlichen Maße zumindest gemacht wird.
Andy Grunwald (00:32:38 - 00:34:08)
Okay, das ist der offensichtliche Grund, warum man gegebenenfalls einen Code Freeze hat. Haben wir ja auch ein bisschen besprochen. AWS Re-Event, Groß-Events, Black Friday, Cyber Monday und so weiter. Bei meiner Research habe ich aber noch zwei andere Gründe gefunden und die finde ich wirklich schön. Und zwar ist ein Code Freeze und ein Deployment Freeze auch in irgendeiner Art und Weise eine explizite Kommunikation, dass du in den Urlaub gehen kannst und 100% disconnecten kannst. Du hast keine Erwartung, irgendwie mit deinem Pager angerufen zu werden oder ähnliches. Jetzt kannst du sagen, als guter Arbeitnehmer, aber weißt du was, Arbeit ist Arbeit, die können mischen mal. Es ist aber auch so, speziell in jungen Firmen, in Startups und Co., dass man halt, ich sag mal, einen Schritt weiter geht und auch mal am Wochenende für die Firma aufsteht. Und da muss ich zugeben, wenn jeder weiß, es ist ein Code Freeze, das ist auch so, disconnecte bitte, lass es sein. Zum Beispiel Spotify hat eine sogenannte Wellnesswoche, soviel ich weiß. Trivago hat das, glaub ich, auch bei Corona eingeführt. Also, es gibt diverse Firmen, die geben ein paar Tage wirklich frei, da wo die ganze Firma frei hat, die ganze. Und der Vorteil ist, da ist auch keine Aktivität per E-Mail, da ist auch keine Aktivität per Slack, weil die ganze Firma frei hat. Ich glaub, viele Firmen haben das während der Pandemie eingeführt, um halt so ein bisschen mit dem Stress auch klarzukommen und diesen wirklich harten Switch von Büro, Homeoffice und den ganzen Tag vor dem Screen hängen und so weiter.
Wolfi Gassler (00:34:08 - 00:34:40)
Naja, früher hat es ganz klassisch Betriebsurlaub geheißen, oder? Wenn du im produzierenden Gewerbe warst, dann sind deine Fabriken stillgestanden und dann hat's Betriebsurlaub gegeben. Gibt's immer noch. Ihr habt einen Freund bei einem großen Konzern, die teure Sachen produzieren. Und der hatte echt Schwierigkeiten scheinbar über die Weihnachtszeit überhaupt arbeiten zu können, weil die halt offiziell da eigentlich Betriebsurlaub haben und dann wird scheinbar auch die Heizung teilweise abgeschaltet und solche Dinge. Also es ist gar nicht so leicht, wenn du als IT-Team abseits von einem produzierenden Gewerbe arbeitest.
Andy Grunwald (00:34:40 - 00:35:04)
Ich habe einen sehr guten Bekannten, der arbeitet bei Daimler in Düsseldorf und da ist das genauso. Der hat ein paar Tage im Jahr, der muss dann Urlaub nehmen. Weil dann irgendwie das Band gewartet wird oder weil die Halle renoviert wird oder ähnliches oder weil die Autos von Verbrennermotor auf Elektromotor, also die Produktion umgestellt wird und so weiter. Also das ist wirklich immer noch so. Ich gehe stark davon aus, die Zeiträume sind jetzt ein bisschen kürzer als früher, hoffe ich zumindest.
Wolfi Gassler (00:35:05 - 00:35:11)
Ich glaube, bei vielen Firmen ist es durchaus noch üblich, dass man einfach so zwei Wochen Betriebsurlaub oder so hat. Gibt es durchaus.
Andy Grunwald (00:35:11 - 00:35:36)
Es gibt aber noch einen Vorteil, den fand ich noch schöner, als diese explizite Kommunikation einfach mal disconnecten. Und zwar während eines Codefreezes hat man endlich mal Zeit zum Nachdenken, Zeit zum Atmen. Man kennt das Feature, Feature, Feature, Feature, Feature. Und wenn man weiß, ich kann nicht deployen, dann kann man natürlich jetzt auch mal ein bisschen Innovation ins eigene Developer-Tooling stecken.
Wolfi Gassler (00:35:36 - 00:35:37)
Kaffee trinken.
Andy Grunwald (00:35:37 - 00:36:02)
Ja, nein. Oder vielleicht einfach mal die sogenannten, man müsste mal Projekte machen. Also es ist halt so eine Änderung in der Geschwindigkeit, in der Entwicklungsgeschwindigkeit, dass man einfach sagt, man geht mal zwei Schritte zurück, was machen wir hier eigentlich? Müssen wir eigentlich mal was umstellen? Man müsste mal. Da war es schon wieder. Wie oft hast du deinen Teams in der Vergangenheit diese Zeit zum Atmen gegeben, während der normalen Feature-Entwicklung?
Wolfi Gassler (00:36:02 - 00:36:30)
Eigentlich des Öfteren, aber wir haben natürlich kein Code Freeze in dem Sinne gemacht, aber wenn man natürlich gewisse Zeiträume genau dafür reserviert oder wie gesagt diese Freitage zum Beispiel reserviert, ist es so ein Klassiker, dann kann man das schon auch machen. Aber ich stimme dir vollkommen zu, wenn man da einen Code Freeze macht, das einfach dementsprechend kommuniziert, da geht es wieder viel um die Kommunikation, dann kann es sehr wohl ein klares Zeichen sein und eine gewisse Wertschätzung, die sicher auch Sinn macht.
Andy Grunwald (00:36:30 - 00:37:05)
Meiner Erfahrung nach ist es halt immer schon so ein bisschen verhandeln, ja, entweder mit irgendwem vom Management oder auch mit eurem Product Manager, Product Owner, weil jeder hat natürlich gewisse Ziele und da ist immer so die Frage, ah ja, eine Woche fürs Refactoring oder man müsste mal oder ja, wenn wir da jetzt ins Developer Tooling investieren, sind wir 50% schneller. Also es ist immer immer so ein Hack-Meck und man muss da schon immer ein bisschen verhandeln und das fühlt sich dann immer so ein bisschen an wie betteln finde ich. Und wenn man halt den Vorteil hat, es wird gerade nicht geployed, dann kann man halt schon einfach mal was mit offizieller Erlaubnis machen anstatt zu betteln.
Wolfi Gassler (00:37:05 - 00:37:29)
Wenn du jetzt sagst, das ist ein gutes Zeichen, was man dem Team gibt, oder auch eine Wertschätzung, wenn man so einen Code Freeze durchführt, dann muss das ja doch schon von recht hoher Ebene entschieden werden, vielleicht sogar company-wide. Wer sollte denn deiner Meinung nach entscheiden, wann ein Code Freeze passiert? Sollte das der CTO machen? Sollte das das Team machen? Gibt es da Unterschiede, je nach Kontext?
Andy Grunwald (00:37:30 - 00:37:49)
Ich sage, ein Code Freeze kann Vorteile haben, kann aber auch einfach Schmerz sein, falls andere Teams einfach ihre Ziele nicht erfüllen können, dann ist es natürlich doof. Aber wer sollte das entscheiden? Schon einer im hohen Management, weil es, wie wir ja schon sagten, es hindert schon die Produktinnovation und das Produktdevelopment stoppt ja schon in einer gewissen Weise.
Wolfi Gassler (00:37:49 - 00:38:04)
Aber wenn du jetzt sagst, mit deinem komischen Eis da, diesem Slush Eis, deinem halb Wasser Zeug, deinem amerikanischen, da entscheidet ja dann das Team, oder? Oder es ist zumindest nicht so hart definiert, was wirklich erlaubt ist und nicht erlaubt ist.
Andy Grunwald (00:38:04 - 00:38:38)
Also es ist natürlich nicht alles schwarz und weiß, wie immer in der Informatik, und es ist auch immer wieder dieses It depends. Du kannst dir auch die Frage stellen, für wen gilt eigentlich ein Code Freeze? Wenn ich jetzt an der Google-Ad-Plattform arbeite, dann wird mit sehr hoher Wahrscheinlichkeit für mich ein Code Freeze gelten, also deutlich strikter, weil über Werbung halt echt viel Geld verdient wird. Wenn ich jedoch an dem internen Tool arbeite, was den aktuellen Kantinenplan per Slack versendet, mit Bildern, dann wird für mich sehr wahrscheinlich kein Code Freeze gelten an Black Friday. Ich weiß, der Kantinenplan ist sehr wichtig in sehr vielen Firmen.
Wolfi Gassler (00:38:38 - 00:38:41)
Ich wollt grad sagen, da kannst du viel, viel Sachen zerstören damit.
Andy Grunwald (00:38:42 - 00:40:29)
Aber es betrifft in der Regel nicht die Revenue-Function der Firma. Und deswegen würde ich mal sagen, dass die meisten internen Produkte in der Regel weitermachen können und vom Code-Freeze nicht betroffen sind. Aber es geht ja jetzt noch weiter. Es geht ja nicht nur auf App-Ebene, sondern auch auf Team-Ebene. Und zwar könnte man fragen, ist ein Merge-Freeze überhaupt ein strikter Merge-Freeze? Das kommt dann immer ganz auf die Kommunikation an. Du kannst natürlich sagen, es wird gar nix gemerkt. dann kannst du das alles ein bisschen aufweichen wie es werden nur kritische fixes gemerged oder die sind die sind erlaubt oder was was wir auch machen wenn du während eines code freezes die unit tests und integration tests verbesserst oder zusätzliche schreibst dann kannst du die auch merken weil die halt in die ci pipeline mit einzahlen aber es so im endeffekt keine produktionsänderung ist Dann gibt's natürlich auch noch so diese Approval-Letter. Wer sagt denn eigentlich, ab wann ein Fix, ein kritischer Fix ist? Wenn du jetzt irgendwelche Career-Levels hast, dann kann das natürlich irgendein Staff-Engineer oder ein Architekt sein. Oder von mir aus auch irgendwie ein Director oder Vice-Präsident oder C-Level, je nachdem, wie groß die Firma ist. Du kannst aber auch sagen, hey Team, ihr entscheidet das selbst. Ihr seid für euren Merchandise komplett verantwortlich. Geht was schief, steht ihr gerade. was auch immer das hier gerade heißt, entweder Überstunden mit fixen und die Plattform wieder ans Leben bringen. Und das ist natürlich auch möglich. Und das ist natürlich Team Empowerment auf oberster Ebene. Also das finde ich natürlich super. Dann musst du natürlich aber auch schon ein sehr erwachsenes Team haben, zumindest ein, zwei sehr erfahrene Leute, die dann also die Faktoren halt mit einbeziehen. Da hattest du ja schon drüber gesprochen.
Wolfi Gassler (00:40:29 - 00:40:34)
Oder sie fliegen halt einfach mal auf die Schnauze. Kann unter Umständen auch nötig sein, damit ein Team das mal lernt.
Andy Grunwald (00:40:34 - 00:40:52)
Ja, aber da habe ich zwei Gegenargumente. Auf der einen Seite, muss das denn sein? Also wie, auf die Schnauze fliegen, wie viel kostet dich das? Und die zweite Geschichte, was ist denn, weil du hast immer Fluktuation in deinen Teams, was ist denn, wenn die Leute, die das Learning auf die Schnauze fliegen mitgenommen haben, dann das Team wechseln?
Wolfi Gassler (00:40:53 - 00:41:06)
Ja, ich würde natürlich niemanden da einfach ins Messer rennen lassen, aber wenn jetzt ein Team ziemlich stur entscheidet, sie wollen das und sie sehen sich darüber aus, wenn dann halt mal was passiert, ja, dann müssen sie es halt auch ausbaden. Das passiert.
Andy Grunwald (00:41:06 - 00:41:52)
Genau, ich glaube, das ist dann die Management-Entscheidung, ob du dein Team damit empowerst und diese Verantwortung dann ans Team gibst. Aber falls dein Team diese Verantwortung hat, die dürfen mergen, was sie wollen im Code Freeze, dann hast du halt, dann würde ich halt schon so ein bisschen die Guidance geben, wie du auch schon bei diesem Freitag Deployment am Anfang besprochen hattest. Was kostet uns denn, wenn wir das erst am Montag shippen? Wie hoch ist das Risiko, dass hier wirklich was schief geht? Und wenn was schief geht, welchen Impact hat das denn? Und ganz wichtig, wie sieht es denn eigentlich mit State Breaking Changes aus? Also ich sage mal Datenbankenmodifikationen und so weiter. Also ist ein Rollback eigentlich so schnell möglich? Oder wird eine neue Datenstruktur automatisch migriert? Weil dann ist natürlich ein Rollback natürlich nicht möglich.
Wolfi Gassler (00:41:53 - 00:42:15)
Ich habe übrigens gerade gestern wieder den klassischen Fehler gemacht und habe ein Delete auf der Datenbank ausgeführt direkt und es hat mich dann glaube ich sechs Stunden oder so gekostet, um meine Backup-Pipeline zu testen und das Recovery zu testen. Also es braucht dann teilweise länger. Man muss sich da im Klaren sein, was kleine Änderungen für Auswirkungen haben können.
Andy Grunwald (00:42:16 - 00:42:19)
Wie lange machst du den Softwareentwicklungsjob schon? In Jahren?
Wolfi Gassler (00:42:19 - 00:42:22)
Viel zu kurz, um nicht immer wieder dieselben Fehler zu machen.
Andy Grunwald (00:42:22 - 00:42:33)
Wir haben jetzt gerade über Erfahrungen gesprochen, über erfahrene Leute, welche Changes die merken sollen. Und jetzt kommst du mit einem meines Erachtens nach doch schon, ich lehne mich jetzt weit aus dem Fenster, Juniorfehler.
Wolfi Gassler (00:42:33 - 00:42:41)
Ja, die mache ich sehr regelmäßig, muss ich sagen, diese Juniorfehler. Unwichtiges Projekt, da kann man sich schon mal zur Datenbank connecten.
Andy Grunwald (00:42:41 - 00:42:44)
Was war es denn? War nicht ordentlich eingegrenzt?
Wolfi Gassler (00:42:44 - 00:42:54)
Nein, in dem Fall hab ich sogar dann irgendeine Tabelle zerschossen. Also das war wirklich so. Da haben noch ein paar andere Sachen mitgespielt, aber auf jeden Fall, ja, war dann gar nicht so leicht.
Andy Grunwald (00:42:54 - 00:43:02)
Bei Wolfgangs Projekt, wovon er erzählt, ging es, geh ich mal stark davon aus, um irgendwas Web- oder cloudtechnisches. Ist das richtig?
Wolfi Gassler (00:43:02 - 00:43:04)
Es war eine interne Webanwendung, also es war nicht mal was Wichtiges, ja.
Andy Grunwald (00:43:05 - 00:45:12)
Aber etwas, was wirklich, ich sag mal, mehr oder weniger täglich released werden kann, oder vielleicht sogar mehr oder weniger in Realtime. Ja, weil all diese Themen mit Codefreeze und so weiter, wir sprechen da jetzt so drüber, wie schlimm es ist oder wie gut es ist und so weiter, und dass man so eine hohe Kadenz hat im Shippen. Aber das trifft natürlich nicht auf jede Produktkategorie zu. Denn man könnte eigentlich sagen, je öfter geschippt wird, je öfter deployed wird, desto relevanter kann ein Codefreeze werden. Web und Cloud sind natürlich ganz vorne dabei, an der Schlagzahl mit den Deployments. Continuous Deployment, Continuous Delivery und Co. Aber wenn wir jetzt mal über Native Mobile oder Native Desktop-Apps reden, oder vielleicht auch so gesagt Webbrowser selbst, die werden ja eher im wöchentlichen Rhythmus oder vielleicht sogar im monatlichen Rhythmus released. Ähnlich sieht's aus mit Libraries, Frameworks oder, Achtung, On-Premise-Software, die dein Ops-Team, der sogenannte Betrieb, noch selbst hostet und selbst managt. Wenn es da jedes Quartal mal ein Update gibt, auch super. Jetzt kommen wir aber langsam in die Gebiete, wo Merge-Freezes und Deployment-Freezes nicht mehr so relevant sind. Nehmen wir mal Embedded Systems oder Operating Systems. Ich hab mir mal den Release-Zyklus von Mac OS X rausgesucht und Mac OS X wird einmal pro Jahr released. Also einmal pro Jahr shippen die eine Major-Version, Snow Leopard und wie sie alle heißen, und dann ein paar mal im Jahr Security-Fixes und Co. Und für die ist das natürlich völlig irrelevant, weil, offengesprochen, weil die einmal im Jahr eine Major-Version releasen, haben die eigentlich das ganze Jahr Deployment-Freeze. Und die Iteration ist dann natürlich deutlich, deutlich geringer. Sieht natürlich dann ebenfalls für spezielle Termine für ein Release aus oder bei sogenannten Quote-unquote Enterprise-Produkten, weil Enterprise ist ja oft auch übersetzbar mit langsam oder wir brauchen etwas Zeit. Deswegen, Wolfgang, denkst du dir ab und zu, dass du in der falschen Industrie bist? Wäre das nicht alles ein bisschen angenehmer, wenn du in der Embedded- oder Operating-System-Industrie wärst?
Wolfi Gassler (00:45:12 - 00:45:38)
Ich bin so alt, ich komme aus der Softwareentwicklungszeit, wo das ganz normal war, solche Release-Zyklen. Man hat sowieso nur alle paar Monate mal released. Ich bin heilfroh, da draußen zu sein und über Web einfach schnell was deployen zu können und einen Fix zu machen und keine CD herumschicken zu müssen. Oder noch schlimmer, du hast eine Software geschrieben, die auf der CD gelaufen ist, irgendeine Präsentationssoftware oder sowas. Da hattest du gar keine Chance, irgendwas zu fixen.
Andy Grunwald (00:45:38 - 00:45:40)
Ja, Fluch und Segen kann es sein.
Wolfi Gassler (00:45:40 - 00:46:08)
Aber einen Punkt, den wir jetzt noch nicht besprochen haben, wenn es um Codefreezes geht, und zwar betrifft das eigentlich vor allem die Management-Ebene, beziehungsweise die Ebene, die auch entscheidet, dass es Codefreezes gibt. Denn man muss das Ganze ja auch kommunizieren, und zwar sinnvoll kommunizieren, dass das ankommt und dass das auch die Auswirkungen hat, die man erreichen will. Also wenn man jetzt zum Beispiel eben irgendeine Wertschätzung ausdrücken will durch CodeFreeze, dann muss man das natürlich anders kommunizieren oder vielleicht irgendwie unterstreichen, dass das auch ein wichtiger Grund ist.
Andy Grunwald (00:46:08 - 00:47:31)
Ja, da kommen wir natürlich zur Achillesferse der ganzen Thematik. Kommunikation ist ja immer schwierig. Also wie macht man eigentlich die Kommunikation und auch die Durchführung? Weil da gibt es nämlich auf der einen Seite nur, wie informiert man denn seine Belegschaft? Wir machen CodeFreeze. Auf der anderen Seite, wie führt man den eigentlich durch? Je mehr Informationen in dieser Kommunikation drin sind, warum machen wir den Codefreeze? Wann machen wir den? Es ist sehr, sehr vorteilhaft, die Leute nicht zu überraschen und sagen, in fünf Minuten starten wir einen Codefreeze, denn Slack ist auch asynchrone Kommunikation und viele Leute hoffen auch noch auf das heutige Deployment und Code. Warum machen wir den Code Freeze? Wie lange hält dieser an? Wer ist eigentlich dafür verantwortlich? Und wer kann eine Approval geben, um Changes doch zu merchen? Wie sieht die Strategie aus, wenn der Merge Freeze wieder aufgehoben wird? Welche Changes gehen wann rein? Nutzt man vielleicht GitHub Merge Queue, um die nacheinander zu stacken? Oder hat man dieses Team Empowerment und sagt, okay, jedes Team ist für sich verantwortlich. Da kommt man wirklich ganz drauf an, was habt ihr für eine Architektur, Microservices oder nicht, was für ein Technologiestack, welche technischen Möglichkeiten habt ihr und ist es überhaupt realistisch, dass die eigenen Teams das selbst für sich entscheiden oder geht da generell ein monolithisches Diplom mit raus.
Wolfi Gassler (00:47:32 - 00:48:10)
Wichtig ist meiner Meinung nach auch, weil du Teams sagst, zum Team gehören auch die ganzen Produktleute. Also das ist kein Problem der technischen Leute, sondern da gehört Produkt dazu, Design, alle Testing, alle die in irgendeiner Form mitwirken, weil ihr habt es selbst schon erlebt, es wird dann irgendwo auf der technischen Ebene kommuniziert und Das DevOps-Team sagt, okay, ab jetzt Code-Freeze und so weiter. Und irgendwann kommt dann ein Product-Owner und sagt, hey, wir brauchen unbedingt dieses Feature. Und dann sagt das Team, ja, wir haben ja Code-Freeze, hast du nicht gewusst? Und darum muss das einfach auf einem Level basieren, dass das wirklich alle mitbekommen. Und es betrifft halt sehr, sehr viele Leute und nicht nur die EntwicklerInnen.
Andy Grunwald (00:48:10 - 00:48:39)
Wenn ich das nicht klar ausgedrückt hab, das ist eine firmenweite Kommunikation. Denn auch diese Leute, die dann das Software verkaufen, also Sales- und Solution-Architekts, die müssen das auch wissen. Weil Kunden wollen irgendwas. Oder ihr habt noch Konfigurationen, die deployed werden müssen. Wenn wir von Code-Freeze und Deployment-Freeze sprechen, dann sprechen wir auch von Konfigurationssettings, die vielleicht kein richtiges Code-Deployment brauchen, aber ein Ansible-Deployment oder was weiß ich nicht. Auch so was ist dann gefreezed.
Wolfi Gassler (00:48:40 - 00:49:27)
Schwierig ist es einfach, wenn es jetzt keine firmenweite Entscheidung ist, sondern eben du hast da deinen Wassereis-Approach, da irgendeinen Slush-Approach und manche Teams machen was, manche Teams machen nichts und da ist dann halt keine professionelle Kommunikation unter Umständen im Hintergrund, weil es eben nicht von ganz oben kommt und dann durchdesignt ist die Kommunikation, sondern es entscheidet sich ein Team für einen Code-Freeze über Weihnachten und dann müssen halt auch die angrenzenden Teams informiert werden oder wie gesagt, wie mit Ausnahmen umgegangen wird und so weiter. Also umso weiter unten das entschieden wird, umso schlechter ist meistens die Kommunikation, weil es da halt keine professionelle Kommunikationsstelle gibt und dementsprechend muss das halt auch sinnvoll kommuniziert werden. Darum immer gute Idee, die Product-Leute einzubinden, weil die meistens sehr kommunikationsstark sind und es gewohnt sind, einfach Sachen nach außen tragen zu müssen.
Andy Grunwald (00:49:27 - 00:51:27)
Meines Erachtens nach sollte das wirklich jemanden vom oberen Management kommunizieren, damit das auch, ich sag mal, ein gewisses Gewicht hat. Jetzt ist die Kommunikation durch, jetzt kann man aber auch sagen, okay, wie macht man das denn jetzt technisch? Also auf der einen Seite kannst du natürlich auch sagen, du kannst alle Teams bitten, nicht zu deployen. Du kannst sagen, bitte nicht auf den Merge-Knopf drücken. Oder du kannst natürlich technische Änderungen machen, um die ganze Sache wirklich aktiv zu verhindern. Also davon rede ich, stopp die Deployment-Pipeline, deaktiviere diese, verbiete Merges in den Main-Branch, also entferne vielleicht sogar Schreibrechte zum Repository. Da muss man ein bisschen aufpassen, da kannst du natürlich auch keine Branches und auch keine Pull-Requests mehr pushen. Also wie realisierst du die ganze Thematik technisch? Und da kommt es jetzt wieder auf die Detailimplementierung an. Wenn du deine Deployment-Pipeline stoppst, Stoppst du dann auch automatisch deine Deploys auf deine Staging-Environments? Oder was passiert, wenn du doch während des Merge-Freezes ein Hotfix oder ein Emergency-Deploy machen musst? Wie schnell kannst du die ganze Sache wieder reaktivieren? Und während eines Code-Freezes muss natürlich auch das Audit-Logging funktionieren. Wenn es einen Manual-Override gibt, wenn ich, Wolfgang, als Staff-Engineer deinen Change trotzdem approve, das muss ja irgendwo gelockt werden, dass wir innerhalb eines company-weiten Code-Freezes einen Deploy machen. Weil wenn dieser Deploy dann am Black Friday ist und uns Millionen kostet, 4, schieß-mich-tot-Millionen-pro-Minute bei Shopify haben wir grad gehört, glaub mir, dann sollte das Audit-Logging da stimmen. Denn da geht's nicht um Blaming, sondern eigentlich, warum, wann, damit man den ganzen Postmortem machen kann. Also, das ist viel komplexer, als man eigentlich denkt. Und weil die ganze Thematik so komplex ist, bringen wir das Thema jetzt. Denn was steht uns bevor? Die Sommerferien stehen uns bald bevor. Und bis zum November, bis zum Black Friday und Cyber Monday sind auch noch ein paar Monate. Somit habt ihr alle genug Zeit, das zumindest noch mal im Team anzusprechen.
Wolfi Gassler (00:51:27 - 00:52:35)
Mir hat diese Episode auf jeden Fall schon was gebracht, weil ich werde es in Zukunft auf jeden Fall auch klarer definieren, dokumentieren und kommunizieren. Es hat zwar immer gut geklappt, muss ich dazu sagen, dieses ihr macht schon, aber da waren auch sehr viele Leute beteiligt und wahrscheinlich hat es einfach gut funktioniert, weil es irgendwer anderer übernommen hat. Aber ich glaube, wenn man es einfach macht, sich mal Gedanken darüber zu machen, es gut aufzuschreiben, dokumentieren, zu besprechen im Team und dann zu exekutieren. Aber ich glaube, es ist kein Hexenwerk, aber umso besser man das natürlich macht und umso geplanter man das einfach macht, umso mehr kann man auch rausholen aus dem Ganzen. Weil bisher hat man vielleicht Codefreezes einfach so gemacht, aber ich glaube, es gibt halt sehr viele Vorteile, die man vielleicht noch mitnehmen kann, dass es eben auch motivierend wirkt, dass es gut kommuniziert ist, dass die Leute wissen, okay, sie haben jetzt Pause. Also diese ganzen Dinge, die da noch mitschwirren und mitschwingen, die sollte man einfach auch mitnehmen, weil das sind positive Dinge. Und wenn man das einfach klar kommuniziert und definiert, hat man vielleicht auch einfach ein glücklicheres Team am Ende. Ich glaube, es ist auch einfach Teil einer Tech-Kultur und gehört da zu einer guten Kultur dazu.
Andy Grunwald (00:52:35 - 00:53:03)
Lasst uns doch mal wissen, wie ihr über Freitagsdeployments denkt, über Codefreezes und welche Erfahrungen ihr mit Codefreezes gemacht habt. Wurden die so bildebuchartig durchgeführt, wie wir es hier besprochen haben, oder war es einfach totales Chaos? Das könnt ihr uns natürlich über alle Social-Media-Kanäle, LinkedIn, Twitter oder auch Mastodonen zukommen lassen. Oder falls ihr mehr Realtime-Kommunikation bevorzugt, kommt doch einfach in unsere Discord-Community. In den Shownotes findet ihr den Discord-Invite-Link.
Wolfi Gassler (00:53:04 - 00:53:17)
Jetzt habe ich noch eine ganz wichtige Frage, Andi. Wenn jetzt alle von ihren 40 Stunden auf 32 Stunden auf Teilzeit zurückgehen, weil ja die 4-Tages-Woche eigentlich die Zukunft ist, wird dann das Freitag-Deployment des Donnerstags Deployment?
Andy Grunwald (00:53:17 - 00:53:28)
Ah, ich denke nicht, weil ich denke eher, dass dann das Team geteilt wird, dass die Ersten von Montag bis Donnerstag arbeiten und die zweite Gruppe von Dienstag bis Freitag.
Wolfi Gassler (00:53:28 - 00:53:30)
Bist immer so langweilig, so eine ernste Antwort.
Andy Grunwald (00:53:30 - 00:53:35)
Wenn du so scheiß Fragen stellst. Stell intelligente Fragen.
Wolfi Gassler (00:53:35 - 00:53:39)
Ich bin nicht in diesem Podcast, um intelligente Fragen zu stellen.
Andy Grunwald (00:53:39 - 00:53:42)
Das war's wieder von uns. Bis zum nächsten Mal. Tschüss. Ciao.