Das Weihnachtsgeschäft oder die nächste wichtige Konferenz steht
bevor. Dann heißt es für kritische
Software oft Code Freeze. Aber ist das überhaupt noch
zeitgemäß oder ist das nur ein Symptom dafür, dass die eigene
Delivery Pipeline nicht reif genug ist?
Und falls man das braucht, was umfasst das alles und wie setzt
man den Code Freeze auch technisch und organisatorisch
vernünftig um? Darüber sprechen wir in dieser
Folge und am Ende gibt es sogar eine Chatliste zum Selbermachen,
viel Spaß. Und damit herzlich Willkommen zu
Folge 141 des To do Developer Podcast, Eurem deutschsprachigen
Developer Podcast auf allen Plattformen.
Und ihr hört wie immer Robin Manuel Thiel und mich.
Malte lantin ich bin Strategic Solution S Engineer bei Github
und Robin Manuel ist Director I und Cloud beim E Commerce
Software Unternehmen Jtl, aber den Podcast machen wir natürlich
wie immer privat und in unserer Freizeit, sprechen aber hier
über unsere Erfahrungen aus echten Projekten, an denen wir
tagtäglich arbeiten und heute gehen wir ganz tief in das Thema
Code freezes ein, aber eigentlich vielleicht.
Doch nicht geht es eigentlich um Code, freezes und geht es darum,
dass wir wirklich den Code einfrieren wollen oder wollen
wir eigentlich uns nur absichern, um halt in kritischen
Momenten eine lauffähige Applikation zu haben?
Das ist die Frage und deswegen starten wir erstmal mit den
Szenarien, wann eigentlich so ein sogenannter Code Freeze
relevant wird. Ja, meistens ja.
Dann, wenn ich irgendwie ganz, ganz sicher gehen muss, dass
jetzt gerade in dem Moment nichts schief läuft in meiner.
Applikation in meiner Infrastruktur oder was auch
immer ich da irgendwie bereitstelle.
Wir haben es ja gerade im Intro schon gesagt, wenn ihr diese
Folge hört, dann habt ihr den Black Friday gerade verpasst.
Ich weiß gar nicht, ist Cyber Monday ist das diesen Montag
oder war das letzten Montag? Ich bin in diesem ganzen Deals
Ding gar nicht gar nicht so wahnsinnig tief drin, was aber
auf jeden Fall gekommen ist. Zum Beispiel das
Weihnachtsgeschäft. Und das sind so ganz klassische
Stellen, wo man zumindest irgendwie, wenn man im E
Commerce unterwegs ist, auf jeden Fall sicher gehen will,
dass alles gut läuft. Es gibt aber auch ganz viele
andere Termine quasi im Jahr, das ist dann auf der
Unternehmensabhängig, das kann kurz vor einer großen Konferenz
sein, wo ein Produkt ankündigt oder wo man einfach generell mit
viel Aufmerksamkeit rechnet, dass man sich einfach, dass man
sicher gehen muss, hey, wir bauen jetzt nicht durch ein
Update, durch einen Patch, durch irgendeinen Deployment, einen
Bug, ein, einen Fehler ein und so weiter.
Ja, und die Frage ist Halt, ist das heute noch zeitgemäß,
wirklich den Code einzufrieren, weil wir sind ja in einer Welt,
wo wir Continuous Delivery machen, und ich glaube,
dementsprechend nutzen halt viele Unternehmen mittlerweile
den Begriff Code Freeze gar nicht mehr so häufig, auch wenn
er immer noch sehr populär ist, sondern man spricht häufiger
auch irgendwie über einen Change Freeze oder vielleicht auch
einen Deployment freeze, also. Ja oder so, Change Windows und
so was, das kommt alles so aus dieser ITIL und Change
Management Ecke, das macht dann halt oft klar, es geht ja
heutzutage um gar nicht mehr nur noch um Code sondern um jede
Änderung an einem produktiven System, auch so wie eine
Datenbank Schema Migration oder irgendwie DNS Einträge ändern,
das mache ich jetzt vielleicht nicht unbedingt vorm
Weihnachtsgeschäft, auch wenn ich das theoretisch natürlich.
Ich auch vorher in verschiedenen Umgebungen gut teste und so was,
aber es bleibt ja halt immer so ein kleines Restrisiko und
deswegen guckt man sich das an. Ich glaube Code Freeze ist
trotzdem immer noch so der am weitesten verbreitetste Begriff,
aber heute spricht man natürlich auch von anderen Dingen, wie es
gibt mit Configuration Freezes, Deployment Freezes oder man sagt
eben generell so so ein Change Freeze, dass man halt irgendwie
darunter versteht. Hey, wir machen jetzt keine
Änderungen, weil sie eben zu risikoreich sind.
Ein klassischer Code Freeze heißt ja, dass.
Zumindest, wenn wir jetzt in der Git Terminologie sind, dass wir
auf unserem Hauptbranch keine Änderungen durchführen
beziehungsweise nur kritische Fixes, die wir tatsächlich
brauchen, um unsere Anwendungen lauffähig zu halten.
Wenn ein Bug auftritt, müssen wir den natürlich fixen, aber
wir machen keine Änderungen mehr, wir schippen keine neuen
Features mehr und das kommt ursprünglich ja aus der Welt, wo
wir tatsächlich noch eine bestimmte Version der Software
fertiggestellt haben, die wir zum Kunden ausgeliefert haben.
Also ganz klassische Selbstbetriebene Software,
dementsprechend in der saas Welt gibt es ja eigentlich keine
klassischen Code freezes auf bestimmten Versionen mehr, weil
wir ja tatsächlich regelmäßig Updates liefern, dann unsere
Kunden und diese werden ja in der Regel nicht mit einer
bestimmten Versionsnummer bestückt, von daher ist ja mal
die Frage was. In welcher Art von Software bin
ich jetzt hier unterwegs, wenn ich immer noch klassische
Versionierung mache, mache ich vielleicht noch Code freeze,
aber jetzt nicht aus dem Grund, den du gerade genannt hattest.
Dass ich zum Beispiel irgendwie eine sehr kritische Zeit des
Jahres habe, sondern ich mache diesen Code freeze, weil ich
weiß. Das ist jetzt Version x.
Die wird zum Kunden ausgeliefert und dementsprechend kann ich
jetzt keine neuen Features mehr hinzufügen, weil vielleicht noch
letzte Tests durchgeführt werden müssen.
Auf dieser Software und dann soll diese Software sich nicht
noch weiter verändern. Ganz früher wurde das Ganze
immer noch irgendwie auf DVD, CD oder einen anderen Datenträger
gebracht und dann zum Kunden ausgeliefert, da war es
natürlich noch kritischer. Aber wie gesagt, heute immer
noch bei der Software, die selbst betrieben wird, durchaus
ein relevantes Konzept, aber darum soll es ja eigentlich gar
nicht gehen, sondern wir reden jetzt darüber, dass unsere
Software stabil laufen soll, wenn es drauf ankommt und dafür
ist natürlich gerade so in der SARS Welt das Thema Deployment
Freeze relevant. Ja, der alte Mann erzählt hier
von früher, wo man noch Software wirklich auf Datenträgern an die
Kunden geschippt hat. In der in der modernen SARS und
Cloud Welt, da reden wir natürlich, wie du gerade gesagt
hast, eher von einem Deployment Freeze.
Das hat den großen Vorteil die Entwicklung und Merges von
meinem Code laufen eben weiter, aber ich will keine Deployments
mehr in Produktion haben, das heißt ich schaue da eher, dass
ich sage okay, wir haben jetzt einen Stand, mit dem gehen wir
jetzt durch diese entsprechende kritische Zeitspanne, diese
Periode, wo wir jetzt sagen, wir machen da keine Änderungen, ich
kann natürlich trotzdem weiterentwickeln, das ist halt
der große Vorteil meiner Development Teams.
Arbeiten weiter, aber ich mache eben keine Deployments mehr und
eigentlich geht damit auch immer einher ein Configuration Freeze,
das heißt ich habe auch keine Änderungen mehr an meinem
Hosting Provider oder an meiner Cloud Infrastruktur, sondern
fokussiere mich halt auf maximale Stabilität.
Ja, und tatsächlich? Dieses Konzept ist Deployment
Freeze und Configuration Freeze kannte ich vorher schon, aber
jetzt haben wir uns natürlich so ein bisschen in das Thema noch
weiter eingelesen und was ich ganz interessant fand, dass es
wohl auch den Begriff des Code slush oder?
Oder Code chill gibt also irgendwie dieses Slush ice, wo
man irgendwie ein Eis hat, aber es ist nicht ganz fest, sondern
irgendwie noch flüssig und das soll so ein bisschen
beschreiben, dass man so ein bisschen weicheren Ansatz wählt
und vielleicht weiterhin Änderungen in Produktion stellen
kann, aber das sind nur Änderungen, die Halt als Low
Risk klassifiziert sind, das heißt Änderungen, die nicht zu
einem Totalausfall meines Systems führen können.
Wobei, da muss man, glaube ich sagen, das ist, glaube ich, die
höchste Kunst davon. Wir werden uns ja gleich in der
Folge so ein bisschen anschauen und.
Wie man das umsetzen kann, so einen Freeze.
Und natürlich ist es deutlich einfacher, einen harten Cut
umzusetzen und der ist schon nicht einfach umzusetzen als so
eine leichte Variante, weil da die Teams eben selber
entscheiden müssen, wie risikoreich sind welche
Änderungen und da kann ich mir gut vorstellen, dass die Teams
selber vielleicht oft gar nicht die besten Personen sind, um
genau das zu entscheiden, weil wenn wir über solche kritischen
Phasen sprechen, dann mag das Team sich ganz, ganz sicher
sein, dass der Hotfix hier gut funktioniert.
Wenn der CEO aber morgen auf der Bühne steht und ein Produkt
präsentiert, und das muss einfach funktionieren, ist der
wahrscheinlich anderer Meinung. Ob er jetzt noch ausgespielt
werden muss oder nicht. Deswegen ist das glaube ich
schwierig umzusetzen oder man muss eine sehr klare
Reportingstruktur oder so eine Freigabestruktur haben, reden
wir aber gleich noch drüber. Wichtig ist aber, dass das ein
echtes und relevantes Thema ist. Also das ist jetzt nichts
irgendwie, was nur in den Lehrbüchern steht und nichts und
jetzt so wie nicht vorkommt. Wer so meine letzten Karriere
changes so ein bisschen verfolgt hat, der weiß, ich werde
wahrscheinlich jetzt noch in vielen folgenden Folgen viel
über den E Commerce reden, weil da arbeite ich jetzt gerade nur
mal in der E Commerce Software Bude und das ist natürlich
gerade so. Jetzt die Blackweek die jetzt
gerade war und das direkt danach anstehende Weihnachtsgeschäft,
da ist halt ein da ist halt ganz ganz klar, da gibt es ein ganz
realistisches Risiko, jede Minute Auswahl kostet den E
Commerce halt direkt Umsatz, das knallt direkt rein und.
Und deswegen muss man natürlich zu gewissen Zeiten einfach ganz,
ganz sicherstellen, dass das System online ist.
Ja, und du hattest gerade wie erwähnt so das Thema.
Der CEO steht auf der Bühne und stellt neue Features vor, das
ist auch etwas, was ich sehr gut nachvollziehen kann, wir hatten
ja gerade im. Im letzten Monat oder im
vorletzten Monat? Die github Universe und da
werden natürlich auch von github immer ganz viele neue Sachen
live auf der Bühne zum ersten Mal präsentiert und
dementsprechend gibt es da auch in den Tagen davor einen
Deployment Freeze um halt sicherzustellen, dass nicht noch
irgendwelche Last Minute changes dann geshippt werden.
Wir machen ja normalerweise so Continuous Delivery diverse
Ships an einem Tag und natürlich sollte es nicht so sein, wenn
dann die Live Demo läuft, dass plötzlich dann irgendwie das UI
an. Das aussieht oder irgendwelche
Preview Features noch mal sich verändert haben und es darf ja
auf keinen Fall während einer solchen Präsentation, wo
irgendwie Millionen Leute live irgendwie so einen Livestream
gucken, dann so ein System ausfallen aufgrund von
irgendwelchen Fehlern, weil ich glaube das ist der wichtige
Punkt, dass es jetzt nicht darum geht, dass wir irgendwie unsere
Systeme als Software unternehmen nicht im Griff haben.
Egal welche Art von softwaresystem Wir betreiben,
sondern es geht um die Realisierung.
Dass am Ende Menschen immer Fehler machen können.
Und wir dürfen halt an manchen Tagen keine Fehler uns erlauben,
weil halt dementsprechend ein entsprechender Umsatzausfall
oder Geschäftsausfall in irgendeiner Art und Weise oder
vielleicht auch einfach nur ein Reputationsschaden möglich ist.
Ja genau, da merkt man schon, das ist ein ganz wichtiger
Punkt. Also ich glaube, wir sind uns
einig, es geht eigentlich in so einer.
Halbwegs modernen Welt, wo wir keine Software mehr auf CD S
oder Disketten schippen, eben um diesen Deployment Freeze, aber
auch, wie du gerade gesagt hast, da geht's ja dann nicht nur um
Code, sondern wenn ich irgendwie, das ist ja auch oft
ganz viel Konfiguration, das sind zum Beispiel irgendwelche
Feature flags, mit denen man zum Beispiel arbeitet, das kann ja
durchaus sein, dass das Feature schon lange geschippt war.
Das heißt, der Code, der ist schon lange auch schon deployed.
Aber ich muss natürlich auch dafür sorgen, dass ich in so
einer Zeit dann nicht irgendwie für alle User so einen Feature
Fleck freischalte oder Environment Variablen Ender oder
irgendwelche applikations Settings mache oder irgendwelche
Änderungen an der Infrastruktur oder ich habe es eben schon
erwähnt. Datenbankschema Migration oder
irgendwelche neuen background Jobs oder irgendwelche batch
Scripte einführe oder worst case sogar irgendwas in den DNS
Änderungen mache. Warum worst case?
Weil DNS ist ja so ein bisschen eine Natur der Sache, hat eine
kleine Änderung, hat aber einen riesigen Blast radius weil der
ganz viele DNS Server dann da wieder draußen vielleicht die
fehlerhafte Änderung cashion das ist etwas was ich auch nicht so
schnell zurückrollen kann, wenn ich jetzt irgendwie noch wenn
ich irgendwie sofort merke, dass ich da vielleicht was was viel
konfiguriert habe. Deswegen kann man glaube ich
schon sagen, wir reden eher von einem Konfigurations oder
Deployment Freeze in unserem Fall und gar nicht mehr so sehr
von einem Code freeze. An einer Stelle muss man aber
noch vielleicht ein bisschen differenzieren.
Gerade bei den Feature Flags, da werden ja gerade bei Konferenzen
diese Feature flags auch verwendet, um neue Features
quasi während der Keynote für alle freizuschalten, aber am
Ende geht es ja darum, dass. Die Leute dann auch wirklich
dieses Feature so bekommen, wie es vorher umfangreich getestet
wurde und nicht vielleicht eine halbe Stunde vorher noch
jemanden update geschippt hat. Und dann.
Schickt man entsprechend den Button für das Feature Flag und
plötzlich wird etwas freigeschaltet, was niemand
vorher Jesu getestet hat und ich glaube gerade das Thema Feature
Flags ist ganz spannend. Wir haben eine Folge dazu
gemacht, wir haben aber gerade gemerkt, das war Folge 13, von
daher waren wir da glaube ich noch technisch und fachlich noch
nicht so weit wie wir heute sind, aber wer dennoch mal
reinhören will, findet ihr bei den ganz alten Folgen ganz weit
unten in der Liste. Genau.
Also das ist so ein bisschen der Hauptgrund, warum man so was
macht. Es gibt noch 2 andere Gründe,
warum man sich generell um so, ja, ich nenne es jetzt weiterhin
Code freezes, aber generell um diese diese Freezes bemüht, und
das ist zum einen, es gibt Zeiten, in denen man wenig
Personal oder Spezialwissen im Unternehmen hat, das kann
entweder ganz klassisch sein über Urlaubszeiten oder
Feiertage oder gerade jetzt, zurzeit sind viele krank,
irgendwie so eine Krankheitswelle und dann kann es
natürlich passieren, dass ein einfach bestimmte Key Personen
nicht erreichbar sind. Wenn ich irgendwie sage, ey
genau 2 Leute im Unternehmen kennen DNS oder wissen wie wir
unsere DNS konfigurieren und die sind gerade beide im Urlaub,
dann sagt man natürlich auch okay, dann versuchen wir, wenn
es jetzt nicht unbedingt ganz ganz wichtig ist, in der Zeit
den DNS Server nicht anzufassen oder ich habe irgendwelche
anderen speziellen unternehmenssituationen ich habe
Restrukturierungen, migrationsprojekte, Krisen,
vielleicht sogar einfach Personalmangel, also nicht nur,
dass Leute im Urlaub sind, sondern gar nicht da sind, dann
muss ich mir natürlich auch so ein bisschen darüber Gedanken
machen. Wir reden jetzt aber heute in
dieser Folge eher von den regulären Sachen, also von
denen, die auch planbar sind, weil da geht es auch gleich so
ein bisschen darum, wie plant man sowas, wie kommuniziert man
sowas aber generell so als Thema kann man glaube ich schon sagen,
dass diese Freezes eigentlich ein Schutz sind vor Risiko und
vor allem so vor riskanten und unkoordinierten Änderungen.
Ja, und da muss man sich halt immer fragen, wann kann man
diese Risiken nicht eingehen oder wann sind diese Risiken
besonders groß und. Und du hast ja gerade schon
gesagt, Urlaubszeit, aber es kann natürlich auch sein, dass
vielleicht gerade durch eine Umstrukturierung einige
Verantwortlichkeiten nicht mehr klar sind, und da ist natürlich
kein guter Zeitpunkt, um umfangreiche Änderungen
vorzunehmen, aber das sollte eigentlich selbstverständlich
sein und wenn wir jetzt so darüber sprechen, hört sich das
auf der einen Seite sehr nachvollziehbar an, dass man so
etwas macht, aber auf der anderen Seite widerspricht das
ja so einem. Klassischen Continuous Delivery.
Ich hatte ja gerade gesagt, üblicherweise in einem Saar
Service sind wir quasi kontinuierlich dabei, neue
Features, neue Funktionalitäten zu schippen und das muss man ja
an dieser Stelle durch so einen Freeze ganz bewusst unterbrechen
und dann quasi irgendwie auf die Bremse treten und dann passiert
halt erstmal nichts. Ja, voll also eigentlich hast du
völlig recht. Eigentlich widersprechen diese
Freezes so einem klassischen Cicd oder so einem agilen Ideal.
Also ich habe. Eigentlich.
Eigentlich muss man ja schon sagen, so, wenn Angst vor einem
Merch zu kritischen Zeiten zeigt ja eigentlich, dass man kein
echtes Vertrauen in die zumindest mal die CD Pipeline
hat. Die Idee ist ja eigentlich, dass
ich ein Setup habe. In dem ich jederzeit deployen
kann, weil ich ja teste und Monitore und im Idealfall mit
Canary deployments Dinge nicht direkt an alle User Ausrolle
oder Feature Flex habe, die ich im kritischen Fall wieder
abschalten kann oder Mechanismus habe um Rollbacks zu machen und
so weiter also eigentlich, wenn ich jetzt wirklich nach Lehrbuch
arbeite, könnte man argumentieren, dass man das gar
nicht braucht. Ja, aber auf der anderen Seite.
Und ich hatte es ja vorhin schon erwähnt.
Machen Menschen halt Fehler und ich glaube, niemand von uns kann
sagen, ich habe noch nie einen Fehler gemacht, der dazu geführt
hat, dass die Applikation, die gerade in Produktion läuft, ein
Problem hat. Also ist mir auch schon
passiert, da muss man natürlich da entsprechend drauf reagieren,
aber daran merkt man natürlich, dass in bestimmten Zeiten
einfach diese Änderungen. Vielleicht unterlassen werden
müssen, weil halt irgendjemand immer einen Fehler machen kann.
Was ich ganz interessant finde, ist einfach mal vielleicht auch
in den auf die Statuspage von diversen SARS Anbietern zu gehen
und sich einfach mal anzuschauen, wie viele Incidents
die letzten Endes haben und wenn selbst die größten SARS Player
des Planeten regelmäßig solche Incidents haben im normalen
Alltag, dann kann man glaube ich nicht von sich sagen, ja wir
sind viel reifer als diese großen Player und bei uns
passiert das nicht und deswegen können.
Können wir halt die ganze Zeit durchshippen, egal wie kritisch
die Zeit ist. Ich glaube, so arrogant dürfen
wir da auch nicht sein. Und dazu kommt natürlich auch,
dass ich jetzt auch noch wenige Unternehmen gesehen habe, die
wirklich dieses perfekte Lehrbuch mit Canary und Blue
Green und Feature Fakes und Rollbacks und sowas wirklich
durchexerzieren. Ich glaube da wollen alle hin
und alle nehmen sich so ein bisschen die Sachen da raus, die
entweder für sie besonders wichtig sind oder Law hanging
Fruits sind, aber. War da muss man ja auch mal dazu
sagen, es ist ja auch unrealistisch, wirklich davon
auszugehen, dass das überall genauso perfekt gelebt wird.
Und dazu kommt natürlich auch, dass ja offenbar auch in den
Firmen, die sich das leisten können oder die das so aufgebaut
haben, diese Fehler passieren, und es gibt ja auch noch ein
paar andere Probleme von diesen Freezes.
Ich habe dann oft so einen, wenn ich wirklich einen richtigen
Code freeze mache, habe ich danach so einen Merch Rush, also
ich habe ganz viele aufgestaute. Sag ich mal Pull requests zum
Beispiel oder merge requests. Je nachdem welche Tool man
verwendet. Nach diesem Freeze oder so ein
Quality Drop vor dem Freeze, dass ich eine Zeit lang wirklich
auch keine neuen Sachen shippe und ich unterbreche halt so ein
bisschen mein Flow und Sorge natürlich auch für in der Zeit
für deutlich weniger Wertschöpfung wirklich für so
eine Verlangsamung meines Unternehmens.
Ja, du hattest gerade gesagt, man hat dann so ein bisschen so
einen Stau, der sich dann da aufbaut, und der muss ja auch
nachher abgearbeitet werden. Das heißt, man hat dann
natürlich auch einen höheren Workload nachher, weil man die
ganzen Sachen, die man dann jetzt nicht gemergt hat, bei
einem echten Code Fries. Die muss man dann nachher
reviewen und dann entsprechend mergen.
Aber auf der anderen Seite hast du natürlich das Problem, dass
wenn du eine bestimmte Deadline setzt und sagst, hier ab dem
Zeitpunkt herrscht ein Deployment Freeze, dass
natürlich alle auf diese Deadline hin arbeiten müssen,
entweder am Beispiel einer Konferenz diejenigen, die die
neuen Features für diese Konferenz bauen, die müssen
genau auf diese Deadline arbeiten, da kann es natürlich
zu Zeitdruck kommen, aber auch so ganz persönliche Sachen.
Stell dir vor, du bist irgendwie ein PM, du arbeitest an einem
Feature und dann. Kommt vielleicht mit sehr kurzem
Vorlauf irgendwie 46 Wochen. Kommt dann jemand zu dir?
Du arbeitest seit einem halben Jahr in einem Feature, sagt er
okay, da ist entsprechend Code Freeze oder Deployment Freeze,
aber in deinen persönlichen Commitments steht halt drin,
dass du zu einem bestimmten Datum dein Feature geshippt
hast. Und da kannst du natürlich schon
ganz schön unter Druck kommen und du hast gerade gesagt, dann
kann das auch zu einem Qualitätsverlust führen, weil du
dann sagst ja. Ja, ich muss das aber vor dieser
Deadline noch rüberbringen und eigentlich hatte ich geplant das
2 Wochen später zu releasen und dann wird es am Ende hin eng und
das wollen wir eigentlich vermeiden und ich glaube wir
sprechen gleich noch mal ein bisschen über die Taktik, wie
man so einen Deponment Freeze sinnvoll einführt und dazu
gehört zum Beispiel um mir zu viel vorzugreifen, dass man es
natürlich ausreichend vorher plant und kommuniziert.
Generell finde ich diesen Gedanken aber gar nicht so
falsch zu sagen. Eigentlich widerspricht es ja
unserem Ideal. Und deswegen finde ich, kann man
auch schon sagen, so, wenn man einen Freeze braucht, dann
sollte man vielleicht noch ein bisschen reindrillen.
Warum brauchen wir den denn oft können die ein Anzeichen dafür
sein, wo ich eben meine eigenen Prozesse oder vielleicht vor
allem so meine Observabilities oder Rollbacks oder mein Testing
oder sowas. Eben noch verbessern kann.
Also ich kann ja sagen okay, wir brauchen auf jeden Fall einen
Code freeze, aber es kann ja das Ziel sein, dass wir das in
Zukunft nicht mehr brauchen oder immer weniger brauchen.
Nur die Tatsache, dass wir es jetzt brauchen, zeigt dann einem
vielleicht ja selber auch noch mal so ein bisschen auf, dass
man da vielleicht noch nicht in diesem Idealzustand, den wir
eben beschrieben haben, erreicht hat, weil es kann ja sein, ich
habe vielleicht trotzdem meinen Code freeze, aber es bleiben
Risiken, weil irgendwelche config oder vielleicht also dass
irgendwas nicht nicht mitgedacht wurde.
Und jetzt irgendwie trotzdem eine Änderung an Datenbank
Schemata gemacht oder was was weiß ich und das deckt ja dann
oft auch einfach so Dinge auf. Wir hatten zum Beispiel bei uns
im Unternehmen kann man sagen, wir nutzen eigentlich für alles
was Cloud Konfiguration ist. Terraform, das heißt man ist
sich relativ sicher zu sagen okay Pass auf, wenn wir jetzt
dieses Repository einfrieren, was für dieses Produkt die Cloud
Infrastruktur aufsetzt, dann werden da auch keine
Infrastruktur chaines gemacht. So, jetzt muss ich aber trotzdem
gucken, ist das wirklich alles, ist es die gesamte Infrastruktur
oder gibt es nicht vielleicht doch noch irgendwelche?
Wir hatten eben das Beispiel DNS Configs, die vielleicht beim
Domain Provider liegen, die gar nicht mit Terraform verwaltet
werden, oder kann es denn vielleicht trotzdem sein, dass
ich mich ja vielleicht dieses Repository eingefroren habe, man
aber trotzdem vielleicht ins Cloud Portal gehen kann und da
manuelle Änderungen machen kann? Sollte natürlich alles nicht
sein, aber da muss ich mir trotzdem Bewusstsein, dass nur
weil ich Code einfriere an irgendeiner Stelle und selbst
wenn es Infrastructure s Code ist, dann.
Das ja nicht auch automatisch heißt, dass ich ja alle alle
Sachen mitgedacht haben, alle Risiken damit abgedeckt haben
und dann ist das ja oft ein Zeichen dafür, dass hey, wenn
ich deswegen jetzt eine Kommunikation machen muss oder
was einfrieren muss, dann sind das vielleicht noch Dinge, die
ich noch vielleicht dahin holen sollte oder woanders mal
vielleicht irgendwann den Zugang abdrehen sollte und so, ich
finde, das kann einem schon viel aufzeigen, wenn man so einen
Freeze braucht, wo noch Verbesserungsbedarf.
Ist die Frage, ist halt auch immer, wie häufig kommt das vor.
Ich glaube wenn man irgendwie. Einmal, zweimal im Jahr, wenn
man irgendwie jetzt im E Commerce unterwegs ist und sagt,
man macht das irgendwie vor Black Friday und in der
Weihnachtszeit, dann ist das ja glaube ich fein.
Aber es gibt natürlich auch Situationen, da wird dann
irgendwie einmal im Monat die letzten Tage des Monats ein Code
Freeze gemacht, weil da ist immer Vorstandssitzung, und das
ist ja ein rein interner Grund, und dass man das jedes Mal
macht, zeigt halt, dass man auch kein Vertrauen in die eigene
Qualität und die eigene Qualitätssicherung hat und.
Und ich glaube, man muss da natürlich differenzieren, an
welcher Stelle halt das Risiko so groß ist, dass sich dieser
Eingriff tatsächlich in dieses Continuous Delivery wirklich
auch lohnen kann. Ja gut, da kommen wir jetzt mal
zur Umsetzung. Also wie setzt man denn jetzt so
einen Freeze? Wie auch immer man den jetzt
nennt, konkret um einen Punkt finde ich ganz ganz wichtig, den
hast du gerade schon so ein bisschen gesagt, Kommunikation
und ich glaube das ist auch oft das, was in so einer komplett
technischen Umgebung manchmal hinten überfällt und.
Ganz wichtig, frühzeitig ankündigen, alle müssen Bescheid
wissen, der Zeitraum muss klar definiert sein, der Umfang muss
klar definiert sein, betroffene Umgebungen müssen benannt
werden, also klarstellen, was genau ist eingefroren reden wir
von Codes oder reden wir von den Deployments oder nur von
Konfiguration und Infrastruktur, gibt es Ausnahmen, wie sieht
eine Eskalationspfad aus? Also es wird ja trotzdem
passieren, dass wir eventuell doch was hotfixen müssen, wenn
ich jetzt einfach sage ich. Schmeißt alle Leute aus meinem
Repo raus und keiner kann jetzt mehr irgendwas.
Da muss ich ja trotzdem irgendwie einen Eskalationspfad
einrichten und es muss natürlich auch klargestellt werden, was
machen wir in der Zeit stattdessen, also geht es
trotzdem irgendwie weiter gut, wenn wir uns eigentlich darauf
geeinigt haben, dass wir keinen Code freeze machen, kann
natürlich weiterentwickelt werden, aber es ist ganz
wichtig, gerade auch gerade, wo du sagtest, eben da hängen ja
auch andere Stakeholder dran, wie zum Beispiel eine PM oder
eine Deadline oder der CEO will auf der Bühne irgendwas
präsentieren, was bislang fertig sein muss, also.
Also wenn wir uns entscheiden, so einen Freeze zu machen, ganz
wichtiger erster Punkt, Kommunikation frühzeitig
Zeitraum, Umfang, Umgebungen definieren.
Ja, und das hängt ja auch direkt mit den technischen Maßnahmen
zusammen, weil wenn wir auf der technischen Seite jetzt hingehen
und bestimmte Permissions beschränken, das heißt, nur noch
bestimmte Gruppen dürfen entweder ein Deployment
freigeben, sie dürfen bestimmte Konfigurationsänderungen
vornehmen oder einfach einen. Pr freigeben, damit er gemergt
werden kann. Das hängt ja aber so ein
bisschen davon ab, wie auch das eigene Deployment Modell läuft,
wenn unser Main Branch immer automatisch in Production
geshippt wird, dann muss ich schon an der PR stelle angreifen
und da bestimmten Leuten nur noch das Recht geben so ein.
Feature Branch zu Mergen und das hängt natürlich dann mit dieser
kommunikativen Maßnahme zusammen.
Es muss allen klar sein, wer solche Dinge dann am Ende
freigeben kann und muss. Du sagst gerade, es muss ja auch
Ausnahmen geben, das heißt, wenn ich irgendwelche kritischen
Probleme habe, die müssen gefixt werden und dann kann es
natürlich nicht sein, dass irgendwie nur der CEO am Ende
den PR freigeben kann und der CEO steht aber gerade auf der
Konferenz auf der Bühne, kann aber gerade nicht und alle
sitzen irgendwie. Im Office und können halt einen
kritischen Fix nicht ausrollen. Ich meine, im Fall von Gitter
wäre das eine wirklich coole Demo, ehrlich gesagt.
Wenn man dann auf der Bühne den PR freigeben muss, weil gerade
irgendwas nicht funktioniert, aber ich glaube, da hängen diese
beiden Themen halt sehr eng zusammen.
Kommunikation und die technischen Maßnahmen, die
entsprechend eingerichtet sind, und da ist natürlich die erste
technische Maßnahme, zu schauen, wie sehen meine Brunch
Protection Rules aus, welche Policies habe ich konfiguriert
und. Und wie muss ich das jetzt
entsprechend in dieser Zeit des Deployment Freezes anpassen,
damit es halt verhindert, dass nicht business as usual
weiterläuft? Ja, das ist ganz wichtig.
Es reicht nicht, irgendwie eine E Mail zu schreiben, sondern das
muss eben auch wirklich dann nicht mehr möglich sein zu
deployen, zumindest nicht auf dem normalen Weg, und da gibt es
ja diverse Sachen. Also du hast gerade schon
gesagt, so in der github Welt, da kann ich ja so.
Protection Policies auf bestimmte Branches setzen.
Gerade wenn ich mich, gerade wenn wir uns reinigen soll,
weiter programmiert werden, dann kann ich ja nicht auf einmal den
Leuten Zugang zu dem Repository wegnehmen, ist auch glaube ich
nicht nicht sinnbehaftet, sondern muss eben dann ein
entsprechendes permissions Konzept aufbauen, das heißt ich
brauche auch vielleicht verschiedene Gruppen, die dann
nur noch PS freigeben können, bedeutet aber auch wiederum, ich
muss bei meinem Rollen und rechte Konzept das Code Free
Szenario von vornherein mitdenken und.
Und dann muss ich natürlich technisch das so umsetzen, dass
während dieser Zeit ich quasi sage, dass nur noch diese
Gruppen Pairs Fall gehen können. Vielleicht sind das auch
verschiedene Gruppen pro pro Repository, oder das ist
wirklich halt dann ein kleiner Kreis, weil man dann wirklich
sagt, für diese Repository nur für den Ernstfall keine Merches
passieren hier mehr ohne Approval, zumindest nicht auf
irgendwelche Main trunk oder Release branches die das
irgendwie gehen. Und ja, so eine, so eine
Protection muss man dann eben Repository weit einführen.
Man kann das theoretisch auch schon, ich rede das auch viel
von Gitter, weil malte und ich natürlich super viel in dieser
Welt unterwegs sind, kann natürlich auch sagen, wir
hinterlegen in jedem Repository schon mal so eine Brunch
Protection, schalten die aber nicht scharf, stellen aber
sicher, dass wir das Repository weit könnten und wenn dann der
Code Freeze kommuniziert wird, dann schalten wir diese diese
Regel scharf, die auf einmal für Pull Requests auf ganz bestimmte
Brunches diese extra Protection layers ein für das ist.
Eigentlich auch gar nicht mehr, geht aus dem Ausnahmefall und
kann die dann nachher wieder deaktivieren.
Und wenn ich jetzt jetzt in meiner Code Management Plattform
nicht kann, dann kann ich natürlich auch über AP is
entsprechende Konfigs vorbereiten, diese dann
entsprechend scharfstellen oder wieder deaktivieren.
Oder ich greife an einer anderen Stelle entsprechend in den
Prozess ein. Es kann zum Beispiel die cicv
Phase sein, wo dann die Pipeline, wenn ein bestimmtes.
Bestimmte Variable gesetzt ist einfach abbricht.
Das heißt, ich setze einfach während dieses Deployment
Freezes eine Umgebungsvariable, welche bestimmt, dass halt die
Pipeline gar nicht durchläuft und wenn dann doch irgendwie
Code gemergt wird, dann kommt der gar nicht in Produktion,
weil die Pipeline abbricht. Ja, Skript ist vor allem dann
natürlich eine wichtige Geschichte, wenn ich jetzt sage,
ey. Wie wir zum Beispiel haben über
100 Repos, da kann ich jetzt ja nicht überall manuell
irgendwelche Policies umschalten oder ändern.
Ist ja auch natürlich wieder, weil es ein menschlicher Faktor
ist. Die Gefahr viel zu groß, dass
ich 1 vergesse, wenn ich das dann halt irgendwie zum Beispiel
skripten kann, dass ich da diese bestimmten Funktionen oder
Änderungen per Skript ausrolle oder ich kann ja bei github
sogar so Enterprise weit irgendwelche Regeln und Dinge
für meine. Repositories definieren, dann
sollte ich das natürlich an einer zentralen Stelle machen,
dann kann ich natürlich auch ganz, ganz viele Repositories
gleichzeitig davon betreffen. Man geht auch selber, weil es
wird auch unser unser Beispiel ist.
Kann man zum Beispiel sogar diese diese Regel, hey.
Ein Review auf diesem also ein Review zu diesem Branch oder
dieser Branch Familie, muss jetzt von bestimmten Teams
erfolgen. Für eine Poly request.
Das könnte man zum Beispiel zentral an einer Stelle
hinterlegen, das wäre so eine Möglichkeit.
Aber wie gesagt, wenn ich nicht, wenn ich etwas anderes als
Github verwende, dann gibt es da entweder auch irgendwas was ich
zentral steuern kann oder ich gehe wirklich dieses Thema
Scripting durch, da würde ich aber einmal kurz vorher den
Skript testen und natürlich mir auch irgendwie verifizieren
lassen, dass das jetzt wirklich auch bei allen Repos, die dieser
Freeze betrifft es. Entsprechend erfolgreich
umkonfiguriert wurde. Genau und im besten Fall ist es
so, dass ich halt ganz klar weiß, welche Gruppe von Leuten
kann auch ein Deployment, was nötig ist freigeben und da ist
es natürlich dann nicht ideal, wenn ich irgendwie einen hacky
Workaround gebaut habe mit irgendwelchen Labeln oder
Umgebungsvariablen, die ich dann temporär zurücksetzen muss und
dann rutscht mir vielleicht doch was durch, was ich eigentlich
nicht wollte. Ich glaube, wenn ich in meiner
Plattform solche Möglichkeiten habe, um zum Beispiel ein
Management Team als required approver irgendwo einzusetzen,
dann kann ich das auch ganz klar kommunizieren.
Dann weiß ich okay wenn jetzt in dieser Freeze Zeit ein
Deployment durchgeführt werden muss, dann weiß ich an wen ich
mich da wenden muss um das entsprechend zu erlauben.
Das zeigt aber auch schon wieder ne.
Meistens betrifft das eben nicht nur ein Repository, sondern ganz
ganz viele verschiedene Umgebungen, die oft ja auch in
verschiedenen Repositories oder verschiedene Teile
Infrastructure Code und der Code selber und noch vielleicht
helmcharts oder was auch immer da an verschiedenen Repos liegt.
Das heißt, eigentlich muss ich mir vor so einem Freeze auch so
ein Assessment machen. Das heißt, ich muss mal gucken,
gut, wie breit geht denn dieser Freeze, wie ist denn auch
irgendwie eine Risikobewertung, welche Systeme will ich denn
jetzt schützen, welche sind besonders kritisch, welche
Repositories zahlen darauf ein, sind überhaupt betroffen, habe
ich da versteckte Risiken, irgendwo DNS, externe Provider,
vielleicht irgendwelche SARS tools die ich verwende, also
muss ich natürlich auch irgendwie gucken, dass wenn ich
jetzt oz Zero für mein Login verwende, auch da keiner
irgendwelche Änderungen macht, wie wird sich denn da
eingeloggt, ist das über Single Sign on?
Soll ich dann dieses ein? Einloggen in der Zeit verhindern
oder wie mache ich das? Da sind ja ganz, ganz viele
Fragestellungen, es kann ja sein, dass wie gesagt, dass dass
es ja auch irgendwelche Skripte gibt, die auf einmal über Nacht
laufen, irgendwie irgendwelche Nightly Builds bauen oder sowas,
was ist denn damit? Also ich glaube da muss man sich
schon vorher hinsetzen und das und so einen Freeze auch
anständig planen, indem man eben wie gesagt so eine
Risikobewertung macht. Den Blast Radius definiert und
wirklich genau schaut. Was sind denn alle Systeme die
jetzt davon betroffen wären, wenn wir alles einfrieren
müssten und wie stellen wir in diesen einzelnen Systemen auch
sicher, dass man da wirklich keinen Zugriff hat?
Und so einen Freeze natürlich auch testen.
Also ich muss natürlich auch testen, ob ich dann wirklich
dieser Blog ausgelöst wird und dass ich jetzt vielleicht mal so
ein Test Deployment in eine unkritische Umgebung oder zu
einer Zeit, wo ich eigentlich keinen Freeze habe, mal teste
und gucke, ob ich wirklich nicht deployen und wirklich keine
Änderung machen kann für die Leute, wo das irgendwie wichtig
ist. Ja, und zuletzt, und das hat man
gerade schon erwähnt, ist natürlich wichtig.
Zu wissen, was der Notfallhammer in dem Sinne ist, also wie wir
quasi durchkommen, wenn es im absoluten Notfall auch möglich
sein muss. Und dementsprechend sollte man
sowas auch nicht überstürzen und dann einfach irgendwie alles
entsprechend absperren und dann geht die einzige Person oder die
Gruppe von Leuten geht dann erstmal irgendwie übers
Wochenende raus oder in den Urlaub und am Ende kann niemand
diese Sperren wieder rausnehmen und ich muss aber irgendwie
einen kritischen. Edge entsprechend releasen und
dann stehe ich halt entsprechend da und muss die Leute irgendwie
aus dem Urlaub anrufen, damit die zurückkommen und die
Konfiguration ändern. Das heißt, ich muss auf der
einen Seite sichergehen, dass diese Limitierungen, die ich
brauche, funktionieren, aber gleichzeitig muss ich
sichergehen, dass ich auch einen Weg habe, im Notfall da
durchzukommen, dass ganz klar der Prozess definiert ist, das.
Also wie mache ich das technisch und welche Menschen müssen auch
involviert sein? Das kann zum Beispiel ein
Reliability Engineer Plus halt Management sein oder Management
plus plus Product Manager, also in welcher Konstellation erlaube
ich dennoch so ein Release oder so ein?
Deployment während dieser Deployment Freeze Zeit und das
muss natürlich ganz klar dokumentiert sein, man muss
jederzeit nachschauen können, hey, wenn ich was Kritisches
habe, mit wem muss ich sprechen und wie komme ich jetzt
entsprechend auch zu einem Punkt, dass das Ganze in
Produktion gebracht werden kann. Genau, vor allem mit wem muss
ich sprechen? Es muss so eine manuelle
Approval Kette quasi geben, ich kann ja nicht sagen, also ich
will ja eigentlich vermeiden, dass jemand glaubt, dass sein
Fotfix jetzt ganz ganz wichtig ist und dann aus Versehen
irgendwas verschlimmbessert sogar noch, sondern ich glaube,
dass das ist dann wirklich was, wo wichtig ist das.
Da wird nichts alleine gemacht in dieser Zeit, da muss es immer
mindestens ein 4 Augen Prinzip geben.
Es muss eine klare Approval Kette geben, ich muss über sowas
wie conditional access mir dann extra Zugang besorgen, der auch
zeitlich limitiert ist, den ich begründen muss den ich approved
bekommen muss und sowas und das muss natürlich auch klar
definiert sein und sowas ist natürlich wirklich auch nur für
echte echte echte Incidence, das ist jetzt kein Shortcut für Ah,
mein Feature muss da doch noch irgendwie rein und eigentlich ah
wir sind doch nicht fertig geworden, der CEO wollte das
aber morgen auf der Bühne präsentieren, da braucht man.
Auch eine Entscheidung für dann im schlimmsten Fall wird dieses
Feature dann eben nicht auf der Bühne präsentiert, weil die
Gefahr ja besteht, dass du das jetzt über diesen Shortcut da
noch reinziehst und dann aber was einrichtest, was einen viel
viel größeren Schaden anrichtet und da wird gar nichts mehr
präsentiert und genau deswegen macht man ja diese Freezes.
Also ich glaube, da muss man sich dann auch schon ganz klar
dran halten. Wenn wir jetzt den Freeze
eingerichtet haben und durch unsere Code Freeze oder
Deployment Side durch sind. Dann müssen wir das Ganze
natürlich auch wieder zurückbauen, auflösen und da
haben wir auf der einen Seite auch der technischen aus der
technischen Perspektive unsere Skripts, die Skripte, die wir
ausführen. Wir müssen die entsprechenden
Policies wieder deaktivieren und auch dafür brauche ich natürlich
eine Checkliste, damit ich nichts vergesse, damit ich nicht
auch in Situationen lande, dass ich vielleicht an einer Stelle
immer noch die Blocker drin habe und die Person, die das dann
freigeben muss, gerade nicht verfügbar ist.
Wenn ich an dem nächsten Feature.
Verarbeite und. Natürlich auch, genauso wie
klare Kommunikation wichtig ist, wenn der Freeze eingeführt ist,
vielleicht auch einfach noch mal eine E Mail an alle schreiben.
Ey, der Freeze ist jetzt aufgehoben, hier sind die ersten
Schritte für diesen Re rampup und vielleicht auch wenn wir
sagen okay wir fahren das jetzt wieder so ein bisschen softer
an, also kleine ungefährliche Änderungen zuerst und das
Monitoring wieder eng im Blick haben.
Eigentlich sollte da gar nicht so wahnsinnig viel passieren,
weil wir haben ja nichts geändert, wir haben ja einfach
nur nicht irgendwas gemacht, eigentlich haben wir nur nichts
gemacht. Glaube ich trotzdem.
Wichtig, dass alle, dass alle abgeholt sind, wieder am Boot
sind. So, jetzt geht es wieder ganz
normal weiter, die Leute, die vielleicht auch extra irgendwie
on Call waren oder extra bereit standen, können wir wieder
normal weiterarbeiten. Also ich würde auch immer das
Aufheben des Freezes genauso kommunizieren wie das Einführen.
Das heißt, wir können das Ganze so ein bisschen zusammenfassen
unter dem unter dem Saat. Hey, wir wollen eigentlich nicht
den Code Freeze, sondern wir wollen Deployment Freeze,
zumindest solange wir uns in der saas Welt bewegen und.
Und wir wollen auch an der Stelle sicherstellen, dass
nichts kaputt geht, aber gleichzeitig wir die Möglichkeit
haben, falls es Probleme gibt, diese Probleme auch wirklich
zeitnah zu beheben. Ja, für so einen Freeze spricht
da natürlich eigentlich, dass es, wenn ich wirklich ein
Revenue Risiko zu einer gewissen Zeit habe oder irgendwelche
Demos oder irgendwelche Krisen im Unternehmen, dass ich dann
halt wirklich sagen kann, ey, ich muss in der Lage sein, das
einzufrieren. Ich glaube, das braucht auch gar
nicht jedes Unternehmen, sondern eben, wenn man genau.
Genau diese Dinge, die wir besprochen haben, wenn man da
sich eigentlich ganz, ganz sicher sein muss gegen so einen
Freeze, spricht aber eigentlich, dass wir ja damit nur dass
Symptome kämpfen und nicht die Ursache.
Das sollte eigentlich kein Ersatz sein für gute cicd
Prozesse, denn eigentlich sollten wir so testen und in
Stages deployen und so weiter, dass sowas gar nicht passieren
kann, dass wir in so eine Situation geraten, wo wir diesen
Freeze einführen müssen. Bei Code gehe ich da aber
vielleicht noch mit bei so kritischen Infrastruktur Changes
oder auf irgendwie in. Jetzt auf die Idee zu kommen,
den Club Anbieter zu wechseln oder sowas da aber nicht.
Also das muss man natürlich schon irgendwie in die richtige
Phase einplanen und auch hier noch mal der Vermerk, wenn man
selber so ein bisschen das Gefühl hat, ja da könnten wir
bestimmt was machen, wir sind nicht perfekt in unseren
Prozessen, dann ist es auf jeden Fall sinnvoll auch in einem
bestimmten Kontext das einfach als strategisches Werkzeug zu
verwenden und zu sagen, Hey. Ja, eigentlich sollte man das
nicht brauchen in der perfekten Welt.
Wir haben hier aber keine perfekte Welt, deswegen gehen
wir jetzt wirklich durch und kommunizieren diesen diesen
Freeze und exerzieren den auch durch und heben den dann auch
wieder auf. Uns würde interessieren, ob ihr
Deployment Freezes macht. Bei euch im Unternehmen.
Also schreibt uns gerne eine E Mail oder auf Spotify oder
youtube könnt ihr natürlich auch Kommentare hinterlassen, wir
finden das extrem spannend, einfach auch eure Perspektive
dazu bekommen und für diejenigen, die es noch nicht
machen, haben wir eine kleine Checkliste zusammengestellt, die
würden wir jetzt einfach mal mit euch durchgehen damit wenn ihr
Deployment Freezes einführen wollt, auch direkt wisst welche
5 Schritte ihr dafür durchlaufen müsst.
Genau diese Liste packen wir auch noch mal in die Show Notes.
Das heißt, ihr findet unter der Folge das auch noch mal, wenn
ihr das in eure eigenen Notizen kopieren oder weiterschicken
wollt, so quasi als Zusammenfassung und sie fängt an
mit dem ersten Punkt, oder das ist das Festlegen vom Scope.
Also erstmal muss man überhaupt definieren.
Was wird denn hier überhaupt eingefroren und wovon reden wir?
Reden wir wirklich von einem Code Freeze, wenn wir Code
Freeze sagen oder meinen wir eigentlich Deployment Freezezes
und bezieht sich auch auf die CONFIG oder auf DNS Server?
Und was ist eigentlich der Zeitraum, in dem wir das ganze
Freezen wollen? Als zweites schauen wir auf die
Risiken. Das heißt, wir gehen diese
kritischen Systeme und entsprechende Stellen durch.
Es kann unsere prot Umgebung sein, wie du gerade gesagt
hattest. Dns Payment Authorization.
Systeme, die bei einem Ausfall dazu führen können, dass unsere
ganze Lösung nicht mehr richtig funktioniert.
Das heißt, diese Stellen identifizieren wir und wissen
dementsprechend auch, worauf wir achten müssten.
Dann dritter Schritt kommunizieren, das ganze Team
informieren, wirklich jeden, der betroffen ist, was ist wann ist
Start, wann ist Ende, was ist erlaubt, was ist verboten, wer
entscheidet, wer macht welche Freigaben und wie sieht der
Eskalationspfad aus? Gehen erst dann gehen wir hin
und nehmen die technischen Maßnahmen vor.
Wir gehen hin und konfigurieren Branch Protection Rules, Wir
rekonfigurieren unsere Deployment Rechte, schränken
diese entsprechend ein und machen vielleicht einen Freeze
Check in unserer cicd Pipeline, also genau diese Dinge die wir
vorhin besprochen haben, werden an dieser Stelle technisch
umgesetzt, um sicherzugehen, dass einfach nichts schiefgehen
kann. Und als letztes auch natürlich
den Notfall und das Ende planen. Ich fand diesen Begriff von
diesem Notfallhammer so schön. Wie sieht er aus?
Das müssen wir einmal definieren, was ist da genau der
Pfad, dass dann doch vielleicht irgendjemand was freigeben kann,
das wird einmal festgehalten, und natürlich brauchen wir auch
ein klares Vorgehen zum Auflösen des Freezes, also wenn der
wieder vorbei ist. Das muss einmal geplant werden
und natürlich auch entsprechend technisch eingerichtet werden
und natürlich auch kommuniziert werden.
Und jetzt haben wir tatsächlich alles an der Hand, was wir
brauchen, um so einen. Code Freeze oder Deployment
Freeze auch in unserer Software oder unserem Unternehmen
vorzubereiten, ob wir es brauchen.
Wir haben ja vorhin darüber diskutiert, wann braucht man es
und braucht man es überhaupt, aber ich denke mal es ist ein.
Gutes Werkzeug, einfach das mal bei der Hand zu haben, um halt,
wenn diese Diskussion mal aufkommt, das Ganze wirklich
strukturiert beleuchten zu können und da auch keine
überstürzten Entscheidungen zu treffen.
Wenn euch die Folge gefallen hat, dann lasst uns gerne eine
gute Bewertung da. Wir freuen uns auch immer sehr,
wenn ihr uns einen Kaffee ausgebt.
Ihr könnt auch gerne zu eurem eigenen Kaffee die passende Nerd
Tasse haben oder wir haben so einen.
Bei mir Coffee Link, wo ihr uns einen Kaffee spendieren könnt,
da freuen wir uns immer sehr. Schaut da gerne in den Links
vorbei, die ihr auch in den Shownotes findet.
Und vielleicht noch für diejenigen, die bis zum Ende
zugehört haben. Die Frage habt ihr gemerkt, was
wir an unserem technischen Setup geändert haben?
Wenn ja, schreibt uns gerne in die Kommentare, uns würde
interessieren, ob es tatsächlich eine Verbesserung ist oder ob es
so ist wie immer. Ansonsten hört auch gerne
nächste Woche wieder rein. Der To do Kreis erscheint jeden
Montag immer abwechselnd in einer Themenfolge wie dieser
hier oder einer News Folge, wo wir dann die News der letzten 2
Wochen von der Developer Welt so ein bisschen zusammenfassen.
Seid also auch nächsten Montag wieder mit dabei und bis dahin
habt eine gute Woche, schreibt viel Code, friert ihn nicht so
oft ein sondern eher das Deployment und habt eine gute
Zeit. Bis dahin.