In der Peak Season, was den Traffic angeht, wird häufig das Thema „Code Freeze“ angesprochen, um den außergewöhnlich hohen Traffic in dieser Zeit zu bewältigen.
Code Freezes mögen heutzutage wie ein veraltetes Konzept erscheinen, ein Überbleibsel aus der Zeit, als starre Wasserfallmodelle die einzige Option für die Produktentwicklung und Releases waren.
Das ganze Konzept, die Produktion zu stoppen und Releases zu verzögern, nur um Bugs und andere funktionale Probleme zu testen, hat keinen Platz mehr im modernen agilen Produktmanagement und in DevOps-Praktiken, bei denen der Code in jeder Phase des Entwicklungsprozesses getestet und überprüft wird.
Zumindest scheint dies der allgemeine Konsens in vielen technischen Teams zu sein.
Aber ist das wirklich so? Wenn man erstmal an der Oberfläche der häufigsten Argumente gegen die Integration von Code Freezes in das agile Produktmanagement kratzt, erscheinen sie dann immer noch veraltet?
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äufe deines Unternehmens integrieren solltest oder nicht.
Was ist ein Code Freeze?
Beginnen wir zunächst damit, was ein Code Freeze eigentlich ist, um zu verstehen, ob es in der modernen Softwareentwicklung noch einen Platz hat.
Ein Code Freeze ist eine traditionelle Praxis unter Entwicklern, die Änderungen oder die Veröffentlichung neuen Codes zu stoppen, um die Stabilität der Website oder App während eines bestimmten Zeitraums zu gewährleisten. Ein Code Freeze wird in der Regel in Zeiten implementiert, in denen ein höherer Traffic als normal erwartet wird, insbesondere bei E-Commerce-Websites in der Peak Season.
Was bedeutet das? In traffic-starken Zeiten im E-Commerce unterlässt du vorübergehend sämtliche Änderungen an der Website. Jegliche Änderungen mit Auswirkung auf die User Experience während der Peak Season können letztlich zu einem Verlust an Conversions und Gewinn führen.
Mit anderen Worten: Ein Code Freeze wird durchgeführt, um sich vor möglichen Fehlern zu schützen, die durch die zusätzliche Belastung der Website entstehen.
Betrachten wir ein praktisches Beispiel: Die Entwickler beschließen, eine neue Code-Änderung während des „Black Friday“ einzuführen, 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ährend die Entwickler versuchen, das Problem zu beheben, kommt es zu Ausfallzeiten auf der Website, was zu Umsatzeinbußen führen kann, da die Kunden ihre Einkäufe nicht abschließen können.
Um dieses Worst-Case-Szenario zu vermeiden, verhängen die Entwickler stattdessen eine Code-Freeze-Zeit, in der keine weiteren Code-Änderungen vorgenommen werden. Auf diese Weise wird sichergestellt, dass eine Website bis zum Ende der Zeit mit hohem Traffic-Aufkommen ohne Probleme funktioniert.
Was beinhaltet eine agile Methodik?
Im Folgenden werden wir die Idee hinter dem agilen Konzept erörtern, um besser beurteilen zu können, ob es mit Code Freezes vereinbar ist, bevor wir die häufigsten Argumente gegen diese Methode untersuchen.
Die agile Methodik zielt darauf ab, Projekte in regelmäßig wiederkehrende Zyklen, sogenannte Sprints, aufzuteilen, und wird weitgehend durch das Feedback der Kunden bestimmt. Dies hilft den Teams, den Verbrauchern schnell einen größeren Wert zu liefern.
Mit anderen Worten: Diese Methodik fördert die kontinuierliche Iteration und Verbesserung von Produkten und Tests während des gesamten Software Development Life Cycles.
Durch die Aufteilung der Entwicklung in Sprints wird die Zykluszeit verkürzt, was die Markteinführung beschleunigt und es den Teams ermöglicht, schneller auf Marktanforderungen zu reagieren.
Vor diesem Hintergrund kann ein Code Freeze die Fähigkeit von Teams, schnell einen Mehrwert zu liefern, potenziell einschränken, da sie eine Freeze-Phase festlegen.
Als Nächstes werden wir uns einige der gängigen Argumente gegen Code Freezes im Kontext einer agilen Methodik ansehen.
Argument 1: Code Freezes sind irrelevant und unnötig
Dieses Argument ist ziemlich simpel und konkret – aufgrund moderner Agile Methodiken und Tools sind spezielle QAs und Testzeitfenster nicht mehr notwendig.
Agile Methoden wie Peer Code Reviews, Pair Programming und die ständige Überwachung des Systemzustands geben dir einen viel besseren Einblick in die Leistung einer Anwendung oder eines Features, während diese entwickelt werden. Fehler und Probleme lassen sich leichter und mit größerer Wahrscheinlichkeit bereits während der Entwicklung erkennen und beheben, bevor spezielle Tests und QA-Aktivitäten durchgeführt werden.
Je ausgefeilter dein agiler Ansatz ist, desto mehr wirst du versuchen, dieses Zeitfenster zu verkleinern. Die derzeit raffiniertesten Agile-Ansätze sind Continuous Integration und Continuous Deployment (CI/CD).
Diese Prozesse zielen darauf ab, die Entwicklung in kleine, inkrementelle Änderungen aufzuteilen, um Änderungen am Code so schnell wie möglich „freizugeben“. 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.
Neue Tools haben auch viele Tests automatisiert. Sie evaluieren permanent den Code, um sicherzustellen, dass er fehlerfrei und jederzeit produktionsfähig ist. Probleme werden in Echtzeit erkannt, und es werden sofort Warnmeldungen zu ihrer Behebung verschickt, so dass weniger manuelle Tests durchgeführt werden müssen.
Das Ergebnis dieser neuen agilen Methoden und Tools liegt klar auf der Hand. Die meisten der wichtigsten Test- und QA-Aktivitäten, die während eines Code Freeze durchgeführt werden, werden entweder während der Entwicklung oder von einer Software durchgeführt.
Bei Agile verlassen Software und Funktionen die Entwicklung jetzt mit einem deutlich höheren Maß an Vertrauen als zuvor, wodurch ein dedizierter Code Freeze immer schwerer zu rechtfertigen ist.
Argument 2: Code-Freezes brechen ein zentrales agiles Prinzip
Das zweite Argument ist ein wenig übergeordneter Natur. Es besagt, dass Code Freezes in der agilen Methodik nichts zu suchen haben, weil sie gegen eines der Grundprinzipien dieser Methodik verstoßen – die Verkürzung der Zeit zwischen Entwicklung und Release.
Im Gegensatz dazu musst du getrennte Entwicklungs- und Release-Phasen beibehalten, wenn du Code Freezes einsetzen willst. Schließlich befindet sich der Code Freeze genau zwischen diesen beiden Phasen.
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äne für Entwicklung und Release „drum herum“ erstellen musst.
Wenn Code Freezes nicht mit den Grundprinzipien der agilen Methodik übereinstimmen, dann ist es schwer zu argumentieren, sich methodisch weiter an sie zu halten.
Argument 3: Code Freezes führen zu langsameren Releases minderer Qualität
Dieses letzte Argument ist wichtig und sollte unter verschiedenen Blickwinkeln betrachtet werden.
Erstens wird behauptet, dass Code Freezes die Roadmap komplexer machen und die Wahrscheinlichkeit erhöhen, dass etwas schief geht und der Zeitplan durcheinander gerät.
Selbst wenn nichts schief geht, ist die Arbeit, die mit Code Freezes verbunden ist, zeitintensiv und unvorhersehbar (da man nicht weiß, welche Bugs man finden wird und wie lange es dauern wird, sie zu beheben), so dass die bloße Aufnahme von Code Freezes in die Roadmap zu langsameren Entwicklungs- und Release-Zyklen führt.
Einerseits werden die Entwickler während eines Code Freeze weiterhin Code entwickeln, ohne ihn jedoch zu integrieren oder zu testen, während sie darauf warten, dass der Freeze vorbei ist. Dies führt zu einer Anhäufung von Code und damit zu größeren Risiken und Instabilitäten, was die Dynamik deiner CI/CD-Prozesse erheblich verlangsamen könnte.
Andererseits möchten die Entwickler vielleicht neue Code-Änderungen herausbringen, bevor der Code Freeze beginnt. Dies kann zu unvollständigem oder schlecht geschriebenem Code führen, der aus Zeitgründen nicht den üblichen gründlichen Tests unterzogen wird, da sie sich beeilen, ihre Projekte vor dem Code Freeze abzuschließen. Das Ergebnis ist eine minderwertige, weniger umfangreiche Software und Anwendung.
Außerdem können Code Freezes die Produktivität deines Entwicklungsteams reduzieren. Während agile Methodiken im Allgemeinen und CI/CD im Besonderen dafür sorgen, dass die Entwickler permanent in einer ungebrochenen Produktionskette arbeiten, zwingen Code Freezes deine Entwickler dazu, die Arbeit in vordefinierten Abständen zu unterbrechen.
Mit anderen Worten: Es könnte deine CI/CD-Pipeline unterbrechen.
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ößte Produktivität verspricht.
Sich für Code Freezes einsetzen: Ein aussichtsloser Kampf?
An dieser Stelle sieht es für jeden düster aus, der Code Freezes immer noch in die agile Methodik integrieren möchte. Es gibt einige sehr überzeugende Argumente und ein insgesamt solides Argument dafür, dass Code Freezes seit der Entwicklung der modernen agilen Methodik zu etwas anderem geworden sind:
- Obsolet und irrelevant
- Nicht mit modernen Entwicklungspraktiken übereinstimmend
- Ein Hindernis für schnelle, qualitativ hochwertige Releases
Diese Argumente sind zwar überzeugend und enthalten viele zutreffende Informationen, aber sie sind nicht unerschütterlich. Und jedes dieser Argumente weist grundlegende Mängel auf, die diskutiert werden müssen, ehe das Kapitel über Code Freezes als nützliche Komponente des agilen Produktmanagements geschlossen werden kann.
Das Problem mit Argument 1: Automatisierte Tests sind nicht umfassend
Automatisierte QA und agile Entwicklungspraktiken haben die Qualität des Quellcodes verbessert, das ist eine Tatsache. Doch nur weil ein Stück Code die Unit-Tests bestanden hat, heißt das noch lange nicht, dass es tatsächlich produktionsreif ist.
Selbst die ausgefeiltesten CI/CD-Ansätze 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ährend ein Code-Teil in Produktion ist.
Wenn du dich für die Verwendung von Code Freezes entscheidest, musst du nicht auf die Vorteile der automatisierten QA und der bewährten agilen Verfahren verzichten.
Du und dein Team werden während der Produktion einfach die kleineren, trivialeren Probleme des Codes erkennen, um die Lage zu sondieren und sich auf größere Probleme mit größeren Auswirkungen während des Freeze zu konzentrieren wie zum Beispiel die Gesamtstabilität und -zuverlässigkeit der neuen Software oder Funktion.
Das Problem mit Argument 2: „Reduzieren“, nicht „eliminieren“
Agile ist zwar darauf ausgelegt, die Zeit zwischen Entwicklung und Release zu verkürzen, aber es besteht ein großer Unterschied zwischen dem Versuch, dieses Zeitfenster zu verkürzen, und dem Versuch, es vollständig zu eliminieren. Dies wäre vor allem bei größeren Projekten nahezu unmöglich.
Der Code Freeze kann bei CI/CD sehr kurz sein – oder nur für eine bestimmte Branche gelten, während die Entwicklung in anderen Branchen fortgeführt wird -, aber es existiert trotzdem.
Unabhängig davon, wie ausgefeilt Agile geworden ist, wird es fast immer einen Punkt in allen Roadmaps für 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.
Das Problem mit Argument 3: Geschwindigkeit und Qualität überdenken
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ügst, verlangsamst du diesen Prozess und schaffst eine neue potenzielle Schwachstelle. Code Freezes sind da keine Ausnahme.
Aber es ist wichtig, einen Schritt zurückzutreten und diese „Verlangsamung“ und den Produktivitätsverlust aus einem breiteren Blickwinkel zu betrachten.
Wenn deine Funktion Fehler aufweist, musst du diese beheben, unabhängig davon, ob du diese Fehler während eines Code Freeze entdeckt hast oder ob sie erst nach dem Release bekannt wurden. Aus der reinen Entwicklungsperspektive betrachtet, ist der Zeitaufwand für die Fehlerbehebung in beiden Szenarien in etwa gleich.
Wenn du jedoch mit Fehlern in einer Live-Umgebung zu tun hast, musst du dich für eine ganze Reihe anderer Probleme Zeit nehmen, darunter:
- Die Entscheidung, ob du die fehlerhafte Funktion zurücknimmst oder sie in Betrieb lassen sollst.
- Deine Entwickler von ihren neuen Projekten abziehen, nachdem sie mit der Arbeit begonnen haben.
- Die Wiedergutmachung gegenüber den Nutzern, die von den Fehlern betroffen waren.
- Die Beantwortung von Fragen und der Umgang mit internen Stakeholdern, die über die fehlerhafte Version nicht sehr glücklich sind.
Die Liste ließe sich weiter fortsetzen. Es gibt nichts Komplizierteres, Zeitaufwändigeres und Produktivitätsschädigenderes – für dich und dein Team – als die Veröffentlichung eines fehlerhaften Features oder Produkts. Code Freezes minimieren die Wahrscheinlichkeit, dass dies geschieht.
Und was das Argument angeht, dass Code Freezes zu qualitativ minderwertigen Funktionen und Produkten führen, weil sie die Menge der Geschäftsanforderungen reduzieren, die du sammeln kannst?
Deine geschäftlichen Anforderungen werden immer nur eine „beste Spekulation“ darüber sein, wie dein Produkt oder dein Feature funktionieren sollte. Die wertvollsten Ansprüche werden immer von Usern in der realen Welt gestellt, wenn dein Produkt oder dein Feature in echten Szenarien eingesetzt wird.
Wie Feature Flags Code Freezes ersetzen können
Wie wir bereits erwähnt haben, wird ein Code Freeze als Präventivmaßnahme gegen riskante und/oder fehlerhafte neue Code-Änderungen in sensiblen Phasen durchgeführt.
Ein Code Freeze könnte jedoch das Risiko sogar erhöhen. Da die Entwickler weiterhin an neuen Änderungen arbeiten, die während des Code-Freeze-Zeitraums nicht freigegeben werden, bedeutet dies, dass sich in der nächsten Version eine Reihe von Commits ansammeln wird, was diese Version unglaublich riskant macht.
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.
An dieser Stelle kommen Feature Flags ins Spiel. Durch die Verwendung von Feature Flags sind die Entwickler nicht mehr auf Code Freezes während Zeiten mit hohem Traffic angewiesen, um das Risiko von Code-Änderungen zu verringern.
Durch die Entkopplung von Bereitstellung und Release ermöglichen es Feature Flags den Entwicklern, eine neue Funktion oder eine Code-Änderung in die Produktion zu überführen und sie für die Benutzer unsichtbar zu machen, um sie dann nach und nach für bestimmte Benutzergruppen freizugeben – zum Beispiel intern in deinem Unternehmen.
Auf diese Weise können 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önnen. Teams können eine fehlerhafte Änderung auch jederzeit mit einem Kill Switch ausschalten oder zurücknehmen, so dass die Benutzer während der Korrektur keinen Zugriff mehr darauf haben.
Zusammenfassend lässt sich sagen, dass Feature Flags den Teams mehr Kontrolle über 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.
Ist es an der Zeit, den Code Freeze abzuschaffen?
Letztendlich spielen Code Freezes immer noch eine wichtige Rolle, um Ausfallzeiten oder unerwartete Fehler in besonders geschäftigen Zeiten zu vermeiden.
Da jede E-Commerce-Website anders ist, musst du entscheiden, ob ein Code Freeze die richtige Wahl für deine Website ist. Wenn du dich für einen Code Freeze entscheidest, solltest du gemeinsam mit deinem Entwicklungsteam im Voraus einen detaillierten Plan aufstellen.
So kannst du feststellen, welcher Code „eingefroren“ werden muss, welcher optimiert werden muss und welche Projekte auf Eis gelegt werden sollten, um „unsaubere“ Releases zu vermeiden, bevor du mit dem Freeze beginnst.
Es gibt Fälle, in denen sie eine weniger kritische Rolle spielen. Bei sehr kleinen Projekten sind beispielsweise keine speziellen Code-Freeze-Zeiten erforderlich.
Bei neuen Features, die relativ geringe Auswirkungen haben, lohnt sich vermutlich kein Freeze. Dasselbe gilt für Release-Pläne, die schrittweise erfolgen, wenn du neue Features nur mit einer warmen Zielgruppe testen willst, die du darauf vorbereitet hast, ein fehlerhaftes, nicht perfektes Szenario zu erwarten; in diesem Fall sind Feature Flags ein effizienter Weg, diese Funktionen schrittweise einzuführen.
Aber in den meisten Fällen lohnt sich der Zeitaufwand – auch wenn er noch so klein ist – um sicherzustellen, dass deine neuen Funktionen so perfekt sind, wie du es dir vorstellst, bevor du sie in die Hände der Menschen gibst, die am wichtigsten sind: Deine User in der realen Welt.
An dieser Stelle werden Feature Flags zu deinen größten Verbündeten, da sie es dir ermöglichen, ein optimales Kundenerlebnis zu bieten, ohne deine Implementierungen unterbrechen zu müssen.
Denke jedoch daran, dass Feature Flags ein großartiges Hilfsmittel sind, welches das ganze Jahr über und nicht nur in Zeiten hohen Traffics eingesetzt werden sollte, um das Risiko zu minimieren und die Qualität zu maximieren.
