In der Peak Season, was den Traffic angeht, wird h\u00e4ufig das Thema \u201eCode Freeze\u201c angesprochen, um den au\u00dfergew\u00f6hnlich hohen Traffic in dieser Zeit zu bew\u00e4ltigen.<\/p>\n\n\n\n
Code Freezes m\u00f6gen heutzutage wie ein veraltetes Konzept erscheinen, ein \u00dcberbleibsel aus der Zeit, als starre Wasserfallmodelle die einzige Option f\u00fcr die Produktentwicklung und Releases waren.<\/p>\n\n\n\n
Das ganze Konzept, die Produktion zu stoppen und Releases zu verz\u00f6gern, nur um Bugs und andere funktionale Probleme zu testen, hat keinen Platz mehr im modernen agilen Produktmanagement und in DevOps<\/a><\/strong>-Praktiken, bei denen der Code in jeder Phase des Entwicklungsprozesses getestet und \u00fcberpr\u00fcft wird.<\/p>\n\n\n\n Zumindest scheint dies der allgemeine Konsens in vielen technischen Teams zu sein.<\/p>\n\n\n\n Aber ist das wirklich so? Wenn man erstmal an der Oberfl\u00e4che der h\u00e4ufigsten Argumente gegen die Integration von Code Freezes in das agile Produktmanagement kratzt, erscheinen sie dann immer noch veraltet?<\/p>\n\n\n\n In diesem Artikel gehen wir auf die drei Hauptargumente ein, die gegen die Integration von Code Freezes in dein agiles Produktmanagement sprechen, und wir zeigen auf, wo diese Argumente nicht zutreffen, um dir zu helfen, eine bessere Entscheidung zu treffen, ob du Code Freezes in die Arbeitsabl\u00e4ufe deines Unternehmens integrieren solltest oder nicht.<\/p>\n\n\n\n Beginnen wir zun\u00e4chst damit, was ein Code Freeze eigentlich ist, um zu verstehen, ob es in der modernen Softwareentwicklung noch einen Platz hat.<\/p>\n\n\n\n Ein Code Freeze ist eine traditionelle Praxis unter Entwicklern, die \u00c4nderungen oder die Ver\u00f6ffentlichung neuen Codes zu stoppen, um die Stabilit\u00e4t der Website oder App w\u00e4hrend eines bestimmten Zeitraums zu gew\u00e4hrleisten<\/strong>. Ein Code Freeze wird in der Regel in Zeiten implementiert, in denen ein h\u00f6herer Traffic als normal erwartet wird, insbesondere bei E-Commerce-Websites in der Peak Season.<\/p>\n\n\n\n Was bedeutet das? In traffic-starken Zeiten im E-Commerce unterl\u00e4sst du vor\u00fcbergehend s\u00e4mtliche \u00c4nderungen an der Website. Jegliche \u00c4nderungen mit Auswirkung auf die User Experience w\u00e4hrend der Peak Season k\u00f6nnen letztlich zu einem Verlust an Conversions und Gewinn f\u00fchren.<\/p>\n\n\n\n Mit anderen Worten: Ein Code Freeze wird durchgef\u00fchrt, um sich vor m\u00f6glichen Fehlern zu sch\u00fctzen, die durch die zus\u00e4tzliche Belastung der Website entstehen<\/strong>.<\/p>\n\n\n\n Betrachten wir ein praktisches Beispiel: Die Entwickler beschlie\u00dfen, eine neue Code-\u00c4nderung w\u00e4hrend des \u201eBlack Friday\u201c einzuf\u00fchren, an dem der Traffic besonders hoch ist, da die Kunden auf der Suche nach den besten Angeboten sind. Es stellt sich jedoch heraus, dass es einen Fehler gibt, mit dem sie nicht gerechnet hatten. W\u00e4hrend die Entwickler versuchen, das Problem zu beheben, kommt es zu Ausfallzeiten auf der Website, was zu Umsatzeinbu\u00dfen f\u00fchren kann, da die Kunden ihre Eink\u00e4ufe nicht abschlie\u00dfen k\u00f6nnen.<\/p>\n\n\n\n Um dieses Worst-Case-Szenario zu vermeiden, verh\u00e4ngen die Entwickler stattdessen eine Code-Freeze-Zeit, in der keine weiteren Code-\u00c4nderungen vorgenommen werden. Auf diese Weise wird sichergestellt, dass eine Website bis zum Ende der Zeit mit hohem Traffic-Aufkommen ohne Probleme funktioniert.<\/strong><\/p>\n\n\n\n Im Folgenden werden wir die Idee hinter dem agilen Konzept<\/a><\/strong> er\u00f6rtern, um besser beurteilen zu k\u00f6nnen, ob es mit Code Freezes vereinbar ist, bevor wir die h\u00e4ufigsten Argumente gegen diese Methode untersuchen.<\/p>\n\n\n\n Die agile Methodik zielt darauf ab, Projekte in regelm\u00e4\u00dfig wiederkehrende Zyklen, sogenannte Sprints, aufzuteilen, und wird weitgehend durch das Feedback der Kunden bestimmt. Dies hilft den Teams, den Verbrauchern schnell einen gr\u00f6\u00dferen Wert zu liefern.<\/p>\n\n\n\n Mit anderen Worten: Diese Methodik f\u00f6rdert die kontinuierliche Iteration und Verbesserung von Produkten und Tests<\/a><\/strong> w\u00e4hrend des gesamten Software Development Life Cycles<\/a><\/strong>.<\/p>\n\n\n\n Durch die Aufteilung der Entwicklung in Sprints wird die Zykluszeit verk\u00fcrzt, was die Markteinf\u00fchrung beschleunigt und es den Teams erm\u00f6glicht, schneller auf Marktanforderungen zu reagieren.<\/p>\n\n\n\n Vor diesem Hintergrund kann ein Code Freeze die F\u00e4higkeit von Teams, schnell einen Mehrwert zu liefern, potenziell einschr\u00e4nken, da sie eine Freeze-Phase festlegen.<\/p>\n\n\n\n Als N\u00e4chstes werden wir uns einige der g\u00e4ngigen Argumente gegen Code Freezes im Kontext einer agilen Methodik ansehen.<\/p>\n\n\n\n Dieses Argument ist ziemlich simpel und konkret – aufgrund moderner Agile Methodiken und Tools sind spezielle QAs und Testzeitfenster nicht mehr notwendig.<\/p>\n\n\n\n Agile Methoden wie Peer Code Reviews, Pair Programming und die st\u00e4ndige \u00dcberwachung des Systemzustands geben dir einen viel besseren Einblick in die Leistung einer Anwendung oder eines Features, w\u00e4hrend diese entwickelt werden. Fehler und Probleme lassen sich leichter und mit gr\u00f6\u00dferer Wahrscheinlichkeit bereits w\u00e4hrend der Entwicklung erkennen und beheben, bevor spezielle Tests und QA-Aktivit\u00e4ten durchgef\u00fchrt werden.<\/p>\n\n\n\n Je ausgefeilter dein agiler Ansatz ist, desto mehr wirst du versuchen, dieses Zeitfenster zu verkleinern. Die derzeit raffiniertesten Agile-Ans\u00e4tze sind Continuous Integration und Continuous Deployment (CI\/CD)<\/a>.<\/strong><\/p>\n\n\n\n Diese Prozesse zielen darauf ab, die Entwicklung in kleine, inkrementelle \u00c4nderungen aufzuteilen, um \u00c4nderungen am Code so schnell wie m\u00f6glich \u201efreizugeben\u201c. Bei der reinsten Anwendung von CI\/CD existieren Entwicklung und Release kaum noch als getrennte Phasen – neuer Code wird fast unmittelbar nach seiner Fertigstellung in die Anwendung integriert.<\/p>\n\n\n\n Neue Tools haben auch viele Tests automatisiert. Sie evaluieren permanent den Code, um sicherzustellen, dass er fehlerfrei und jederzeit produktionsf\u00e4hig ist. Probleme werden in Echtzeit erkannt, und es werden sofort Warnmeldungen zu ihrer Behebung verschickt, so dass weniger manuelle Tests durchgef\u00fchrt werden m\u00fcssen.<\/p>\n\n\n\n Das Ergebnis dieser neuen agilen Methoden und Tools liegt klar auf der Hand. Die meisten der wichtigsten Test- und QA-Aktivit\u00e4ten, die w\u00e4hrend eines Code Freeze durchgef\u00fchrt werden, werden entweder w\u00e4hrend der Entwicklung oder von einer Software durchgef\u00fchrt.<\/p>\n\n\n\n Bei Agile verlassen Software und Funktionen die Entwicklung jetzt mit einem deutlich h\u00f6heren Ma\u00df an Vertrauen als zuvor, wodurch ein dedizierter Code Freeze immer schwerer zu rechtfertigen ist.<\/p>\n\n\n\n Das zweite Argument ist ein wenig \u00fcbergeordneter Natur. Es besagt, dass Code Freezes in der agilen Methodik nichts zu suchen haben, weil sie gegen eines der Grundprinzipien dieser Methodik versto\u00dfen – die Verk\u00fcrzung der Zeit zwischen Entwicklung und Release.<\/p>\n\n\n\n Im Gegensatz dazu musst du getrennte Entwicklungs- und Release-Phasen beibehalten, wenn du Code Freezes einsetzen willst. Schlie\u00dflich befindet sich der Code Freeze genau zwischen diesen beiden Phasen.<\/p>\n\n\n\n Anstatt zu versuchen, das Zeitfenster zwischen Entwicklung und Release zu minimieren oder zu eliminieren, wie es bei den meisten agilen Methoden der Fall ist, zwingen Code Freezes dich dazu, dieses Zeitfenster so zu formalisieren, dass du deine Zeitpl\u00e4ne f\u00fcr Entwicklung und Release „drum herum“ erstellen musst.<\/p>\n\n\n\n Wenn Code Freezes nicht mit den Grundprinzipien der agilen Methodik \u00fcbereinstimmen, dann ist es schwer zu argumentieren, sich methodisch weiter an sie zu halten.<\/p>\n\n\n\n Dieses letzte Argument ist wichtig und sollte unter verschiedenen Blickwinkeln betrachtet werden.<\/p>\n\n\n\n Erstens wird behauptet, dass Code Freezes die Roadmap komplexer machen und die Wahrscheinlichkeit erh\u00f6hen, dass etwas schief geht und der Zeitplan durcheinander ger\u00e4t.<\/p>\n\n\n\n Selbst wenn nichts schief geht, ist die Arbeit, die mit Code Freezes verbunden ist, zeitintensiv und unvorhersehbar (da man nicht wei\u00df, welche Bugs man finden wird und wie lange es dauern wird, sie zu beheben), so dass die blo\u00dfe Aufnahme von Code Freezes in die Roadmap zu langsameren Entwicklungs- und Release-Zyklen f\u00fchrt.<\/p>\n\n\n\n Einerseits werden die Entwickler w\u00e4hrend eines Code Freeze weiterhin Code entwickeln, ohne ihn jedoch zu integrieren oder zu testen, w\u00e4hrend sie darauf warten, dass der Freeze vorbei ist. Dies f\u00fchrt zu einer Anh\u00e4ufung von Code und damit zu gr\u00f6\u00dferen Risiken und Instabilit\u00e4ten, was die Dynamik deiner CI\/CD-Prozesse erheblich verlangsamen k\u00f6nnte. <\/p>\n\n\n\n Andererseits m\u00f6chten die Entwickler vielleicht neue Code-\u00c4nderungen herausbringen, bevor der Code Freeze beginnt. Dies kann zu unvollst\u00e4ndigem oder schlecht geschriebenem Code f\u00fchren, der aus Zeitgr\u00fcnden nicht den \u00fcblichen gr\u00fcndlichen Tests unterzogen wird, da sie sich beeilen, ihre Projekte vor dem Code Freeze abzuschlie\u00dfen. Das Ergebnis ist eine minderwertige, weniger umfangreiche Software und Anwendung.<\/p>\n\n\n\n Au\u00dferdem k\u00f6nnen Code Freezes die Produktivit\u00e4t deines Entwicklungsteams reduzieren. W\u00e4hrend agile Methodiken im Allgemeinen und CI\/CD im Besonderen daf\u00fcr sorgen, dass die Entwickler permanent in einer ungebrochenen Produktionskette arbeiten, zwingen Code Freezes deine Entwickler dazu, die Arbeit in vordefinierten Abst\u00e4nden zu unterbrechen.<\/p>\n\n\n\n Mit anderen Worten: Es k\u00f6nnte deine CI\/CD-Pipeline unterbrechen.<\/strong><\/p>\n\n\n\n Dadurch unterbrichst du den Arbeitsrhythmus deines Teams und zwingst es, deine Code-Freeze-Richtlinien zu umgehen, anstatt den Arbeitsfluss zu suchen und aufrechtzuerhalten, der die gr\u00f6\u00dfte Produktivit\u00e4t verspricht.<\/p>\n\n\n\n An dieser Stelle sieht es f\u00fcr jeden d\u00fcster aus, der Code Freezes immer noch in die agile Methodik integrieren m\u00f6chte. Es gibt einige sehr \u00fcberzeugende Argumente und ein insgesamt solides Argument daf\u00fcr, dass Code Freezes seit der Entwicklung der modernen agilen Methodik zu etwas anderem geworden sind:<\/p>\n\n\n\n Diese Argumente sind zwar \u00fcberzeugend und enthalten viele zutreffende Informationen, aber sie sind nicht unersch\u00fctterlich. Und jedes dieser Argumente weist grundlegende M\u00e4ngel auf, die diskutiert werden m\u00fcssen, ehe das Kapitel \u00fcber Code Freezes als n\u00fctzliche Komponente des agilen Produktmanagements geschlossen werden kann.<\/p>\n\n\n\n Automatisierte QA und agile Entwicklungspraktiken haben die Qualit\u00e4t des Quellcodes verbessert, das ist eine Tatsache. Doch nur weil ein St\u00fcck Code die Unit-Tests bestanden hat, hei\u00dft das noch lange nicht, dass es tats\u00e4chlich produktionsreif ist<\/a>.<\/strong><\/p>\n\n\n\n Selbst die ausgefeiltesten CI\/CD-Ans\u00e4tze umfassen nicht immer entscheidende Schritte wie Regressionstests, die sicherstellen, dass ein Code-Teil fehlerfrei ist. Letzten Endes gibt es einfach einige Dinge, die man nicht testen und beheben kann, w\u00e4hrend ein Code-Teil in Produktion ist<\/a>.<\/strong><\/p>\n\n\n\n Wenn du dich f\u00fcr die Verwendung von Code Freezes entscheidest, musst du nicht auf die Vorteile der automatisierten QA und der bew\u00e4hrten agilen Verfahren verzichten.<\/p>\n\n\n\n Du und dein Team werden w\u00e4hrend der Produktion einfach die kleineren, trivialeren Probleme des Codes erkennen, um die Lage zu sondieren und sich auf gr\u00f6\u00dfere Probleme mit gr\u00f6\u00dferen Auswirkungen w\u00e4hrend des Freeze zu konzentrieren wie zum Beispiel die Gesamtstabilit\u00e4t und -zuverl\u00e4ssigkeit der neuen Software oder Funktion.<\/p>\n\n\n\n Agile ist zwar darauf ausgelegt, die Zeit zwischen Entwicklung und Release zu verk\u00fcrzen, aber es besteht ein gro\u00dfer Unterschied zwischen dem Versuch, dieses Zeitfenster zu verk\u00fcrzen, und dem Versuch, es vollst\u00e4ndig zu eliminieren. Dies w\u00e4re vor allem bei gr\u00f6\u00dferen Projekten nahezu unm\u00f6glich.<\/p>\n\n\n\n Der Code Freeze kann bei CI\/CD sehr kurz sein – oder nur f\u00fcr eine bestimmte Branche gelten, w\u00e4hrend die Entwicklung in anderen Branchen fortgef\u00fchrt wird<\/a><\/strong> -, aber es existiert trotzdem.<\/p>\n\n\n\n Unabh\u00e4ngig davon, wie ausgefeilt Agile geworden ist, wird es fast immer einen Punkt in allen Roadmaps f\u00fcr Entwicklung und Releases geben, an dem ein neues Softwareteil oder ein neues Feature in einem festen Zustand evaluiert wird, bevor es an die User in der realen Welt geht.<\/p>\n\n\n\n Wenn du Code Freezes verwendest, wird die Entwicklung und dein Release-Zyklus um einen neuen Schritt erweitert, und jedes Mal, wenn du einem Prozess einen neuen Schritt hinzuf\u00fcgst, verlangsamst du diesen Prozess und schaffst eine neue potenzielle Schwachstelle. Code Freezes sind da keine Ausnahme.<\/p>\n\n\n\n Aber es ist wichtig, einen Schritt zur\u00fcckzutreten und diese „Verlangsamung“ und den Produktivit\u00e4tsverlust aus einem breiteren Blickwinkel zu betrachten.<\/p>\n\n\n\n Wenn deine Funktion Fehler aufweist, musst du diese beheben, unabh\u00e4ngig davon, ob du diese Fehler w\u00e4hrend eines Code Freeze entdeckt hast oder ob sie erst nach dem Release bekannt wurden. Aus der reinen Entwicklungsperspektive betrachtet, ist der Zeitaufwand f\u00fcr die Fehlerbehebung in beiden Szenarien in etwa gleich.<\/p>\n\n\n\n Wenn du jedoch mit Fehlern in einer Live-Umgebung zu tun hast, musst du dich f\u00fcr eine ganze Reihe anderer Probleme Zeit nehmen, darunter:<\/p>\n\n\n\n Die Liste lie\u00dfe sich weiter fortsetzen. Es gibt nichts Komplizierteres, Zeitaufw\u00e4ndigeres und Produktivit\u00e4tssch\u00e4digenderes – f\u00fcr dich und dein Team – als die Ver\u00f6ffentlichung eines fehlerhaften Features oder Produkts. Code Freezes minimieren die Wahrscheinlichkeit, dass dies geschieht.<\/p>\n\n\n\n Und was das Argument angeht, dass Code Freezes zu qualitativ minderwertigen Funktionen und Produkten f\u00fchren, weil sie die Menge der Gesch\u00e4ftsanforderungen reduzieren, die du sammeln kannst?<\/p>\n\n\n\n Deine gesch\u00e4ftlichen Anforderungen werden immer nur eine \u201ebeste Spekulation\u201c dar\u00fcber sein, wie dein Produkt oder dein Feature funktionieren sollte. Die wertvollsten Anspr\u00fcche werden immer von Usern in der realen Welt gestellt, wenn dein Produkt oder dein Feature in echten Szenarien eingesetzt wird.<\/p>\n\n\n\n Wie wir bereits erw\u00e4hnt haben, wird ein Code Freeze als Pr\u00e4ventivma\u00dfnahme gegen riskante und\/oder fehlerhafte neue Code-\u00c4nderungen in sensiblen Phasen durchgef\u00fchrt. <\/p>\n\n\n\n Ein Code Freeze k\u00f6nnte jedoch das Risiko sogar erh\u00f6hen. Da die Entwickler weiterhin an neuen \u00c4nderungen arbeiten, die w\u00e4hrend des Code-Freeze-Zeitraums nicht freigegeben werden, bedeutet dies, dass sich in der n\u00e4chsten Version eine Reihe von Commits ansammeln wird, was diese Version unglaublich riskant macht. <\/p>\n\n\n\n Wenn irgendwelche Probleme auftauchen, wird es viel schwieriger sein, die Quelle des Problems zu lokalisieren, was bedeutet, dass mehr Zeit damit verschwendet wird, es zu finden und zu beheben.<\/p>\n\n\n\n An dieser Stelle kommen Feature Flags<\/a><\/strong> ins Spiel. Durch die Verwendung von Feature Flags sind die Entwickler nicht mehr auf Code Freezes w\u00e4hrend Zeiten mit hohem Traffic angewiesen, um das Risiko von Code-\u00c4nderungen zu verringern. <\/p>\n\n\n\n Durch die Entkopplung von Bereitstellung und Release erm\u00f6glichen es Feature Flags den Entwicklern, eine neue Funktion oder eine Code-\u00c4nderung in die Produktion zu \u00fcberf\u00fchren und sie f\u00fcr die Benutzer unsichtbar zu machen, um sie dann nach und nach f\u00fcr bestimmte Benutzergruppen freizugeben<\/strong> – zum Beispiel intern in deinem Unternehmen.<\/p>\n\n\n\n Auf diese Weise k\u00f6nnen Teams kontinuierlich neuen Code bereitstellen und an neuen Funktionen arbeiten, ohne dass die Kunden davon etwas mitbekommen, da sie hinter diesen Flags versteckt sind und jederzeit ein- oder ausgeschaltet werden k\u00f6nnen. Teams k\u00f6nnen eine fehlerhafte \u00c4nderung auch jederzeit mit einem Kill Switch<\/a><\/strong> ausschalten oder zur\u00fccknehmen, so dass die Benutzer w\u00e4hrend der Korrektur keinen Zugriff mehr darauf haben.<\/p>\n\n\n\n Zusammenfassend l\u00e4sst sich sagen, dass Feature Flags den Teams mehr Kontrolle \u00fcber den Release-Prozess geben und dazu beitragen, das Risiko der Bereitstellung in der Produktion zu verringern, insbesondere in besonders sensiblen Zeiten mit hohem Traffic, ohne die Benutzererfahrung negativ zu beeinflussen. <\/p>\n\n\n\n Letztendlich spielen Code Freezes immer noch eine wichtige Rolle, um Ausfallzeiten oder unerwartete Fehler in besonders gesch\u00e4ftigen Zeiten zu vermeiden.<\/p>\n\n\n\n Da jede E-Commerce-Website anders ist, musst du entscheiden, ob ein Code Freeze die richtige Wahl f\u00fcr deine Website ist. Wenn du dich f\u00fcr einen Code Freeze entscheidest, solltest du gemeinsam mit deinem Entwicklungsteam im Voraus einen detaillierten Plan aufstellen. <\/p>\n\n\n\nWas ist ein Code Freeze?<\/h2>\n\n\n\n
Was beinhaltet eine agile Methodik?<\/h2>\n\n\n\n
Argument 1: Code Freezes sind irrelevant und unn\u00f6tig<\/h3>\n\n\n\n
Argument 2: Code-Freezes brechen ein zentrales agiles Prinzip<\/h3>\n\n\n\n
Argument 3: Code Freezes f\u00fchren zu langsameren Releases minderer Qualit\u00e4t<\/h3>\n\n\n\n
Sich f\u00fcr Code Freezes einsetzen: Ein aussichtsloser Kampf?<\/h2>\n\n\n\n
\n
Das Problem mit Argument 1: Automatisierte Tests sind nicht umfassend<\/h3>\n\n\n\n
Das Problem mit Argument 2: \u201eReduzieren\u201c, nicht \u201eeliminieren\u201c<\/h3>\n\n\n\n
Das Problem mit Argument 3: Geschwindigkeit und Qualit\u00e4t \u00fcberdenken<\/h3>\n\n\n\n
\n
Wie Feature Flags Code Freezes ersetzen k\u00f6nnen<\/h2>\n\n\n\n
Ist es an der Zeit, den Code Freeze abzuschaffen?<\/h2>\n\n\n\n