Halten Sie Ihre Entwicklungszüge durch den Code-Freeze der Feiertage am Laufen

Da der Schwarze Freitag und der Cyber Monday nur noch etwa einen Monat entfernt sind, hat Ihr Unternehmen vielleicht schon mit dem jährlichen Bereitstellungsstopp begonnen. Der Bereitstellungsstopp ist eine gängige Strategie, um Risiken während eines bestimmten Zeitfensters zu minimieren. In der Regel wird er in der Urlaubssaison eingesetzt, um sicherzustellen, dass Sites und Dienste zu 100 % verfügbar sind, und um kritische Zwischenfälle zu vermeiden. Der Freeze hat zwar seine Vorteile, aber wie bei allem, was mit Code zu tun hat, gibt es auch Nachteile. In diesem Blog möchten wir Ihnen zeigen, wie Sie einige dieser Nachteile mit einem so genannten "weichen" Deployment Freeze abmildern können.

Ein Deployment Freeze soll sicherstellen, dass neu eingeführte Funktionen nicht zu Störungen führen, wenn:

• Ein erhöhter Netzwerkverkehr führt plötzlich zu einer Überlastung Ihrer Systeme. (Letztes Jahr verzeichnete Optimizely einen dreifachen Anstieg der Ereignisdaten und der Besucherströme von Einzelhandels-Sites.)
• Ein Fehler wird zusammen mit der neuen Funktion eingeführt und führt zu Unterbrechungen, die den Betrieb stören. (Beispiel: Als Amazon am Prime Day 2018 einen einstündigen Ausfall hatte, gingen schätzungsweise 100 Millionen Dollar an Umsatz verloren.)
• Kritische Mitarbeiter sind nicht verfügbar. Techniker gehen in den Urlaub wie alle anderen auch, und es stehen weniger Mitarbeiter zur Verfügung, um auf Notfälle zu reagieren.

Vielleicht denken Sie jetzt: Die Zeit des Bereitstellungsstopps muss die Lieblingszeit eines QA-Ingenieurs im Jahr sein. Oder?

Nicht unbedingt. Wie viele Ingenieure nur zu gut wissen, birgt die Festlegung eines willkürlichen Termins für die Codebereitstellung ein inhärentes Risiko - und kann ein System möglicherweise extrem instabil machen, sobald der Code-Stop aufgehoben wird und die Ingenieure wieder mit der Auslieferung von Code beginnen.

Es mag einfach sein, den Bereitstellungszug anzuhalten, aber ihn wieder in Gang zu bringen, bringt seine eigenen Herausforderungen mit sich.

Im Folgenden finden Sie einige der Herausforderungen und Risiken, denen sich Entwickler nach einem Entwicklungsstopp gegenübersehen:

• Erhöhte Brüchigkeit des Systems: Software wird brüchiger, wenn sich ein Rückstau von Änderungen auftürmt, ohne dass diese zusammengeführt werden. Sobald der Freeze aufgehoben wird, kann die Zusammenführung all dieser Änderungen in einem großen Deployment große Probleme und potenzielle Kollisionen verursachen.
• Verspätete Produktauslieferung: Code, der nicht vor der Deadline für den Freeze ausgeliefert wird, führt zu Verzögerungen bei den Funktionen.
• Kaputte Prozesse: Selbst wenn ein Deployment-Freeze offiziell ausgerufen wird, handelt es sich in Wirklichkeit selten um einen vollständigen Code-Freeze. Teams müssen oft für dringende Fehlerkorrekturen, Änderungen in letzter Sekunde, die geliefert werden müssen, kritische Infrastrukturwartung usw. bereitstellen. Jeder
  jedes dieser Ereignisse überbrückt den normalen Bereitstellungsprozess und verursacht ein höheres Maß an Reibung.
• Mehr Bugs: Ein willkürlicher Stichtag zwingt die Entwickler dazu, sich zu beeilen, um die Funktionen in die Produktion zu bringen, wodurch die Wahrscheinlichkeit von Fehlern steigt.

Wie können Unternehmen also während eines Deployment Freeze sowohl die Bedürfnisse des Managements als auch die der Entwickler unter einen Hut bringen?

Ein Ansatz besteht darin, ein Feature Flag-System zu verwenden, um einen sanften Deployment Freeze zu implementieren: das, was ich gerne als "Deployment Slushie" bezeichne. Die Bereitstellung von Code hinter Feature Flags ermöglicht es den Entwicklungsteams, weiterhin Code einzuchecken und in die Produktion zu überführen, während sie gleichzeitig das Risiko mindern, indem sie den neuen Code für benutzerdefinierte Zielgruppen bereitstellen, die von der gesamten Installationsbasis segmentiert sind.

Der Prozess funktioniert folgendermaßen:

1. Der Entwickler liefert den Code wie gewohnt aus, nur dass die Bereitstellung hinter Feature Flags erfolgt, die auf das jeweilige Team targetiert sind.
2. Die Entwicklungsteams können hinter den Feature Flags in der Produktion testen, um die Funktionalität zu validieren.
3. Sollte etwas schief gehen, kann jeder im Team das Feature Flag deaktivieren, um den Code zu entfernen, der das Problem verursacht hat.
4. Nach Beendigung des Deployment Freeze kann das Team die Testpersonen aus dem Flag entfernen und das Feature für alle ausrollen.

Mit diesem Ansatz vermeiden Sie, dass Sie Ihren Bereitstellungsprozess ändern, willkürliche Fristen setzen und die Brüchigkeit des Systems riskieren müssen. Die Techniker müssen die Bereitstellung in der Produktion für die Dauer des Einfrierens nicht unterbrechen. Mit Feature Flags bemerken die Kunden auch nicht, dass der Code kontinuierlich ausgeliefert wird und dass neue Funktionen hinter den Flaggen entwickelt und ausgeliefert werden.

Der "Deployment Slushie" hat jedoch einige Einschränkungen. Funktionen, die zu Ausfallzeiten führen, wie z.B. eine Datenbankänderung, sind nach wie vor tabu. Funktionen, die nicht rückgängig gemacht werden können (Beispiel: Migrationsskript, das den Zustand eines Kundenerlebnisses verändern würde), können ebenfalls noch nicht ausgeliefert werden. Aber insgesamt können Sie mit Hilfe von Feature Flags Ihren Feiertags-Freeze - oder jeden anderen Code-Freeze - wie gewohnt ausliefern, ohne sich um die Nachwirkungen des Tauwetters sorgen zu müssen.

Bieten Sie Ihren Kunden in der bevorstehenden Urlaubssaison ein nahtloses Erlebnis, ohne dass Sie Ihre Entwicklungen unterbrechen müssen. Nutzen Sie Feature Flags und halten Sie Ihre Entwicklungszüge den ganzen Winter über am Laufen.