1 00:00:00,320 --> 00:00:03,880 Das Weihnachtsgeschäft oder die nächste wichtige Konferenz steht 2 00:00:03,880 --> 00:00:05,880 bevor. Dann heißt es für kritische 3 00:00:05,880 --> 00:00:09,360 Software oft Code Freeze. Aber ist das überhaupt noch 4 00:00:09,360 --> 00:00:13,040 zeitgemäß oder ist das nur ein Symptom dafür, dass die eigene 5 00:00:13,040 --> 00:00:15,120 Delivery Pipeline nicht reif genug ist? 6 00:00:15,360 --> 00:00:19,240 Und falls man das braucht, was umfasst das alles und wie setzt 7 00:00:19,240 --> 00:00:21,760 man den Code Freeze auch technisch und organisatorisch 8 00:00:21,760 --> 00:00:23,840 vernünftig um? Darüber sprechen wir in dieser 9 00:00:23,840 --> 00:00:26,960 Folge und am Ende gibt es sogar eine Chatliste zum Selbermachen, 10 00:00:27,040 --> 00:00:34,560 viel Spaß. Und damit herzlich Willkommen zu 11 00:00:34,560 --> 00:00:37,760 Folge 141 des To do Developer Podcast, Eurem deutschsprachigen 12 00:00:37,760 --> 00:00:41,280 Developer Podcast auf allen Plattformen. 13 00:00:43,360 --> 00:00:46,400 Und ihr hört wie immer Robin Manuel Thiel und mich. 14 00:00:46,400 --> 00:00:50,240 Malte lantin ich bin Strategic Solution S Engineer bei Github 15 00:00:50,240 --> 00:00:53,640 und Robin Manuel ist Director I und Cloud beim E Commerce 16 00:00:53,640 --> 00:00:56,640 Software Unternehmen Jtl, aber den Podcast machen wir natürlich 17 00:00:56,640 --> 00:00:59,840 wie immer privat und in unserer Freizeit, sprechen aber hier 18 00:00:59,840 --> 00:01:03,200 über unsere Erfahrungen aus echten Projekten, an denen wir 19 00:01:03,200 --> 00:01:08,160 tagtäglich arbeiten und heute gehen wir ganz tief in das Thema 20 00:01:08,160 --> 00:01:11,920 Code freezes ein, aber eigentlich vielleicht. 21 00:01:12,320 --> 00:01:15,840 Doch nicht geht es eigentlich um Code, freezes und geht es darum, 22 00:01:16,160 --> 00:01:19,120 dass wir wirklich den Code einfrieren wollen oder wollen 23 00:01:19,120 --> 00:01:22,200 wir eigentlich uns nur absichern, um halt in kritischen 24 00:01:22,200 --> 00:01:24,720 Momenten eine lauffähige Applikation zu haben? 25 00:01:25,360 --> 00:01:27,840 Das ist die Frage und deswegen starten wir erstmal mit den 26 00:01:27,840 --> 00:01:32,080 Szenarien, wann eigentlich so ein sogenannter Code Freeze 27 00:01:32,080 --> 00:01:33,840 relevant wird. Ja, meistens ja. 28 00:01:33,840 --> 00:01:36,720 Dann, wenn ich irgendwie ganz, ganz sicher gehen muss, dass 29 00:01:36,720 --> 00:01:39,520 jetzt gerade in dem Moment nichts schief läuft in meiner. 30 00:01:39,920 --> 00:01:42,320 Applikation in meiner Infrastruktur oder was auch 31 00:01:42,320 --> 00:01:43,680 immer ich da irgendwie bereitstelle. 32 00:01:43,680 --> 00:01:46,400 Wir haben es ja gerade im Intro schon gesagt, wenn ihr diese 33 00:01:46,400 --> 00:01:49,040 Folge hört, dann habt ihr den Black Friday gerade verpasst. 34 00:01:49,360 --> 00:01:51,480 Ich weiß gar nicht, ist Cyber Monday ist das diesen Montag 35 00:01:51,480 --> 00:01:53,640 oder war das letzten Montag? Ich bin in diesem ganzen Deals 36 00:01:53,640 --> 00:01:55,760 Ding gar nicht gar nicht so wahnsinnig tief drin, was aber 37 00:01:55,760 --> 00:01:57,280 auf jeden Fall gekommen ist. Zum Beispiel das 38 00:01:57,280 --> 00:01:59,680 Weihnachtsgeschäft. Und das sind so ganz klassische 39 00:01:59,680 --> 00:02:01,600 Stellen, wo man zumindest irgendwie, wenn man im E 40 00:02:01,600 --> 00:02:03,920 Commerce unterwegs ist, auf jeden Fall sicher gehen will, 41 00:02:04,080 --> 00:02:06,640 dass alles gut läuft. Es gibt aber auch ganz viele 42 00:02:06,640 --> 00:02:09,520 andere Termine quasi im Jahr, das ist dann auf der 43 00:02:09,520 --> 00:02:12,520 Unternehmensabhängig, das kann kurz vor einer großen Konferenz 44 00:02:12,520 --> 00:02:15,040 sein, wo ein Produkt ankündigt oder wo man einfach generell mit 45 00:02:15,040 --> 00:02:18,480 viel Aufmerksamkeit rechnet, dass man sich einfach, dass man 46 00:02:18,480 --> 00:02:21,280 sicher gehen muss, hey, wir bauen jetzt nicht durch ein 47 00:02:21,280 --> 00:02:24,000 Update, durch einen Patch, durch irgendeinen Deployment, einen 48 00:02:24,000 --> 00:02:26,480 Bug, ein, einen Fehler ein und so weiter. 49 00:02:26,960 --> 00:02:30,400 Ja, und die Frage ist Halt, ist das heute noch zeitgemäß, 50 00:02:30,400 --> 00:02:33,520 wirklich den Code einzufrieren, weil wir sind ja in einer Welt, 51 00:02:33,520 --> 00:02:37,120 wo wir Continuous Delivery machen, und ich glaube, 52 00:02:37,120 --> 00:02:40,720 dementsprechend nutzen halt viele Unternehmen mittlerweile 53 00:02:40,720 --> 00:02:44,480 den Begriff Code Freeze gar nicht mehr so häufig, auch wenn 54 00:02:44,480 --> 00:02:47,200 er immer noch sehr populär ist, sondern man spricht häufiger 55 00:02:47,200 --> 00:02:50,640 auch irgendwie über einen Change Freeze oder vielleicht auch 56 00:02:50,640 --> 00:02:53,800 einen Deployment freeze, also. Ja oder so, Change Windows und 57 00:02:53,800 --> 00:02:56,320 so was, das kommt alles so aus dieser ITIL und Change 58 00:02:56,320 --> 00:02:58,400 Management Ecke, das macht dann halt oft klar, es geht ja 59 00:02:58,400 --> 00:03:02,280 heutzutage um gar nicht mehr nur noch um Code sondern um jede 60 00:03:02,280 --> 00:03:04,640 Änderung an einem produktiven System, auch so wie eine 61 00:03:04,800 --> 00:03:08,280 Datenbank Schema Migration oder irgendwie DNS Einträge ändern, 62 00:03:08,280 --> 00:03:10,720 das mache ich jetzt vielleicht nicht unbedingt vorm 63 00:03:10,720 --> 00:03:13,200 Weihnachtsgeschäft, auch wenn ich das theoretisch natürlich. 64 00:03:13,880 --> 00:03:16,280 Ich auch vorher in verschiedenen Umgebungen gut teste und so was, 65 00:03:16,280 --> 00:03:18,760 aber es bleibt ja halt immer so ein kleines Restrisiko und 66 00:03:19,040 --> 00:03:21,680 deswegen guckt man sich das an. Ich glaube Code Freeze ist 67 00:03:21,680 --> 00:03:24,800 trotzdem immer noch so der am weitesten verbreitetste Begriff, 68 00:03:25,840 --> 00:03:28,200 aber heute spricht man natürlich auch von anderen Dingen, wie es 69 00:03:28,200 --> 00:03:30,720 gibt mit Configuration Freezes, Deployment Freezes oder man sagt 70 00:03:30,720 --> 00:03:34,640 eben generell so so ein Change Freeze, dass man halt irgendwie 71 00:03:34,640 --> 00:03:36,200 darunter versteht. Hey, wir machen jetzt keine 72 00:03:36,200 --> 00:03:38,640 Änderungen, weil sie eben zu risikoreich sind. 73 00:03:38,800 --> 00:03:41,040 Ein klassischer Code Freeze heißt ja, dass. 74 00:03:41,360 --> 00:03:44,680 Zumindest, wenn wir jetzt in der Git Terminologie sind, dass wir 75 00:03:44,680 --> 00:03:47,440 auf unserem Hauptbranch keine Änderungen durchführen 76 00:03:48,080 --> 00:03:51,280 beziehungsweise nur kritische Fixes, die wir tatsächlich 77 00:03:51,280 --> 00:03:54,280 brauchen, um unsere Anwendungen lauffähig zu halten. 78 00:03:54,280 --> 00:03:57,080 Wenn ein Bug auftritt, müssen wir den natürlich fixen, aber 79 00:03:57,080 --> 00:03:59,680 wir machen keine Änderungen mehr, wir schippen keine neuen 80 00:03:59,680 --> 00:04:03,440 Features mehr und das kommt ursprünglich ja aus der Welt, wo 81 00:04:03,440 --> 00:04:06,080 wir tatsächlich noch eine bestimmte Version der Software 82 00:04:06,080 --> 00:04:09,240 fertiggestellt haben, die wir zum Kunden ausgeliefert haben. 83 00:04:09,680 --> 00:04:12,800 Also ganz klassische Selbstbetriebene Software, 84 00:04:12,960 --> 00:04:17,360 dementsprechend in der saas Welt gibt es ja eigentlich keine 85 00:04:17,360 --> 00:04:21,680 klassischen Code freezes auf bestimmten Versionen mehr, weil 86 00:04:21,680 --> 00:04:26,360 wir ja tatsächlich regelmäßig Updates liefern, dann unsere 87 00:04:26,360 --> 00:04:29,200 Kunden und diese werden ja in der Regel nicht mit einer 88 00:04:29,200 --> 00:04:33,200 bestimmten Versionsnummer bestückt, von daher ist ja mal 89 00:04:33,200 --> 00:04:36,400 die Frage was. In welcher Art von Software bin 90 00:04:36,400 --> 00:04:38,640 ich jetzt hier unterwegs, wenn ich immer noch klassische 91 00:04:38,640 --> 00:04:41,280 Versionierung mache, mache ich vielleicht noch Code freeze, 92 00:04:41,280 --> 00:04:44,400 aber jetzt nicht aus dem Grund, den du gerade genannt hattest. 93 00:04:44,400 --> 00:04:46,520 Dass ich zum Beispiel irgendwie eine sehr kritische Zeit des 94 00:04:46,520 --> 00:04:49,200 Jahres habe, sondern ich mache diesen Code freeze, weil ich 95 00:04:49,200 --> 00:04:51,520 weiß. Das ist jetzt Version x. 96 00:04:51,520 --> 00:04:54,720 Die wird zum Kunden ausgeliefert und dementsprechend kann ich 97 00:04:54,720 --> 00:04:57,280 jetzt keine neuen Features mehr hinzufügen, weil vielleicht noch 98 00:04:57,280 --> 00:04:58,960 letzte Tests durchgeführt werden müssen. 99 00:04:58,960 --> 00:05:02,320 Auf dieser Software und dann soll diese Software sich nicht 100 00:05:02,320 --> 00:05:05,040 noch weiter verändern. Ganz früher wurde das Ganze 101 00:05:05,040 --> 00:05:07,920 immer noch irgendwie auf DVD, CD oder einen anderen Datenträger 102 00:05:07,920 --> 00:05:10,320 gebracht und dann zum Kunden ausgeliefert, da war es 103 00:05:10,320 --> 00:05:13,680 natürlich noch kritischer. Aber wie gesagt, heute immer 104 00:05:13,680 --> 00:05:16,680 noch bei der Software, die selbst betrieben wird, durchaus 105 00:05:16,680 --> 00:05:19,520 ein relevantes Konzept, aber darum soll es ja eigentlich gar 106 00:05:19,520 --> 00:05:21,960 nicht gehen, sondern wir reden jetzt darüber, dass unsere 107 00:05:21,960 --> 00:05:26,080 Software stabil laufen soll, wenn es drauf ankommt und dafür 108 00:05:26,080 --> 00:05:29,120 ist natürlich gerade so in der SARS Welt das Thema Deployment 109 00:05:29,120 --> 00:05:31,360 Freeze relevant. Ja, der alte Mann erzählt hier 110 00:05:31,360 --> 00:05:34,520 von früher, wo man noch Software wirklich auf Datenträgern an die 111 00:05:34,520 --> 00:05:37,160 Kunden geschippt hat. In der in der modernen SARS und 112 00:05:37,160 --> 00:05:39,040 Cloud Welt, da reden wir natürlich, wie du gerade gesagt 113 00:05:39,040 --> 00:05:40,400 hast, eher von einem Deployment Freeze. 114 00:05:40,400 --> 00:05:43,880 Das hat den großen Vorteil die Entwicklung und Merges von 115 00:05:43,880 --> 00:05:48,560 meinem Code laufen eben weiter, aber ich will keine Deployments 116 00:05:48,560 --> 00:05:51,160 mehr in Produktion haben, das heißt ich schaue da eher, dass 117 00:05:51,160 --> 00:05:54,160 ich sage okay, wir haben jetzt einen Stand, mit dem gehen wir 118 00:05:54,160 --> 00:05:58,080 jetzt durch diese entsprechende kritische Zeitspanne, diese 119 00:05:58,080 --> 00:06:00,240 Periode, wo wir jetzt sagen, wir machen da keine Änderungen, ich 120 00:06:00,240 --> 00:06:01,920 kann natürlich trotzdem weiterentwickeln, das ist halt 121 00:06:01,920 --> 00:06:03,600 der große Vorteil meiner Development Teams. 122 00:06:03,920 --> 00:06:07,360 Arbeiten weiter, aber ich mache eben keine Deployments mehr und 123 00:06:07,360 --> 00:06:10,680 eigentlich geht damit auch immer einher ein Configuration Freeze, 124 00:06:10,680 --> 00:06:12,800 das heißt ich habe auch keine Änderungen mehr an meinem 125 00:06:13,200 --> 00:06:17,200 Hosting Provider oder an meiner Cloud Infrastruktur, sondern 126 00:06:18,080 --> 00:06:20,320 fokussiere mich halt auf maximale Stabilität. 127 00:06:20,480 --> 00:06:23,040 Ja, und tatsächlich? Dieses Konzept ist Deployment 128 00:06:23,040 --> 00:06:26,000 Freeze und Configuration Freeze kannte ich vorher schon, aber 129 00:06:26,000 --> 00:06:27,920 jetzt haben wir uns natürlich so ein bisschen in das Thema noch 130 00:06:27,920 --> 00:06:31,000 weiter eingelesen und was ich ganz interessant fand, dass es 131 00:06:31,000 --> 00:06:33,800 wohl auch den Begriff des Code slush oder? 132 00:06:33,880 --> 00:06:37,880 Oder Code chill gibt also irgendwie dieses Slush ice, wo 133 00:06:37,880 --> 00:06:40,240 man irgendwie ein Eis hat, aber es ist nicht ganz fest, sondern 134 00:06:40,240 --> 00:06:42,560 irgendwie noch flüssig und das soll so ein bisschen 135 00:06:42,560 --> 00:06:45,440 beschreiben, dass man so ein bisschen weicheren Ansatz wählt 136 00:06:45,680 --> 00:06:50,080 und vielleicht weiterhin Änderungen in Produktion stellen 137 00:06:50,080 --> 00:06:52,800 kann, aber das sind nur Änderungen, die Halt als Low 138 00:06:52,800 --> 00:06:56,200 Risk klassifiziert sind, das heißt Änderungen, die nicht zu 139 00:06:56,200 --> 00:06:58,720 einem Totalausfall meines Systems führen können. 140 00:06:58,760 --> 00:07:00,560 Wobei, da muss man, glaube ich sagen, das ist, glaube ich, die 141 00:07:00,640 --> 00:07:02,800 höchste Kunst davon. Wir werden uns ja gleich in der 142 00:07:02,800 --> 00:07:03,800 Folge so ein bisschen anschauen und. 143 00:07:04,160 --> 00:07:06,080 Wie man das umsetzen kann, so einen Freeze. 144 00:07:06,080 --> 00:07:08,800 Und natürlich ist es deutlich einfacher, einen harten Cut 145 00:07:08,800 --> 00:07:12,120 umzusetzen und der ist schon nicht einfach umzusetzen als so 146 00:07:12,120 --> 00:07:16,320 eine leichte Variante, weil da die Teams eben selber 147 00:07:16,320 --> 00:07:18,640 entscheiden müssen, wie risikoreich sind welche 148 00:07:18,640 --> 00:07:22,120 Änderungen und da kann ich mir gut vorstellen, dass die Teams 149 00:07:22,120 --> 00:07:25,040 selber vielleicht oft gar nicht die besten Personen sind, um 150 00:07:25,040 --> 00:07:28,000 genau das zu entscheiden, weil wenn wir über solche kritischen 151 00:07:28,000 --> 00:07:30,320 Phasen sprechen, dann mag das Team sich ganz, ganz sicher 152 00:07:30,320 --> 00:07:32,720 sein, dass der Hotfix hier gut funktioniert. 153 00:07:32,960 --> 00:07:35,760 Wenn der CEO aber morgen auf der Bühne steht und ein Produkt 154 00:07:35,760 --> 00:07:38,280 präsentiert, und das muss einfach funktionieren, ist der 155 00:07:38,280 --> 00:07:40,160 wahrscheinlich anderer Meinung. Ob er jetzt noch ausgespielt 156 00:07:40,160 --> 00:07:42,320 werden muss oder nicht. Deswegen ist das glaube ich 157 00:07:42,720 --> 00:07:45,360 schwierig umzusetzen oder man muss eine sehr klare 158 00:07:45,360 --> 00:07:49,120 Reportingstruktur oder so eine Freigabestruktur haben, reden 159 00:07:49,120 --> 00:07:51,600 wir aber gleich noch drüber. Wichtig ist aber, dass das ein 160 00:07:51,680 --> 00:07:54,600 echtes und relevantes Thema ist. Also das ist jetzt nichts 161 00:07:54,600 --> 00:07:57,840 irgendwie, was nur in den Lehrbüchern steht und nichts und 162 00:07:57,840 --> 00:08:02,800 jetzt so wie nicht vorkommt. Wer so meine letzten Karriere 163 00:08:02,800 --> 00:08:04,960 changes so ein bisschen verfolgt hat, der weiß, ich werde 164 00:08:04,960 --> 00:08:07,120 wahrscheinlich jetzt noch in vielen folgenden Folgen viel 165 00:08:07,120 --> 00:08:09,600 über den E Commerce reden, weil da arbeite ich jetzt gerade nur 166 00:08:09,600 --> 00:08:12,520 mal in der E Commerce Software Bude und das ist natürlich 167 00:08:12,520 --> 00:08:14,080 gerade so. Jetzt die Blackweek die jetzt 168 00:08:14,080 --> 00:08:16,640 gerade war und das direkt danach anstehende Weihnachtsgeschäft, 169 00:08:16,960 --> 00:08:21,200 da ist halt ein da ist halt ganz ganz klar, da gibt es ein ganz 170 00:08:21,200 --> 00:08:23,600 realistisches Risiko, jede Minute Auswahl kostet den E 171 00:08:23,600 --> 00:08:26,600 Commerce halt direkt Umsatz, das knallt direkt rein und. 172 00:08:27,040 --> 00:08:30,480 Und deswegen muss man natürlich zu gewissen Zeiten einfach ganz, 173 00:08:30,480 --> 00:08:32,480 ganz sicherstellen, dass das System online ist. 174 00:08:32,720 --> 00:08:34,960 Ja, und du hattest gerade wie erwähnt so das Thema. 175 00:08:34,960 --> 00:08:38,159 Der CEO steht auf der Bühne und stellt neue Features vor, das 176 00:08:38,159 --> 00:08:40,840 ist auch etwas, was ich sehr gut nachvollziehen kann, wir hatten 177 00:08:40,840 --> 00:08:43,360 ja gerade im. Im letzten Monat oder im 178 00:08:43,360 --> 00:08:46,880 vorletzten Monat? Die github Universe und da 179 00:08:46,880 --> 00:08:49,840 werden natürlich auch von github immer ganz viele neue Sachen 180 00:08:49,840 --> 00:08:52,160 live auf der Bühne zum ersten Mal präsentiert und 181 00:08:52,160 --> 00:08:55,520 dementsprechend gibt es da auch in den Tagen davor einen 182 00:08:55,520 --> 00:08:58,400 Deployment Freeze um halt sicherzustellen, dass nicht noch 183 00:08:58,400 --> 00:09:02,320 irgendwelche Last Minute changes dann geshippt werden. 184 00:09:02,320 --> 00:09:05,520 Wir machen ja normalerweise so Continuous Delivery diverse 185 00:09:05,520 --> 00:09:09,120 Ships an einem Tag und natürlich sollte es nicht so sein, wenn 186 00:09:09,120 --> 00:09:11,960 dann die Live Demo läuft, dass plötzlich dann irgendwie das UI 187 00:09:11,960 --> 00:09:13,200 an. Das aussieht oder irgendwelche 188 00:09:13,200 --> 00:09:16,400 Preview Features noch mal sich verändert haben und es darf ja 189 00:09:16,400 --> 00:09:19,240 auf keinen Fall während einer solchen Präsentation, wo 190 00:09:19,240 --> 00:09:22,520 irgendwie Millionen Leute live irgendwie so einen Livestream 191 00:09:22,520 --> 00:09:26,080 gucken, dann so ein System ausfallen aufgrund von 192 00:09:26,080 --> 00:09:30,080 irgendwelchen Fehlern, weil ich glaube das ist der wichtige 193 00:09:30,080 --> 00:09:34,160 Punkt, dass es jetzt nicht darum geht, dass wir irgendwie unsere 194 00:09:34,160 --> 00:09:37,680 Systeme als Software unternehmen nicht im Griff haben. 195 00:09:38,160 --> 00:09:40,560 Egal welche Art von softwaresystem Wir betreiben, 196 00:09:40,560 --> 00:09:42,560 sondern es geht um die Realisierung. 197 00:09:42,560 --> 00:09:45,600 Dass am Ende Menschen immer Fehler machen können. 198 00:09:45,760 --> 00:09:50,080 Und wir dürfen halt an manchen Tagen keine Fehler uns erlauben, 199 00:09:50,080 --> 00:09:54,240 weil halt dementsprechend ein entsprechender Umsatzausfall 200 00:09:54,240 --> 00:09:56,880 oder Geschäftsausfall in irgendeiner Art und Weise oder 201 00:09:56,880 --> 00:09:59,520 vielleicht auch einfach nur ein Reputationsschaden möglich ist. 202 00:09:59,840 --> 00:10:01,680 Ja genau, da merkt man schon, das ist ein ganz wichtiger 203 00:10:01,680 --> 00:10:04,320 Punkt. Also ich glaube, wir sind uns 204 00:10:04,320 --> 00:10:05,840 einig, es geht eigentlich in so einer. 205 00:10:06,400 --> 00:10:08,880 Halbwegs modernen Welt, wo wir keine Software mehr auf CD S 206 00:10:08,880 --> 00:10:11,440 oder Disketten schippen, eben um diesen Deployment Freeze, aber 207 00:10:11,600 --> 00:10:14,400 auch, wie du gerade gesagt hast, da geht's ja dann nicht nur um 208 00:10:14,400 --> 00:10:17,280 Code, sondern wenn ich irgendwie, das ist ja auch oft 209 00:10:17,280 --> 00:10:20,400 ganz viel Konfiguration, das sind zum Beispiel irgendwelche 210 00:10:20,400 --> 00:10:22,800 Feature flags, mit denen man zum Beispiel arbeitet, das kann ja 211 00:10:22,800 --> 00:10:24,960 durchaus sein, dass das Feature schon lange geschippt war. 212 00:10:25,600 --> 00:10:28,480 Das heißt, der Code, der ist schon lange auch schon deployed. 213 00:10:28,560 --> 00:10:30,320 Aber ich muss natürlich auch dafür sorgen, dass ich in so 214 00:10:30,320 --> 00:10:32,400 einer Zeit dann nicht irgendwie für alle User so einen Feature 215 00:10:32,400 --> 00:10:36,360 Fleck freischalte oder Environment Variablen Ender oder 216 00:10:36,360 --> 00:10:39,360 irgendwelche applikations Settings mache oder irgendwelche 217 00:10:39,360 --> 00:10:41,760 Änderungen an der Infrastruktur oder ich habe es eben schon 218 00:10:41,760 --> 00:10:44,200 erwähnt. Datenbankschema Migration oder 219 00:10:44,200 --> 00:10:47,200 irgendwelche neuen background Jobs oder irgendwelche batch 220 00:10:47,200 --> 00:10:50,960 Scripte einführe oder worst case sogar irgendwas in den DNS 221 00:10:50,960 --> 00:10:52,880 Änderungen mache. Warum worst case? 222 00:10:52,880 --> 00:10:55,920 Weil DNS ist ja so ein bisschen eine Natur der Sache, hat eine 223 00:10:55,920 --> 00:10:58,640 kleine Änderung, hat aber einen riesigen Blast radius weil der 224 00:10:58,640 --> 00:11:01,280 ganz viele DNS Server dann da wieder draußen vielleicht die 225 00:11:01,280 --> 00:11:03,680 fehlerhafte Änderung cashion das ist etwas was ich auch nicht so 226 00:11:03,680 --> 00:11:06,400 schnell zurückrollen kann, wenn ich jetzt irgendwie noch wenn 227 00:11:06,400 --> 00:11:09,520 ich irgendwie sofort merke, dass ich da vielleicht was was viel 228 00:11:09,520 --> 00:11:11,680 konfiguriert habe. Deswegen kann man glaube ich 229 00:11:11,680 --> 00:11:14,720 schon sagen, wir reden eher von einem Konfigurations oder 230 00:11:14,720 --> 00:11:19,040 Deployment Freeze in unserem Fall und gar nicht mehr so sehr 231 00:11:19,040 --> 00:11:22,520 von einem Code freeze. An einer Stelle muss man aber 232 00:11:22,520 --> 00:11:24,240 noch vielleicht ein bisschen differenzieren. 233 00:11:24,240 --> 00:11:27,600 Gerade bei den Feature Flags, da werden ja gerade bei Konferenzen 234 00:11:27,600 --> 00:11:30,720 diese Feature flags auch verwendet, um neue Features 235 00:11:30,800 --> 00:11:34,160 quasi während der Keynote für alle freizuschalten, aber am 236 00:11:34,160 --> 00:11:37,760 Ende geht es ja darum, dass. Die Leute dann auch wirklich 237 00:11:37,760 --> 00:11:40,920 dieses Feature so bekommen, wie es vorher umfangreich getestet 238 00:11:40,920 --> 00:11:43,480 wurde und nicht vielleicht eine halbe Stunde vorher noch 239 00:11:43,480 --> 00:11:45,840 jemanden update geschippt hat. Und dann. 240 00:11:46,680 --> 00:11:49,000 Schickt man entsprechend den Button für das Feature Flag und 241 00:11:49,000 --> 00:11:51,440 plötzlich wird etwas freigeschaltet, was niemand 242 00:11:51,440 --> 00:11:55,280 vorher Jesu getestet hat und ich glaube gerade das Thema Feature 243 00:11:55,280 --> 00:11:57,360 Flags ist ganz spannend. Wir haben eine Folge dazu 244 00:11:57,360 --> 00:12:00,960 gemacht, wir haben aber gerade gemerkt, das war Folge 13, von 245 00:12:00,960 --> 00:12:05,760 daher waren wir da glaube ich noch technisch und fachlich noch 246 00:12:05,760 --> 00:12:08,240 nicht so weit wie wir heute sind, aber wer dennoch mal 247 00:12:08,240 --> 00:12:11,440 reinhören will, findet ihr bei den ganz alten Folgen ganz weit 248 00:12:11,440 --> 00:12:13,200 unten in der Liste. Genau. 249 00:12:13,200 --> 00:12:15,320 Also das ist so ein bisschen der Hauptgrund, warum man so was 250 00:12:15,320 --> 00:12:16,640 macht. Es gibt noch 2 andere Gründe, 251 00:12:16,640 --> 00:12:19,320 warum man sich generell um so, ja, ich nenne es jetzt weiterhin 252 00:12:19,320 --> 00:12:23,440 Code freezes, aber generell um diese diese Freezes bemüht, und 253 00:12:23,440 --> 00:12:27,040 das ist zum einen, es gibt Zeiten, in denen man wenig 254 00:12:27,040 --> 00:12:29,840 Personal oder Spezialwissen im Unternehmen hat, das kann 255 00:12:29,840 --> 00:12:33,840 entweder ganz klassisch sein über Urlaubszeiten oder 256 00:12:33,840 --> 00:12:36,640 Feiertage oder gerade jetzt, zurzeit sind viele krank, 257 00:12:36,640 --> 00:12:38,880 irgendwie so eine Krankheitswelle und dann kann es 258 00:12:38,880 --> 00:12:41,240 natürlich passieren, dass ein einfach bestimmte Key Personen 259 00:12:41,240 --> 00:12:42,920 nicht erreichbar sind. Wenn ich irgendwie sage, ey 260 00:12:42,920 --> 00:12:46,640 genau 2 Leute im Unternehmen kennen DNS oder wissen wie wir 261 00:12:46,640 --> 00:12:49,680 unsere DNS konfigurieren und die sind gerade beide im Urlaub, 262 00:12:50,000 --> 00:12:52,440 dann sagt man natürlich auch okay, dann versuchen wir, wenn 263 00:12:52,440 --> 00:12:54,720 es jetzt nicht unbedingt ganz ganz wichtig ist, in der Zeit 264 00:12:54,720 --> 00:12:57,400 den DNS Server nicht anzufassen oder ich habe irgendwelche 265 00:12:57,400 --> 00:12:59,360 anderen speziellen unternehmenssituationen ich habe 266 00:12:59,360 --> 00:13:01,760 Restrukturierungen, migrationsprojekte, Krisen, 267 00:13:02,000 --> 00:13:04,000 vielleicht sogar einfach Personalmangel, also nicht nur, 268 00:13:04,000 --> 00:13:06,160 dass Leute im Urlaub sind, sondern gar nicht da sind, dann 269 00:13:06,160 --> 00:13:08,360 muss ich mir natürlich auch so ein bisschen darüber Gedanken 270 00:13:08,360 --> 00:13:09,960 machen. Wir reden jetzt aber heute in 271 00:13:09,960 --> 00:13:12,160 dieser Folge eher von den regulären Sachen, also von 272 00:13:12,160 --> 00:13:15,000 denen, die auch planbar sind, weil da geht es auch gleich so 273 00:13:15,000 --> 00:13:17,280 ein bisschen darum, wie plant man sowas, wie kommuniziert man 274 00:13:17,280 --> 00:13:20,000 sowas aber generell so als Thema kann man glaube ich schon sagen, 275 00:13:20,000 --> 00:13:23,240 dass diese Freezes eigentlich ein Schutz sind vor Risiko und 276 00:13:23,240 --> 00:13:27,360 vor allem so vor riskanten und unkoordinierten Änderungen. 277 00:13:27,520 --> 00:13:30,400 Ja, und da muss man sich halt immer fragen, wann kann man 278 00:13:30,400 --> 00:13:33,840 diese Risiken nicht eingehen oder wann sind diese Risiken 279 00:13:33,840 --> 00:13:36,920 besonders groß und. Und du hast ja gerade schon 280 00:13:36,920 --> 00:13:39,360 gesagt, Urlaubszeit, aber es kann natürlich auch sein, dass 281 00:13:39,360 --> 00:13:43,280 vielleicht gerade durch eine Umstrukturierung einige 282 00:13:43,520 --> 00:13:46,320 Verantwortlichkeiten nicht mehr klar sind, und da ist natürlich 283 00:13:46,320 --> 00:13:49,280 kein guter Zeitpunkt, um umfangreiche Änderungen 284 00:13:49,280 --> 00:13:52,720 vorzunehmen, aber das sollte eigentlich selbstverständlich 285 00:13:52,720 --> 00:13:56,240 sein und wenn wir jetzt so darüber sprechen, hört sich das 286 00:13:56,240 --> 00:13:59,360 auf der einen Seite sehr nachvollziehbar an, dass man so 287 00:13:59,360 --> 00:14:01,600 etwas macht, aber auf der anderen Seite widerspricht das 288 00:14:01,600 --> 00:14:04,520 ja so einem. Klassischen Continuous Delivery. 289 00:14:04,520 --> 00:14:07,200 Ich hatte ja gerade gesagt, üblicherweise in einem Saar 290 00:14:07,200 --> 00:14:11,120 Service sind wir quasi kontinuierlich dabei, neue 291 00:14:11,280 --> 00:14:15,640 Features, neue Funktionalitäten zu schippen und das muss man ja 292 00:14:15,640 --> 00:14:19,520 an dieser Stelle durch so einen Freeze ganz bewusst unterbrechen 293 00:14:19,520 --> 00:14:22,800 und dann quasi irgendwie auf die Bremse treten und dann passiert 294 00:14:22,800 --> 00:14:26,080 halt erstmal nichts. Ja, voll also eigentlich hast du 295 00:14:26,080 --> 00:14:27,440 völlig recht. Eigentlich widersprechen diese 296 00:14:27,440 --> 00:14:31,920 Freezes so einem klassischen Cicd oder so einem agilen Ideal. 297 00:14:31,920 --> 00:14:33,040 Also ich habe. Eigentlich. 298 00:14:33,520 --> 00:14:37,360 Eigentlich muss man ja schon sagen, so, wenn Angst vor einem 299 00:14:37,480 --> 00:14:42,000 Merch zu kritischen Zeiten zeigt ja eigentlich, dass man kein 300 00:14:42,000 --> 00:14:47,840 echtes Vertrauen in die zumindest mal die CD Pipeline 301 00:14:47,840 --> 00:14:49,560 hat. Die Idee ist ja eigentlich, dass 302 00:14:49,560 --> 00:14:53,440 ich ein Setup habe. In dem ich jederzeit deployen 303 00:14:53,440 --> 00:14:58,000 kann, weil ich ja teste und Monitore und im Idealfall mit 304 00:14:58,000 --> 00:15:02,560 Canary deployments Dinge nicht direkt an alle User Ausrolle 305 00:15:02,720 --> 00:15:05,120 oder Feature Flex habe, die ich im kritischen Fall wieder 306 00:15:05,120 --> 00:15:09,240 abschalten kann oder Mechanismus habe um Rollbacks zu machen und 307 00:15:09,240 --> 00:15:12,960 so weiter also eigentlich, wenn ich jetzt wirklich nach Lehrbuch 308 00:15:12,960 --> 00:15:15,640 arbeite, könnte man argumentieren, dass man das gar 309 00:15:15,640 --> 00:15:17,400 nicht braucht. Ja, aber auf der anderen Seite. 310 00:15:17,400 --> 00:15:18,880 Und ich hatte es ja vorhin schon erwähnt. 311 00:15:19,200 --> 00:15:22,720 Machen Menschen halt Fehler und ich glaube, niemand von uns kann 312 00:15:22,720 --> 00:15:25,280 sagen, ich habe noch nie einen Fehler gemacht, der dazu geführt 313 00:15:25,280 --> 00:15:27,760 hat, dass die Applikation, die gerade in Produktion läuft, ein 314 00:15:27,760 --> 00:15:29,200 Problem hat. Also ist mir auch schon 315 00:15:29,200 --> 00:15:32,520 passiert, da muss man natürlich da entsprechend drauf reagieren, 316 00:15:32,520 --> 00:15:35,920 aber daran merkt man natürlich, dass in bestimmten Zeiten 317 00:15:35,920 --> 00:15:38,960 einfach diese Änderungen. Vielleicht unterlassen werden 318 00:15:38,960 --> 00:15:42,000 müssen, weil halt irgendjemand immer einen Fehler machen kann. 319 00:15:42,160 --> 00:15:44,480 Was ich ganz interessant finde, ist einfach mal vielleicht auch 320 00:15:44,480 --> 00:15:49,080 in den auf die Statuspage von diversen SARS Anbietern zu gehen 321 00:15:49,080 --> 00:15:51,680 und sich einfach mal anzuschauen, wie viele Incidents 322 00:15:51,680 --> 00:15:55,440 die letzten Endes haben und wenn selbst die größten SARS Player 323 00:15:55,440 --> 00:15:59,520 des Planeten regelmäßig solche Incidents haben im normalen 324 00:15:59,520 --> 00:16:02,800 Alltag, dann kann man glaube ich nicht von sich sagen, ja wir 325 00:16:02,800 --> 00:16:06,240 sind viel reifer als diese großen Player und bei uns 326 00:16:06,240 --> 00:16:07,480 passiert das nicht und deswegen können. 327 00:16:07,560 --> 00:16:09,920 Können wir halt die ganze Zeit durchshippen, egal wie kritisch 328 00:16:09,920 --> 00:16:13,160 die Zeit ist. Ich glaube, so arrogant dürfen 329 00:16:13,160 --> 00:16:15,200 wir da auch nicht sein. Und dazu kommt natürlich auch, 330 00:16:15,200 --> 00:16:19,320 dass ich jetzt auch noch wenige Unternehmen gesehen habe, die 331 00:16:19,320 --> 00:16:22,400 wirklich dieses perfekte Lehrbuch mit Canary und Blue 332 00:16:22,400 --> 00:16:25,520 Green und Feature Fakes und Rollbacks und sowas wirklich 333 00:16:25,920 --> 00:16:27,920 durchexerzieren. Ich glaube da wollen alle hin 334 00:16:27,920 --> 00:16:30,400 und alle nehmen sich so ein bisschen die Sachen da raus, die 335 00:16:30,400 --> 00:16:32,560 entweder für sie besonders wichtig sind oder Law hanging 336 00:16:32,560 --> 00:16:35,120 Fruits sind, aber. War da muss man ja auch mal dazu 337 00:16:35,120 --> 00:16:37,600 sagen, es ist ja auch unrealistisch, wirklich davon 338 00:16:37,600 --> 00:16:41,200 auszugehen, dass das überall genauso perfekt gelebt wird. 339 00:16:41,600 --> 00:16:44,800 Und dazu kommt natürlich auch, dass ja offenbar auch in den 340 00:16:44,800 --> 00:16:47,440 Firmen, die sich das leisten können oder die das so aufgebaut 341 00:16:47,440 --> 00:16:49,880 haben, diese Fehler passieren, und es gibt ja auch noch ein 342 00:16:49,880 --> 00:16:52,000 paar andere Probleme von diesen Freezes. 343 00:16:52,000 --> 00:16:54,320 Ich habe dann oft so einen, wenn ich wirklich einen richtigen 344 00:16:54,320 --> 00:16:56,920 Code freeze mache, habe ich danach so einen Merch Rush, also 345 00:16:56,920 --> 00:17:01,120 ich habe ganz viele aufgestaute. Sag ich mal Pull requests zum 346 00:17:01,120 --> 00:17:03,680 Beispiel oder merge requests. Je nachdem welche Tool man 347 00:17:04,000 --> 00:17:06,640 verwendet. Nach diesem Freeze oder so ein 348 00:17:06,640 --> 00:17:09,040 Quality Drop vor dem Freeze, dass ich eine Zeit lang wirklich 349 00:17:09,040 --> 00:17:12,079 auch keine neuen Sachen shippe und ich unterbreche halt so ein 350 00:17:12,079 --> 00:17:15,119 bisschen mein Flow und Sorge natürlich auch für in der Zeit 351 00:17:15,119 --> 00:17:17,280 für deutlich weniger Wertschöpfung wirklich für so 352 00:17:17,280 --> 00:17:19,119 eine Verlangsamung meines Unternehmens. 353 00:17:20,000 --> 00:17:21,920 Ja, du hattest gerade gesagt, man hat dann so ein bisschen so 354 00:17:21,920 --> 00:17:25,040 einen Stau, der sich dann da aufbaut, und der muss ja auch 355 00:17:25,040 --> 00:17:26,960 nachher abgearbeitet werden. Das heißt, man hat dann 356 00:17:26,960 --> 00:17:29,480 natürlich auch einen höheren Workload nachher, weil man die 357 00:17:29,480 --> 00:17:32,360 ganzen Sachen, die man dann jetzt nicht gemergt hat, bei 358 00:17:32,360 --> 00:17:35,280 einem echten Code Fries. Die muss man dann nachher 359 00:17:35,280 --> 00:17:38,000 reviewen und dann entsprechend mergen. 360 00:17:38,320 --> 00:17:41,440 Aber auf der anderen Seite hast du natürlich das Problem, dass 361 00:17:41,440 --> 00:17:44,680 wenn du eine bestimmte Deadline setzt und sagst, hier ab dem 362 00:17:44,680 --> 00:17:47,440 Zeitpunkt herrscht ein Deployment Freeze, dass 363 00:17:47,440 --> 00:17:50,000 natürlich alle auf diese Deadline hin arbeiten müssen, 364 00:17:50,000 --> 00:17:53,000 entweder am Beispiel einer Konferenz diejenigen, die die 365 00:17:53,000 --> 00:17:54,960 neuen Features für diese Konferenz bauen, die müssen 366 00:17:54,960 --> 00:17:57,360 genau auf diese Deadline arbeiten, da kann es natürlich 367 00:17:57,360 --> 00:18:00,680 zu Zeitdruck kommen, aber auch so ganz persönliche Sachen. 368 00:18:00,680 --> 00:18:03,240 Stell dir vor, du bist irgendwie ein PM, du arbeitest an einem 369 00:18:03,240 --> 00:18:06,480 Feature und dann. Kommt vielleicht mit sehr kurzem 370 00:18:06,480 --> 00:18:09,200 Vorlauf irgendwie 46 Wochen. Kommt dann jemand zu dir? 371 00:18:09,200 --> 00:18:10,960 Du arbeitest seit einem halben Jahr in einem Feature, sagt er 372 00:18:10,960 --> 00:18:15,040 okay, da ist entsprechend Code Freeze oder Deployment Freeze, 373 00:18:15,280 --> 00:18:17,440 aber in deinen persönlichen Commitments steht halt drin, 374 00:18:17,440 --> 00:18:20,120 dass du zu einem bestimmten Datum dein Feature geshippt 375 00:18:20,120 --> 00:18:22,320 hast. Und da kannst du natürlich schon 376 00:18:22,320 --> 00:18:24,800 ganz schön unter Druck kommen und du hast gerade gesagt, dann 377 00:18:24,800 --> 00:18:28,160 kann das auch zu einem Qualitätsverlust führen, weil du 378 00:18:28,160 --> 00:18:30,840 dann sagst ja. Ja, ich muss das aber vor dieser 379 00:18:30,840 --> 00:18:33,120 Deadline noch rüberbringen und eigentlich hatte ich geplant das 380 00:18:33,120 --> 00:18:36,600 2 Wochen später zu releasen und dann wird es am Ende hin eng und 381 00:18:36,600 --> 00:18:39,440 das wollen wir eigentlich vermeiden und ich glaube wir 382 00:18:39,440 --> 00:18:41,640 sprechen gleich noch mal ein bisschen über die Taktik, wie 383 00:18:41,640 --> 00:18:45,680 man so einen Deponment Freeze sinnvoll einführt und dazu 384 00:18:45,680 --> 00:18:49,400 gehört zum Beispiel um mir zu viel vorzugreifen, dass man es 385 00:18:49,400 --> 00:18:52,080 natürlich ausreichend vorher plant und kommuniziert. 386 00:18:52,800 --> 00:18:54,840 Generell finde ich diesen Gedanken aber gar nicht so 387 00:18:54,840 --> 00:18:56,880 falsch zu sagen. Eigentlich widerspricht es ja 388 00:18:56,880 --> 00:18:59,400 unserem Ideal. Und deswegen finde ich, kann man 389 00:18:59,400 --> 00:19:02,240 auch schon sagen, so, wenn man einen Freeze braucht, dann 390 00:19:02,360 --> 00:19:04,560 sollte man vielleicht noch ein bisschen reindrillen. 391 00:19:04,560 --> 00:19:09,280 Warum brauchen wir den denn oft können die ein Anzeichen dafür 392 00:19:09,280 --> 00:19:12,320 sein, wo ich eben meine eigenen Prozesse oder vielleicht vor 393 00:19:12,320 --> 00:19:15,840 allem so meine Observabilities oder Rollbacks oder mein Testing 394 00:19:15,840 --> 00:19:17,920 oder sowas. Eben noch verbessern kann. 395 00:19:17,920 --> 00:19:20,960 Also ich kann ja sagen okay, wir brauchen auf jeden Fall einen 396 00:19:20,960 --> 00:19:23,120 Code freeze, aber es kann ja das Ziel sein, dass wir das in 397 00:19:23,120 --> 00:19:25,160 Zukunft nicht mehr brauchen oder immer weniger brauchen. 398 00:19:25,160 --> 00:19:27,640 Nur die Tatsache, dass wir es jetzt brauchen, zeigt dann einem 399 00:19:27,640 --> 00:19:29,200 vielleicht ja selber auch noch mal so ein bisschen auf, dass 400 00:19:29,200 --> 00:19:32,040 man da vielleicht noch nicht in diesem Idealzustand, den wir 401 00:19:32,040 --> 00:19:34,880 eben beschrieben haben, erreicht hat, weil es kann ja sein, ich 402 00:19:34,880 --> 00:19:37,000 habe vielleicht trotzdem meinen Code freeze, aber es bleiben 403 00:19:37,000 --> 00:19:41,000 Risiken, weil irgendwelche config oder vielleicht also dass 404 00:19:41,120 --> 00:19:43,200 irgendwas nicht nicht mitgedacht wurde. 405 00:19:43,840 --> 00:19:45,680 Und jetzt irgendwie trotzdem eine Änderung an Datenbank 406 00:19:45,680 --> 00:19:49,440 Schemata gemacht oder was was weiß ich und das deckt ja dann 407 00:19:49,440 --> 00:19:52,280 oft auch einfach so Dinge auf. Wir hatten zum Beispiel bei uns 408 00:19:52,280 --> 00:19:55,160 im Unternehmen kann man sagen, wir nutzen eigentlich für alles 409 00:19:55,160 --> 00:19:57,920 was Cloud Konfiguration ist. Terraform, das heißt man ist 410 00:19:57,920 --> 00:19:59,560 sich relativ sicher zu sagen okay Pass auf, wenn wir jetzt 411 00:19:59,560 --> 00:20:03,600 dieses Repository einfrieren, was für dieses Produkt die Cloud 412 00:20:03,600 --> 00:20:07,360 Infrastruktur aufsetzt, dann werden da auch keine 413 00:20:07,360 --> 00:20:10,080 Infrastruktur chaines gemacht. So, jetzt muss ich aber trotzdem 414 00:20:10,080 --> 00:20:13,000 gucken, ist das wirklich alles, ist es die gesamte Infrastruktur 415 00:20:13,000 --> 00:20:14,640 oder gibt es nicht vielleicht doch noch irgendwelche? 416 00:20:14,640 --> 00:20:17,280 Wir hatten eben das Beispiel DNS Configs, die vielleicht beim 417 00:20:17,360 --> 00:20:20,160 Domain Provider liegen, die gar nicht mit Terraform verwaltet 418 00:20:20,160 --> 00:20:23,080 werden, oder kann es denn vielleicht trotzdem sein, dass 419 00:20:23,080 --> 00:20:26,040 ich mich ja vielleicht dieses Repository eingefroren habe, man 420 00:20:26,040 --> 00:20:28,200 aber trotzdem vielleicht ins Cloud Portal gehen kann und da 421 00:20:28,200 --> 00:20:30,880 manuelle Änderungen machen kann? Sollte natürlich alles nicht 422 00:20:30,880 --> 00:20:34,160 sein, aber da muss ich mir trotzdem Bewusstsein, dass nur 423 00:20:34,160 --> 00:20:36,360 weil ich Code einfriere an irgendeiner Stelle und selbst 424 00:20:36,360 --> 00:20:38,800 wenn es Infrastructure s Code ist, dann. 425 00:20:38,920 --> 00:20:41,760 Das ja nicht auch automatisch heißt, dass ich ja alle alle 426 00:20:41,760 --> 00:20:44,560 Sachen mitgedacht haben, alle Risiken damit abgedeckt haben 427 00:20:44,960 --> 00:20:46,920 und dann ist das ja oft ein Zeichen dafür, dass hey, wenn 428 00:20:46,920 --> 00:20:48,640 ich deswegen jetzt eine Kommunikation machen muss oder 429 00:20:48,640 --> 00:20:50,880 was einfrieren muss, dann sind das vielleicht noch Dinge, die 430 00:20:50,880 --> 00:20:52,640 ich noch vielleicht dahin holen sollte oder woanders mal 431 00:20:52,640 --> 00:20:54,960 vielleicht irgendwann den Zugang abdrehen sollte und so, ich 432 00:20:55,080 --> 00:20:58,120 finde, das kann einem schon viel aufzeigen, wenn man so einen 433 00:20:58,120 --> 00:21:00,400 Freeze braucht, wo noch Verbesserungsbedarf. 434 00:21:00,400 --> 00:21:03,600 Ist die Frage, ist halt auch immer, wie häufig kommt das vor. 435 00:21:03,600 --> 00:21:06,600 Ich glaube wenn man irgendwie. Einmal, zweimal im Jahr, wenn 436 00:21:06,600 --> 00:21:08,600 man irgendwie jetzt im E Commerce unterwegs ist und sagt, 437 00:21:08,600 --> 00:21:11,360 man macht das irgendwie vor Black Friday und in der 438 00:21:11,360 --> 00:21:14,160 Weihnachtszeit, dann ist das ja glaube ich fein. 439 00:21:14,160 --> 00:21:16,440 Aber es gibt natürlich auch Situationen, da wird dann 440 00:21:16,440 --> 00:21:19,600 irgendwie einmal im Monat die letzten Tage des Monats ein Code 441 00:21:19,600 --> 00:21:22,600 Freeze gemacht, weil da ist immer Vorstandssitzung, und das 442 00:21:22,600 --> 00:21:25,360 ist ja ein rein interner Grund, und dass man das jedes Mal 443 00:21:25,360 --> 00:21:28,560 macht, zeigt halt, dass man auch kein Vertrauen in die eigene 444 00:21:28,800 --> 00:21:31,560 Qualität und die eigene Qualitätssicherung hat und. 445 00:21:32,000 --> 00:21:34,880 Und ich glaube, man muss da natürlich differenzieren, an 446 00:21:34,880 --> 00:21:39,920 welcher Stelle halt das Risiko so groß ist, dass sich dieser 447 00:21:39,920 --> 00:21:44,240 Eingriff tatsächlich in dieses Continuous Delivery wirklich 448 00:21:44,240 --> 00:21:47,200 auch lohnen kann. Ja gut, da kommen wir jetzt mal 449 00:21:47,200 --> 00:21:49,560 zur Umsetzung. Also wie setzt man denn jetzt so 450 00:21:49,560 --> 00:21:51,080 einen Freeze? Wie auch immer man den jetzt 451 00:21:51,080 --> 00:21:54,240 nennt, konkret um einen Punkt finde ich ganz ganz wichtig, den 452 00:21:54,240 --> 00:21:56,720 hast du gerade schon so ein bisschen gesagt, Kommunikation 453 00:21:56,720 --> 00:21:59,640 und ich glaube das ist auch oft das, was in so einer komplett 454 00:21:59,640 --> 00:22:01,800 technischen Umgebung manchmal hinten überfällt und. 455 00:22:02,240 --> 00:22:05,800 Ganz wichtig, frühzeitig ankündigen, alle müssen Bescheid 456 00:22:05,800 --> 00:22:09,320 wissen, der Zeitraum muss klar definiert sein, der Umfang muss 457 00:22:09,320 --> 00:22:12,480 klar definiert sein, betroffene Umgebungen müssen benannt 458 00:22:12,480 --> 00:22:16,080 werden, also klarstellen, was genau ist eingefroren reden wir 459 00:22:16,080 --> 00:22:19,360 von Codes oder reden wir von den Deployments oder nur von 460 00:22:19,360 --> 00:22:23,360 Konfiguration und Infrastruktur, gibt es Ausnahmen, wie sieht 461 00:22:23,360 --> 00:22:25,760 eine Eskalationspfad aus? Also es wird ja trotzdem 462 00:22:25,760 --> 00:22:28,520 passieren, dass wir eventuell doch was hotfixen müssen, wenn 463 00:22:28,520 --> 00:22:32,240 ich jetzt einfach sage ich. Schmeißt alle Leute aus meinem 464 00:22:32,240 --> 00:22:33,920 Repo raus und keiner kann jetzt mehr irgendwas. 465 00:22:33,920 --> 00:22:36,080 Da muss ich ja trotzdem irgendwie einen Eskalationspfad 466 00:22:36,080 --> 00:22:39,600 einrichten und es muss natürlich auch klargestellt werden, was 467 00:22:39,600 --> 00:22:41,360 machen wir in der Zeit stattdessen, also geht es 468 00:22:41,360 --> 00:22:43,240 trotzdem irgendwie weiter gut, wenn wir uns eigentlich darauf 469 00:22:43,240 --> 00:22:45,240 geeinigt haben, dass wir keinen Code freeze machen, kann 470 00:22:45,240 --> 00:22:47,760 natürlich weiterentwickelt werden, aber es ist ganz 471 00:22:47,760 --> 00:22:50,920 wichtig, gerade auch gerade, wo du sagtest, eben da hängen ja 472 00:22:50,920 --> 00:22:53,360 auch andere Stakeholder dran, wie zum Beispiel eine PM oder 473 00:22:53,360 --> 00:22:56,080 eine Deadline oder der CEO will auf der Bühne irgendwas 474 00:22:56,880 --> 00:22:58,920 präsentieren, was bislang fertig sein muss, also. 475 00:22:59,000 --> 00:23:01,240 Also wenn wir uns entscheiden, so einen Freeze zu machen, ganz 476 00:23:01,240 --> 00:23:04,720 wichtiger erster Punkt, Kommunikation frühzeitig 477 00:23:04,800 --> 00:23:07,040 Zeitraum, Umfang, Umgebungen definieren. 478 00:23:07,360 --> 00:23:10,480 Ja, und das hängt ja auch direkt mit den technischen Maßnahmen 479 00:23:10,480 --> 00:23:13,120 zusammen, weil wenn wir auf der technischen Seite jetzt hingehen 480 00:23:13,120 --> 00:23:16,080 und bestimmte Permissions beschränken, das heißt, nur noch 481 00:23:16,080 --> 00:23:18,640 bestimmte Gruppen dürfen entweder ein Deployment 482 00:23:18,640 --> 00:23:22,160 freigeben, sie dürfen bestimmte Konfigurationsänderungen 483 00:23:22,160 --> 00:23:26,320 vornehmen oder einfach einen. Pr freigeben, damit er gemergt 484 00:23:26,320 --> 00:23:27,840 werden kann. Das hängt ja aber so ein 485 00:23:27,840 --> 00:23:31,280 bisschen davon ab, wie auch das eigene Deployment Modell läuft, 486 00:23:31,280 --> 00:23:35,360 wenn unser Main Branch immer automatisch in Production 487 00:23:35,360 --> 00:23:38,880 geshippt wird, dann muss ich schon an der PR stelle angreifen 488 00:23:38,880 --> 00:23:42,160 und da bestimmten Leuten nur noch das Recht geben so ein. 489 00:23:43,880 --> 00:23:47,440 Feature Branch zu Mergen und das hängt natürlich dann mit dieser 490 00:23:47,440 --> 00:23:49,200 kommunikativen Maßnahme zusammen. 491 00:23:49,200 --> 00:23:52,160 Es muss allen klar sein, wer solche Dinge dann am Ende 492 00:23:52,160 --> 00:23:56,160 freigeben kann und muss. Du sagst gerade, es muss ja auch 493 00:23:56,160 --> 00:23:58,600 Ausnahmen geben, das heißt, wenn ich irgendwelche kritischen 494 00:23:58,600 --> 00:24:01,280 Probleme habe, die müssen gefixt werden und dann kann es 495 00:24:01,280 --> 00:24:04,320 natürlich nicht sein, dass irgendwie nur der CEO am Ende 496 00:24:04,320 --> 00:24:07,640 den PR freigeben kann und der CEO steht aber gerade auf der 497 00:24:07,640 --> 00:24:11,120 Konferenz auf der Bühne, kann aber gerade nicht und alle 498 00:24:11,120 --> 00:24:14,400 sitzen irgendwie. Im Office und können halt einen 499 00:24:14,400 --> 00:24:16,360 kritischen Fix nicht ausrollen. Ich meine, im Fall von Gitter 500 00:24:16,360 --> 00:24:18,120 wäre das eine wirklich coole Demo, ehrlich gesagt. 501 00:24:19,680 --> 00:24:23,080 Wenn man dann auf der Bühne den PR freigeben muss, weil gerade 502 00:24:23,080 --> 00:24:26,120 irgendwas nicht funktioniert, aber ich glaube, da hängen diese 503 00:24:26,120 --> 00:24:28,000 beiden Themen halt sehr eng zusammen. 504 00:24:28,160 --> 00:24:31,240 Kommunikation und die technischen Maßnahmen, die 505 00:24:31,240 --> 00:24:34,960 entsprechend eingerichtet sind, und da ist natürlich die erste 506 00:24:34,960 --> 00:24:38,560 technische Maßnahme, zu schauen, wie sehen meine Brunch 507 00:24:38,560 --> 00:24:41,680 Protection Rules aus, welche Policies habe ich konfiguriert 508 00:24:41,680 --> 00:24:43,600 und. Und wie muss ich das jetzt 509 00:24:43,600 --> 00:24:48,960 entsprechend in dieser Zeit des Deployment Freezes anpassen, 510 00:24:49,200 --> 00:24:53,200 damit es halt verhindert, dass nicht business as usual 511 00:24:53,200 --> 00:24:54,920 weiterläuft? Ja, das ist ganz wichtig. 512 00:24:54,920 --> 00:24:57,240 Es reicht nicht, irgendwie eine E Mail zu schreiben, sondern das 513 00:24:57,240 --> 00:25:00,480 muss eben auch wirklich dann nicht mehr möglich sein zu 514 00:25:00,480 --> 00:25:04,160 deployen, zumindest nicht auf dem normalen Weg, und da gibt es 515 00:25:04,160 --> 00:25:05,520 ja diverse Sachen. Also du hast gerade schon 516 00:25:05,520 --> 00:25:07,440 gesagt, so in der github Welt, da kann ich ja so. 517 00:25:07,800 --> 00:25:10,480 Protection Policies auf bestimmte Branches setzen. 518 00:25:10,480 --> 00:25:12,320 Gerade wenn ich mich, gerade wenn wir uns reinigen soll, 519 00:25:12,320 --> 00:25:14,920 weiter programmiert werden, dann kann ich ja nicht auf einmal den 520 00:25:14,920 --> 00:25:17,200 Leuten Zugang zu dem Repository wegnehmen, ist auch glaube ich 521 00:25:17,200 --> 00:25:19,520 nicht nicht sinnbehaftet, sondern muss eben dann ein 522 00:25:19,760 --> 00:25:22,120 entsprechendes permissions Konzept aufbauen, das heißt ich 523 00:25:22,120 --> 00:25:24,760 brauche auch vielleicht verschiedene Gruppen, die dann 524 00:25:24,760 --> 00:25:28,720 nur noch PS freigeben können, bedeutet aber auch wiederum, ich 525 00:25:28,720 --> 00:25:31,760 muss bei meinem Rollen und rechte Konzept das Code Free 526 00:25:31,760 --> 00:25:34,440 Szenario von vornherein mitdenken und. 527 00:25:34,760 --> 00:25:36,800 Und dann muss ich natürlich technisch das so umsetzen, dass 528 00:25:36,800 --> 00:25:39,920 während dieser Zeit ich quasi sage, dass nur noch diese 529 00:25:39,920 --> 00:25:43,200 Gruppen Pairs Fall gehen können. Vielleicht sind das auch 530 00:25:43,200 --> 00:25:47,120 verschiedene Gruppen pro pro Repository, oder das ist 531 00:25:47,120 --> 00:25:50,160 wirklich halt dann ein kleiner Kreis, weil man dann wirklich 532 00:25:50,160 --> 00:25:54,160 sagt, für diese Repository nur für den Ernstfall keine Merches 533 00:25:54,160 --> 00:25:56,240 passieren hier mehr ohne Approval, zumindest nicht auf 534 00:25:56,240 --> 00:25:58,880 irgendwelche Main trunk oder Release branches die das 535 00:25:58,880 --> 00:26:02,480 irgendwie gehen. Und ja, so eine, so eine 536 00:26:02,480 --> 00:26:05,800 Protection muss man dann eben Repository weit einführen. 537 00:26:05,800 --> 00:26:08,240 Man kann das theoretisch auch schon, ich rede das auch viel 538 00:26:08,240 --> 00:26:10,360 von Gitter, weil malte und ich natürlich super viel in dieser 539 00:26:10,360 --> 00:26:12,720 Welt unterwegs sind, kann natürlich auch sagen, wir 540 00:26:12,720 --> 00:26:16,160 hinterlegen in jedem Repository schon mal so eine Brunch 541 00:26:16,160 --> 00:26:18,600 Protection, schalten die aber nicht scharf, stellen aber 542 00:26:18,600 --> 00:26:21,360 sicher, dass wir das Repository weit könnten und wenn dann der 543 00:26:21,360 --> 00:26:23,760 Code Freeze kommuniziert wird, dann schalten wir diese diese 544 00:26:23,760 --> 00:26:27,040 Regel scharf, die auf einmal für Pull Requests auf ganz bestimmte 545 00:26:27,040 --> 00:26:29,520 Brunches diese extra Protection layers ein für das ist. 546 00:26:29,920 --> 00:26:32,840 Eigentlich auch gar nicht mehr, geht aus dem Ausnahmefall und 547 00:26:32,840 --> 00:26:35,120 kann die dann nachher wieder deaktivieren. 548 00:26:35,280 --> 00:26:38,320 Und wenn ich jetzt jetzt in meiner Code Management Plattform 549 00:26:38,320 --> 00:26:40,960 nicht kann, dann kann ich natürlich auch über AP is 550 00:26:40,960 --> 00:26:43,600 entsprechende Konfigs vorbereiten, diese dann 551 00:26:43,600 --> 00:26:46,240 entsprechend scharfstellen oder wieder deaktivieren. 552 00:26:46,480 --> 00:26:49,840 Oder ich greife an einer anderen Stelle entsprechend in den 553 00:26:49,840 --> 00:26:53,320 Prozess ein. Es kann zum Beispiel die cicv 554 00:26:53,320 --> 00:26:56,240 Phase sein, wo dann die Pipeline, wenn ein bestimmtes. 555 00:26:56,800 --> 00:26:59,160 Bestimmte Variable gesetzt ist einfach abbricht. 556 00:26:59,160 --> 00:27:02,000 Das heißt, ich setze einfach während dieses Deployment 557 00:27:02,000 --> 00:27:06,000 Freezes eine Umgebungsvariable, welche bestimmt, dass halt die 558 00:27:06,000 --> 00:27:09,600 Pipeline gar nicht durchläuft und wenn dann doch irgendwie 559 00:27:09,840 --> 00:27:13,440 Code gemergt wird, dann kommt der gar nicht in Produktion, 560 00:27:13,440 --> 00:27:16,760 weil die Pipeline abbricht. Ja, Skript ist vor allem dann 561 00:27:16,760 --> 00:27:18,800 natürlich eine wichtige Geschichte, wenn ich jetzt sage, 562 00:27:18,960 --> 00:27:21,240 ey. Wie wir zum Beispiel haben über 563 00:27:21,240 --> 00:27:22,960 100 Repos, da kann ich jetzt ja nicht überall manuell 564 00:27:22,960 --> 00:27:25,680 irgendwelche Policies umschalten oder ändern. 565 00:27:25,920 --> 00:27:27,720 Ist ja auch natürlich wieder, weil es ein menschlicher Faktor 566 00:27:27,720 --> 00:27:28,920 ist. Die Gefahr viel zu groß, dass 567 00:27:28,920 --> 00:27:31,840 ich 1 vergesse, wenn ich das dann halt irgendwie zum Beispiel 568 00:27:31,840 --> 00:27:35,760 skripten kann, dass ich da diese bestimmten Funktionen oder 569 00:27:35,760 --> 00:27:39,720 Änderungen per Skript ausrolle oder ich kann ja bei github 570 00:27:39,720 --> 00:27:43,600 sogar so Enterprise weit irgendwelche Regeln und Dinge 571 00:27:44,000 --> 00:27:46,840 für meine. Repositories definieren, dann 572 00:27:46,840 --> 00:27:48,880 sollte ich das natürlich an einer zentralen Stelle machen, 573 00:27:48,880 --> 00:27:50,720 dann kann ich natürlich auch ganz, ganz viele Repositories 574 00:27:50,720 --> 00:27:54,560 gleichzeitig davon betreffen. Man geht auch selber, weil es 575 00:27:54,560 --> 00:27:56,960 wird auch unser unser Beispiel ist. 576 00:27:57,520 --> 00:28:00,400 Kann man zum Beispiel sogar diese diese Regel, hey. 577 00:28:00,880 --> 00:28:04,800 Ein Review auf diesem also ein Review zu diesem Branch oder 578 00:28:04,800 --> 00:28:08,320 dieser Branch Familie, muss jetzt von bestimmten Teams 579 00:28:08,320 --> 00:28:09,840 erfolgen. Für eine Poly request. 580 00:28:10,000 --> 00:28:12,240 Das könnte man zum Beispiel zentral an einer Stelle 581 00:28:12,240 --> 00:28:13,920 hinterlegen, das wäre so eine Möglichkeit. 582 00:28:13,920 --> 00:28:15,720 Aber wie gesagt, wenn ich nicht, wenn ich etwas anderes als 583 00:28:15,720 --> 00:28:17,880 Github verwende, dann gibt es da entweder auch irgendwas was ich 584 00:28:17,880 --> 00:28:20,480 zentral steuern kann oder ich gehe wirklich dieses Thema 585 00:28:20,480 --> 00:28:23,120 Scripting durch, da würde ich aber einmal kurz vorher den 586 00:28:23,120 --> 00:28:26,480 Skript testen und natürlich mir auch irgendwie verifizieren 587 00:28:26,480 --> 00:28:29,200 lassen, dass das jetzt wirklich auch bei allen Repos, die dieser 588 00:28:29,200 --> 00:28:32,080 Freeze betrifft es. Entsprechend erfolgreich 589 00:28:32,160 --> 00:28:35,040 umkonfiguriert wurde. Genau und im besten Fall ist es 590 00:28:35,040 --> 00:28:38,640 so, dass ich halt ganz klar weiß, welche Gruppe von Leuten 591 00:28:38,640 --> 00:28:43,560 kann auch ein Deployment, was nötig ist freigeben und da ist 592 00:28:43,560 --> 00:28:47,360 es natürlich dann nicht ideal, wenn ich irgendwie einen hacky 593 00:28:47,360 --> 00:28:50,240 Workaround gebaut habe mit irgendwelchen Labeln oder 594 00:28:50,240 --> 00:28:53,120 Umgebungsvariablen, die ich dann temporär zurücksetzen muss und 595 00:28:53,120 --> 00:28:55,280 dann rutscht mir vielleicht doch was durch, was ich eigentlich 596 00:28:55,280 --> 00:28:58,080 nicht wollte. Ich glaube, wenn ich in meiner 597 00:28:58,080 --> 00:29:01,120 Plattform solche Möglichkeiten habe, um zum Beispiel ein 598 00:29:01,280 --> 00:29:05,200 Management Team als required approver irgendwo einzusetzen, 599 00:29:05,200 --> 00:29:07,600 dann kann ich das auch ganz klar kommunizieren. 600 00:29:07,600 --> 00:29:11,200 Dann weiß ich okay wenn jetzt in dieser Freeze Zeit ein 601 00:29:11,200 --> 00:29:13,760 Deployment durchgeführt werden muss, dann weiß ich an wen ich 602 00:29:13,760 --> 00:29:16,400 mich da wenden muss um das entsprechend zu erlauben. 603 00:29:17,080 --> 00:29:18,400 Das zeigt aber auch schon wieder ne. 604 00:29:18,400 --> 00:29:21,360 Meistens betrifft das eben nicht nur ein Repository, sondern ganz 605 00:29:21,360 --> 00:29:23,920 ganz viele verschiedene Umgebungen, die oft ja auch in 606 00:29:23,920 --> 00:29:26,720 verschiedenen Repositories oder verschiedene Teile 607 00:29:26,960 --> 00:29:29,920 Infrastructure Code und der Code selber und noch vielleicht 608 00:29:30,080 --> 00:29:32,560 helmcharts oder was auch immer da an verschiedenen Repos liegt. 609 00:29:32,920 --> 00:29:35,080 Das heißt, eigentlich muss ich mir vor so einem Freeze auch so 610 00:29:35,080 --> 00:29:37,040 ein Assessment machen. Das heißt, ich muss mal gucken, 611 00:29:37,040 --> 00:29:40,720 gut, wie breit geht denn dieser Freeze, wie ist denn auch 612 00:29:40,720 --> 00:29:42,840 irgendwie eine Risikobewertung, welche Systeme will ich denn 613 00:29:42,840 --> 00:29:45,040 jetzt schützen, welche sind besonders kritisch, welche 614 00:29:45,040 --> 00:29:48,000 Repositories zahlen darauf ein, sind überhaupt betroffen, habe 615 00:29:48,000 --> 00:29:51,840 ich da versteckte Risiken, irgendwo DNS, externe Provider, 616 00:29:52,000 --> 00:29:54,400 vielleicht irgendwelche SARS tools die ich verwende, also 617 00:29:54,400 --> 00:29:56,120 muss ich natürlich auch irgendwie gucken, dass wenn ich 618 00:29:56,120 --> 00:29:58,400 jetzt oz Zero für mein Login verwende, auch da keiner 619 00:29:58,400 --> 00:30:00,640 irgendwelche Änderungen macht, wie wird sich denn da 620 00:30:00,640 --> 00:30:02,240 eingeloggt, ist das über Single Sign on? 621 00:30:02,240 --> 00:30:04,520 Soll ich dann dieses ein? Einloggen in der Zeit verhindern 622 00:30:05,400 --> 00:30:07,440 oder wie mache ich das? Da sind ja ganz, ganz viele 623 00:30:07,760 --> 00:30:12,160 Fragestellungen, es kann ja sein, dass wie gesagt, dass dass 624 00:30:12,160 --> 00:30:14,480 es ja auch irgendwelche Skripte gibt, die auf einmal über Nacht 625 00:30:14,480 --> 00:30:17,160 laufen, irgendwie irgendwelche Nightly Builds bauen oder sowas, 626 00:30:17,160 --> 00:30:19,400 was ist denn damit? Also ich glaube da muss man sich 627 00:30:19,400 --> 00:30:21,360 schon vorher hinsetzen und das und so einen Freeze auch 628 00:30:21,360 --> 00:30:23,440 anständig planen, indem man eben wie gesagt so eine 629 00:30:23,440 --> 00:30:26,840 Risikobewertung macht. Den Blast Radius definiert und 630 00:30:26,880 --> 00:30:29,560 wirklich genau schaut. Was sind denn alle Systeme die 631 00:30:29,560 --> 00:30:31,680 jetzt davon betroffen wären, wenn wir alles einfrieren 632 00:30:31,680 --> 00:30:34,960 müssten und wie stellen wir in diesen einzelnen Systemen auch 633 00:30:34,960 --> 00:30:37,280 sicher, dass man da wirklich keinen Zugriff hat? 634 00:30:37,840 --> 00:30:39,520 Und so einen Freeze natürlich auch testen. 635 00:30:39,520 --> 00:30:41,600 Also ich muss natürlich auch testen, ob ich dann wirklich 636 00:30:41,600 --> 00:30:44,480 dieser Blog ausgelöst wird und dass ich jetzt vielleicht mal so 637 00:30:44,480 --> 00:30:47,200 ein Test Deployment in eine unkritische Umgebung oder zu 638 00:30:47,200 --> 00:30:49,680 einer Zeit, wo ich eigentlich keinen Freeze habe, mal teste 639 00:30:49,680 --> 00:30:52,480 und gucke, ob ich wirklich nicht deployen und wirklich keine 640 00:30:52,480 --> 00:30:55,760 Änderung machen kann für die Leute, wo das irgendwie wichtig 641 00:30:55,760 --> 00:30:57,880 ist. Ja, und zuletzt, und das hat man 642 00:30:57,880 --> 00:30:59,760 gerade schon erwähnt, ist natürlich wichtig. 643 00:31:00,360 --> 00:31:04,080 Zu wissen, was der Notfallhammer in dem Sinne ist, also wie wir 644 00:31:04,080 --> 00:31:08,320 quasi durchkommen, wenn es im absoluten Notfall auch möglich 645 00:31:08,320 --> 00:31:10,960 sein muss. Und dementsprechend sollte man 646 00:31:10,960 --> 00:31:14,240 sowas auch nicht überstürzen und dann einfach irgendwie alles 647 00:31:14,960 --> 00:31:19,200 entsprechend absperren und dann geht die einzige Person oder die 648 00:31:19,200 --> 00:31:21,120 Gruppe von Leuten geht dann erstmal irgendwie übers 649 00:31:21,120 --> 00:31:24,920 Wochenende raus oder in den Urlaub und am Ende kann niemand 650 00:31:24,920 --> 00:31:27,520 diese Sperren wieder rausnehmen und ich muss aber irgendwie 651 00:31:27,520 --> 00:31:31,280 einen kritischen. Edge entsprechend releasen und 652 00:31:31,280 --> 00:31:33,320 dann stehe ich halt entsprechend da und muss die Leute irgendwie 653 00:31:33,320 --> 00:31:35,960 aus dem Urlaub anrufen, damit die zurückkommen und die 654 00:31:35,960 --> 00:31:38,560 Konfiguration ändern. Das heißt, ich muss auf der 655 00:31:38,560 --> 00:31:43,040 einen Seite sichergehen, dass diese Limitierungen, die ich 656 00:31:43,040 --> 00:31:46,160 brauche, funktionieren, aber gleichzeitig muss ich 657 00:31:46,160 --> 00:31:49,600 sichergehen, dass ich auch einen Weg habe, im Notfall da 658 00:31:49,600 --> 00:31:53,400 durchzukommen, dass ganz klar der Prozess definiert ist, das. 659 00:31:53,760 --> 00:31:57,280 Also wie mache ich das technisch und welche Menschen müssen auch 660 00:31:57,280 --> 00:31:59,920 involviert sein? Das kann zum Beispiel ein 661 00:31:59,920 --> 00:32:03,760 Reliability Engineer Plus halt Management sein oder Management 662 00:32:03,760 --> 00:32:08,560 plus plus Product Manager, also in welcher Konstellation erlaube 663 00:32:08,560 --> 00:32:12,480 ich dennoch so ein Release oder so ein? 664 00:32:12,920 --> 00:32:16,480 Deployment während dieser Deployment Freeze Zeit und das 665 00:32:16,480 --> 00:32:18,880 muss natürlich ganz klar dokumentiert sein, man muss 666 00:32:18,880 --> 00:32:21,520 jederzeit nachschauen können, hey, wenn ich was Kritisches 667 00:32:21,520 --> 00:32:23,800 habe, mit wem muss ich sprechen und wie komme ich jetzt 668 00:32:23,800 --> 00:32:26,240 entsprechend auch zu einem Punkt, dass das Ganze in 669 00:32:26,240 --> 00:32:28,560 Produktion gebracht werden kann. Genau, vor allem mit wem muss 670 00:32:28,560 --> 00:32:30,080 ich sprechen? Es muss so eine manuelle 671 00:32:30,080 --> 00:32:32,840 Approval Kette quasi geben, ich kann ja nicht sagen, also ich 672 00:32:32,840 --> 00:32:35,280 will ja eigentlich vermeiden, dass jemand glaubt, dass sein 673 00:32:35,280 --> 00:32:38,160 Fotfix jetzt ganz ganz wichtig ist und dann aus Versehen 674 00:32:38,560 --> 00:32:40,600 irgendwas verschlimmbessert sogar noch, sondern ich glaube, 675 00:32:40,600 --> 00:32:42,400 dass das ist dann wirklich was, wo wichtig ist das. 676 00:32:42,960 --> 00:32:45,360 Da wird nichts alleine gemacht in dieser Zeit, da muss es immer 677 00:32:45,360 --> 00:32:47,080 mindestens ein 4 Augen Prinzip geben. 678 00:32:47,080 --> 00:32:49,920 Es muss eine klare Approval Kette geben, ich muss über sowas 679 00:32:49,920 --> 00:32:53,680 wie conditional access mir dann extra Zugang besorgen, der auch 680 00:32:53,680 --> 00:32:56,840 zeitlich limitiert ist, den ich begründen muss den ich approved 681 00:32:56,840 --> 00:32:59,320 bekommen muss und sowas und das muss natürlich auch klar 682 00:32:59,320 --> 00:33:01,960 definiert sein und sowas ist natürlich wirklich auch nur für 683 00:33:01,960 --> 00:33:05,680 echte echte echte Incidence, das ist jetzt kein Shortcut für Ah, 684 00:33:05,680 --> 00:33:08,880 mein Feature muss da doch noch irgendwie rein und eigentlich ah 685 00:33:09,040 --> 00:33:10,760 wir sind doch nicht fertig geworden, der CEO wollte das 686 00:33:10,760 --> 00:33:12,840 aber morgen auf der Bühne präsentieren, da braucht man. 687 00:33:12,920 --> 00:33:15,120 Auch eine Entscheidung für dann im schlimmsten Fall wird dieses 688 00:33:15,120 --> 00:33:17,640 Feature dann eben nicht auf der Bühne präsentiert, weil die 689 00:33:17,640 --> 00:33:19,840 Gefahr ja besteht, dass du das jetzt über diesen Shortcut da 690 00:33:19,840 --> 00:33:22,920 noch reinziehst und dann aber was einrichtest, was einen viel 691 00:33:22,920 --> 00:33:24,840 viel größeren Schaden anrichtet und da wird gar nichts mehr 692 00:33:24,840 --> 00:33:27,600 präsentiert und genau deswegen macht man ja diese Freezes. 693 00:33:27,600 --> 00:33:29,480 Also ich glaube, da muss man sich dann auch schon ganz klar 694 00:33:29,480 --> 00:33:31,840 dran halten. Wenn wir jetzt den Freeze 695 00:33:31,840 --> 00:33:34,760 eingerichtet haben und durch unsere Code Freeze oder 696 00:33:34,760 --> 00:33:38,080 Deployment Side durch sind. Dann müssen wir das Ganze 697 00:33:38,080 --> 00:33:41,400 natürlich auch wieder zurückbauen, auflösen und da 698 00:33:41,400 --> 00:33:44,800 haben wir auf der einen Seite auch der technischen aus der 699 00:33:44,800 --> 00:33:47,600 technischen Perspektive unsere Skripts, die Skripte, die wir 700 00:33:47,600 --> 00:33:49,760 ausführen. Wir müssen die entsprechenden 701 00:33:49,760 --> 00:33:54,160 Policies wieder deaktivieren und auch dafür brauche ich natürlich 702 00:33:54,160 --> 00:33:58,080 eine Checkliste, damit ich nichts vergesse, damit ich nicht 703 00:33:58,080 --> 00:34:00,720 auch in Situationen lande, dass ich vielleicht an einer Stelle 704 00:34:00,720 --> 00:34:03,680 immer noch die Blocker drin habe und die Person, die das dann 705 00:34:03,680 --> 00:34:05,880 freigeben muss, gerade nicht verfügbar ist. 706 00:34:05,880 --> 00:34:06,840 Wenn ich an dem nächsten Feature. 707 00:34:06,960 --> 00:34:08,880 Verarbeite und. Natürlich auch, genauso wie 708 00:34:08,880 --> 00:34:11,199 klare Kommunikation wichtig ist, wenn der Freeze eingeführt ist, 709 00:34:11,199 --> 00:34:13,000 vielleicht auch einfach noch mal eine E Mail an alle schreiben. 710 00:34:13,120 --> 00:34:15,960 Ey, der Freeze ist jetzt aufgehoben, hier sind die ersten 711 00:34:15,960 --> 00:34:19,800 Schritte für diesen Re rampup und vielleicht auch wenn wir 712 00:34:19,800 --> 00:34:22,239 sagen okay wir fahren das jetzt wieder so ein bisschen softer 713 00:34:22,239 --> 00:34:25,719 an, also kleine ungefährliche Änderungen zuerst und das 714 00:34:25,719 --> 00:34:27,199 Monitoring wieder eng im Blick haben. 715 00:34:27,440 --> 00:34:29,360 Eigentlich sollte da gar nicht so wahnsinnig viel passieren, 716 00:34:29,360 --> 00:34:31,280 weil wir haben ja nichts geändert, wir haben ja einfach 717 00:34:31,280 --> 00:34:33,440 nur nicht irgendwas gemacht, eigentlich haben wir nur nichts 718 00:34:33,440 --> 00:34:35,159 gemacht. Glaube ich trotzdem. 719 00:34:35,159 --> 00:34:37,440 Wichtig, dass alle, dass alle abgeholt sind, wieder am Boot 720 00:34:37,440 --> 00:34:38,719 sind. So, jetzt geht es wieder ganz 721 00:34:38,719 --> 00:34:40,719 normal weiter, die Leute, die vielleicht auch extra irgendwie 722 00:34:40,719 --> 00:34:43,840 on Call waren oder extra bereit standen, können wir wieder 723 00:34:43,840 --> 00:34:46,880 normal weiterarbeiten. Also ich würde auch immer das 724 00:34:46,880 --> 00:34:49,520 Aufheben des Freezes genauso kommunizieren wie das Einführen. 725 00:34:49,960 --> 00:34:52,560 Das heißt, wir können das Ganze so ein bisschen zusammenfassen 726 00:34:52,560 --> 00:34:56,199 unter dem unter dem Saat. Hey, wir wollen eigentlich nicht 727 00:34:56,199 --> 00:34:59,280 den Code Freeze, sondern wir wollen Deployment Freeze, 728 00:34:59,280 --> 00:35:02,600 zumindest solange wir uns in der saas Welt bewegen und. 729 00:35:02,800 --> 00:35:06,400 Und wir wollen auch an der Stelle sicherstellen, dass 730 00:35:06,480 --> 00:35:09,720 nichts kaputt geht, aber gleichzeitig wir die Möglichkeit 731 00:35:09,720 --> 00:35:13,840 haben, falls es Probleme gibt, diese Probleme auch wirklich 732 00:35:13,840 --> 00:35:17,320 zeitnah zu beheben. Ja, für so einen Freeze spricht 733 00:35:17,320 --> 00:35:19,600 da natürlich eigentlich, dass es, wenn ich wirklich ein 734 00:35:19,600 --> 00:35:22,000 Revenue Risiko zu einer gewissen Zeit habe oder irgendwelche 735 00:35:22,000 --> 00:35:24,400 Demos oder irgendwelche Krisen im Unternehmen, dass ich dann 736 00:35:24,400 --> 00:35:27,360 halt wirklich sagen kann, ey, ich muss in der Lage sein, das 737 00:35:27,360 --> 00:35:28,960 einzufrieren. Ich glaube, das braucht auch gar 738 00:35:28,960 --> 00:35:31,400 nicht jedes Unternehmen, sondern eben, wenn man genau. 739 00:35:31,400 --> 00:35:34,080 Genau diese Dinge, die wir besprochen haben, wenn man da 740 00:35:34,080 --> 00:35:36,920 sich eigentlich ganz, ganz sicher sein muss gegen so einen 741 00:35:36,920 --> 00:35:39,120 Freeze, spricht aber eigentlich, dass wir ja damit nur dass 742 00:35:39,120 --> 00:35:40,680 Symptome kämpfen und nicht die Ursache. 743 00:35:40,680 --> 00:35:43,200 Das sollte eigentlich kein Ersatz sein für gute cicd 744 00:35:43,200 --> 00:35:47,520 Prozesse, denn eigentlich sollten wir so testen und in 745 00:35:47,520 --> 00:35:50,560 Stages deployen und so weiter, dass sowas gar nicht passieren 746 00:35:50,560 --> 00:35:52,880 kann, dass wir in so eine Situation geraten, wo wir diesen 747 00:35:52,880 --> 00:35:56,960 Freeze einführen müssen. Bei Code gehe ich da aber 748 00:35:56,960 --> 00:36:00,160 vielleicht noch mit bei so kritischen Infrastruktur Changes 749 00:36:00,160 --> 00:36:02,800 oder auf irgendwie in. Jetzt auf die Idee zu kommen, 750 00:36:02,800 --> 00:36:05,880 den Club Anbieter zu wechseln oder sowas da aber nicht. 751 00:36:05,880 --> 00:36:07,760 Also das muss man natürlich schon irgendwie in die richtige 752 00:36:07,760 --> 00:36:11,440 Phase einplanen und auch hier noch mal der Vermerk, wenn man 753 00:36:11,440 --> 00:36:13,200 selber so ein bisschen das Gefühl hat, ja da könnten wir 754 00:36:13,200 --> 00:36:15,680 bestimmt was machen, wir sind nicht perfekt in unseren 755 00:36:15,680 --> 00:36:18,920 Prozessen, dann ist es auf jeden Fall sinnvoll auch in einem 756 00:36:18,920 --> 00:36:21,760 bestimmten Kontext das einfach als strategisches Werkzeug zu 757 00:36:21,760 --> 00:36:25,240 verwenden und zu sagen, Hey. Ja, eigentlich sollte man das 758 00:36:25,240 --> 00:36:26,680 nicht brauchen in der perfekten Welt. 759 00:36:26,680 --> 00:36:29,080 Wir haben hier aber keine perfekte Welt, deswegen gehen 760 00:36:29,080 --> 00:36:30,960 wir jetzt wirklich durch und kommunizieren diesen diesen 761 00:36:30,960 --> 00:36:34,000 Freeze und exerzieren den auch durch und heben den dann auch 762 00:36:34,000 --> 00:36:37,120 wieder auf. Uns würde interessieren, ob ihr 763 00:36:37,120 --> 00:36:39,800 Deployment Freezes macht. Bei euch im Unternehmen. 764 00:36:39,800 --> 00:36:43,800 Also schreibt uns gerne eine E Mail oder auf Spotify oder 765 00:36:43,800 --> 00:36:46,560 youtube könnt ihr natürlich auch Kommentare hinterlassen, wir 766 00:36:46,560 --> 00:36:49,360 finden das extrem spannend, einfach auch eure Perspektive 767 00:36:49,360 --> 00:36:52,480 dazu bekommen und für diejenigen, die es noch nicht 768 00:36:52,480 --> 00:36:55,360 machen, haben wir eine kleine Checkliste zusammengestellt, die 769 00:36:55,360 --> 00:36:59,040 würden wir jetzt einfach mal mit euch durchgehen damit wenn ihr 770 00:36:59,200 --> 00:37:02,640 Deployment Freezes einführen wollt, auch direkt wisst welche 771 00:37:02,640 --> 00:37:04,880 5 Schritte ihr dafür durchlaufen müsst. 772 00:37:05,200 --> 00:37:07,400 Genau diese Liste packen wir auch noch mal in die Show Notes. 773 00:37:07,400 --> 00:37:09,360 Das heißt, ihr findet unter der Folge das auch noch mal, wenn 774 00:37:09,360 --> 00:37:11,760 ihr das in eure eigenen Notizen kopieren oder weiterschicken 775 00:37:11,760 --> 00:37:14,800 wollt, so quasi als Zusammenfassung und sie fängt an 776 00:37:14,800 --> 00:37:17,600 mit dem ersten Punkt, oder das ist das Festlegen vom Scope. 777 00:37:17,600 --> 00:37:19,280 Also erstmal muss man überhaupt definieren. 778 00:37:19,840 --> 00:37:22,200 Was wird denn hier überhaupt eingefroren und wovon reden wir? 779 00:37:22,200 --> 00:37:24,400 Reden wir wirklich von einem Code Freeze, wenn wir Code 780 00:37:24,400 --> 00:37:27,040 Freeze sagen oder meinen wir eigentlich Deployment Freezezes 781 00:37:27,040 --> 00:37:30,320 und bezieht sich auch auf die CONFIG oder auf DNS Server? 782 00:37:30,400 --> 00:37:32,960 Und was ist eigentlich der Zeitraum, in dem wir das ganze 783 00:37:32,960 --> 00:37:35,880 Freezen wollen? Als zweites schauen wir auf die 784 00:37:35,880 --> 00:37:37,520 Risiken. Das heißt, wir gehen diese 785 00:37:37,520 --> 00:37:40,720 kritischen Systeme und entsprechende Stellen durch. 786 00:37:40,800 --> 00:37:43,080 Es kann unsere prot Umgebung sein, wie du gerade gesagt 787 00:37:43,080 --> 00:37:45,920 hattest. Dns Payment Authorization. 788 00:37:46,240 --> 00:37:49,840 Systeme, die bei einem Ausfall dazu führen können, dass unsere 789 00:37:49,840 --> 00:37:52,240 ganze Lösung nicht mehr richtig funktioniert. 790 00:37:52,240 --> 00:37:55,120 Das heißt, diese Stellen identifizieren wir und wissen 791 00:37:55,120 --> 00:37:58,160 dementsprechend auch, worauf wir achten müssten. 792 00:37:58,400 --> 00:38:01,360 Dann dritter Schritt kommunizieren, das ganze Team 793 00:38:01,360 --> 00:38:04,360 informieren, wirklich jeden, der betroffen ist, was ist wann ist 794 00:38:04,360 --> 00:38:07,680 Start, wann ist Ende, was ist erlaubt, was ist verboten, wer 795 00:38:07,680 --> 00:38:10,760 entscheidet, wer macht welche Freigaben und wie sieht der 796 00:38:10,760 --> 00:38:13,920 Eskalationspfad aus? Gehen erst dann gehen wir hin 797 00:38:13,920 --> 00:38:16,320 und nehmen die technischen Maßnahmen vor. 798 00:38:16,480 --> 00:38:20,000 Wir gehen hin und konfigurieren Branch Protection Rules, Wir 799 00:38:20,320 --> 00:38:23,040 rekonfigurieren unsere Deployment Rechte, schränken 800 00:38:23,040 --> 00:38:26,680 diese entsprechend ein und machen vielleicht einen Freeze 801 00:38:26,680 --> 00:38:30,160 Check in unserer cicd Pipeline, also genau diese Dinge die wir 802 00:38:30,160 --> 00:38:33,440 vorhin besprochen haben, werden an dieser Stelle technisch 803 00:38:33,440 --> 00:38:36,240 umgesetzt, um sicherzugehen, dass einfach nichts schiefgehen 804 00:38:36,240 --> 00:38:38,160 kann. Und als letztes auch natürlich 805 00:38:38,160 --> 00:38:40,720 den Notfall und das Ende planen. Ich fand diesen Begriff von 806 00:38:40,720 --> 00:38:43,440 diesem Notfallhammer so schön. Wie sieht er aus? 807 00:38:43,440 --> 00:38:45,760 Das müssen wir einmal definieren, was ist da genau der 808 00:38:45,760 --> 00:38:48,880 Pfad, dass dann doch vielleicht irgendjemand was freigeben kann, 809 00:38:49,040 --> 00:38:51,560 das wird einmal festgehalten, und natürlich brauchen wir auch 810 00:38:51,560 --> 00:38:54,360 ein klares Vorgehen zum Auflösen des Freezes, also wenn der 811 00:38:54,360 --> 00:38:56,720 wieder vorbei ist. Das muss einmal geplant werden 812 00:38:56,720 --> 00:38:59,120 und natürlich auch entsprechend technisch eingerichtet werden 813 00:38:59,120 --> 00:39:00,960 und natürlich auch kommuniziert werden. 814 00:39:01,200 --> 00:39:03,720 Und jetzt haben wir tatsächlich alles an der Hand, was wir 815 00:39:03,720 --> 00:39:07,120 brauchen, um so einen. Code Freeze oder Deployment 816 00:39:07,120 --> 00:39:10,000 Freeze auch in unserer Software oder unserem Unternehmen 817 00:39:10,160 --> 00:39:12,400 vorzubereiten, ob wir es brauchen. 818 00:39:12,400 --> 00:39:15,280 Wir haben ja vorhin darüber diskutiert, wann braucht man es 819 00:39:15,280 --> 00:39:18,560 und braucht man es überhaupt, aber ich denke mal es ist ein. 820 00:39:19,080 --> 00:39:22,160 Gutes Werkzeug, einfach das mal bei der Hand zu haben, um halt, 821 00:39:22,160 --> 00:39:25,280 wenn diese Diskussion mal aufkommt, das Ganze wirklich 822 00:39:25,360 --> 00:39:28,080 strukturiert beleuchten zu können und da auch keine 823 00:39:28,080 --> 00:39:29,840 überstürzten Entscheidungen zu treffen. 824 00:39:30,160 --> 00:39:32,480 Wenn euch die Folge gefallen hat, dann lasst uns gerne eine 825 00:39:32,480 --> 00:39:34,160 gute Bewertung da. Wir freuen uns auch immer sehr, 826 00:39:34,160 --> 00:39:36,240 wenn ihr uns einen Kaffee ausgebt. 827 00:39:36,480 --> 00:39:38,840 Ihr könnt auch gerne zu eurem eigenen Kaffee die passende Nerd 828 00:39:38,840 --> 00:39:40,400 Tasse haben oder wir haben so einen. 829 00:39:40,840 --> 00:39:43,280 Bei mir Coffee Link, wo ihr uns einen Kaffee spendieren könnt, 830 00:39:43,280 --> 00:39:45,600 da freuen wir uns immer sehr. Schaut da gerne in den Links 831 00:39:45,600 --> 00:39:47,360 vorbei, die ihr auch in den Shownotes findet. 832 00:39:47,520 --> 00:39:49,600 Und vielleicht noch für diejenigen, die bis zum Ende 833 00:39:49,600 --> 00:39:52,800 zugehört haben. Die Frage habt ihr gemerkt, was 834 00:39:52,800 --> 00:39:55,080 wir an unserem technischen Setup geändert haben? 835 00:39:55,080 --> 00:39:57,600 Wenn ja, schreibt uns gerne in die Kommentare, uns würde 836 00:39:57,600 --> 00:40:00,640 interessieren, ob es tatsächlich eine Verbesserung ist oder ob es 837 00:40:00,800 --> 00:40:03,440 so ist wie immer. Ansonsten hört auch gerne 838 00:40:03,440 --> 00:40:05,640 nächste Woche wieder rein. Der To do Kreis erscheint jeden 839 00:40:05,640 --> 00:40:08,480 Montag immer abwechselnd in einer Themenfolge wie dieser 840 00:40:08,480 --> 00:40:11,400 hier oder einer News Folge, wo wir dann die News der letzten 2 841 00:40:11,400 --> 00:40:13,840 Wochen von der Developer Welt so ein bisschen zusammenfassen. 842 00:40:14,080 --> 00:40:17,040 Seid also auch nächsten Montag wieder mit dabei und bis dahin 843 00:40:17,120 --> 00:40:20,160 habt eine gute Woche, schreibt viel Code, friert ihn nicht so 844 00:40:20,160 --> 00:40:22,560 oft ein sondern eher das Deployment und habt eine gute 845 00:40:22,560 --> 00:40:24,400 Zeit. Bis dahin.