Verhindern Sie technische Schulden, indem Sie Feature Flags und die Lebenszeit von Experimenten verstehen.

Sie können z.B. verfolgen, wie lange sich das Feature Flag oder das Experiment bereits in Ihrem System befindet und wie viele verschiedene Zustände (z.B. an/aus, verschiedene Konfigurationen, verschiedene Experimentierversionen) es hat. Während Sie an Ihrer Funktion arbeiten, kann sie viele verschiedene Zustände durchlaufen, bevor sie die endgültige, optimierte Version erreicht, aus der sie dann entfernt werden kann. Wenn das Feature Flag schon lange in Ihrem System vorhanden ist und alle Ihre Benutzer den gleichen Status des Feature Flags haben, sollte es wahrscheinlich entfernt und der Code des Features in Ihre Codebasis integriert werden.

Es ist jedoch klug, den Zweck einer Flagge oder eines Experiments zu evaluieren, bevor Sie sie entfernen, denn die tatsächliche Lebensdauer eines Experiments oder einer Feature Flagge hängt von ihrem Anwendungsfall ab, mehr dazu weiter unten.

In meiner Erfahrung als Ingenieur und technischer Leiter habe ich verschiedene Arten von Flaggen und Experimenten gesehen. Im Folgenden gehe ich die Beispiele aus meinem kostenlosen E-Book Ship Confidently with Progressive Delivery and Experimentation durch und zeige auf, welche Feature Flags entfernt werden sollten und welche je nach Anwendungsfall in Ihrer Codebasis verbleiben können. Lassen Sie uns eintauchen!

01 Temporäre Flag- und Experiment-Typen zur Festlegung eines Zeitplans für die Entfernung

Wenn eine Funktion für alle Benutzer eingeführt werden soll oder Sie die Funktion für ein kurzfristiges Experiment verwenden, sollten Sie sicherstellen, dass Sie ein Ticket haben, mit dem Sie die Entfernung verfolgen können, sobald die Funktion vollständig für Ihre Benutzer eingeführt oder das Experiment abgeschlossen ist. Diese temporären Flaggen können Wochen, Monate oder Quartale andauern. Beispiele hierfür sind:

• 🚪 Painted-door Experimente: Diese Experimente sind dazu gedacht, die kleinste Menge an Benutzeroberfläche für eine Funktion zu zeigen, um festzustellen, ob Kundeninteresse besteht, und werden in der Regel nur in den frühen Phasen des Lebenszyklus der Softwareentwicklung verwendet. Diese Experimente sind nicht dafür gedacht, im Produkt zu bleiben, nachdem sie die Hypothese des Experiments validiert oder in-validiert haben.
• 🛩 Performance Experimente: Diese Experimente sind dazu gedacht, zwei verschiedene Implementierungen in einem realen Leistungsexperiment gegeneinander antreten zu lassen. Sobald genügend Daten gesammelt wurden, um die leistungsstärkere Lösung zu ermitteln, ist es in der Regel am besten, den gesamten Datenverkehr auf die leistungsstärkere Variante umzuleiten.
• 🏗 Groß angelegte Refactorings: Wenn Sie zwischen Frameworks, Sprachen oder Implementierungsdetails wechseln, ist es sinnvoll, diese eher riskanten Änderungen hinter einem Feature Flag zu implementieren, damit Sie sicher sein können, dass sie sich nicht negativ auf Ihre Benutzer oder Ihr Unternehmen auswirken. Sobald die Umstrukturierung jedoch abgeschlossen ist, werden Sie hoffentlich nicht wieder in die andere Richtung gehen und können das Feature Flag entfernen.
• 🎨 Produktumbenennungen: Wenn Ihr Unternehmen beschließt, das Erscheinungsbild Ihres Produkts aus Markengründen zu ändern, ist es sinnvoll, einen Rollout durchzuführen, um die Umstellung auf das neue Branding zu erleichtern und das Customer Engagement zu messen. Nachdem das neue Branding etabliert ist, ist es eine gute Idee, das Feature Flag zu entfernen, das die Umstellung bewirkt hat.

02 Permanente Flagge und Arten von Experimenten zur Überprüfung und Dokumentation

Wenn ein Feature so konzipiert ist, dass es für verschiedene Kunden unterschiedliche Zustände annehmen kann, oder wenn Sie seine Konfiguration für betriebliche Abläufe oder kontinuierliche Experimentier- und Optimierungszwecke kontrollieren möchten, dann ist es wahrscheinlich, dass das Flag für einen längeren Zeitraum in Ihrem Produkt verbleiben wird. Beispiele für diese Flaggen und Experimente sind:

• 💰 Werbeflags: Diese Flaggen sind nützlich, wenn Ihr Produkt oder Ihr Unternehmen in regelmäßigen Abständen eine besondere Aktion anbieten möchte. Sie könnten zum Beispiel jeden Winter eine Werbekampagne durchführen, bei der Sie Ihren Kunden einen kostenlosen Versand Ihrer Produkte anbieten. Durch die Implementierung eines Feature Flags, mit dem diese Werbeaktionen aktiviert und konfiguriert werden können, kann Ihr Team den Bedarf an technischen Ressourcen verringern, die diese regelmäßigen Werbeaktionen in regelmäßigen Abständen aktivieren oder deaktivieren.
• 🔒 Berechtigungsflags: Diese Flags sind nützlich, wenn Sie in Ihrem Produkt verschiedene Berechtigungsstufen haben, wie z.B. Nur-Lesen, die keinen Bearbeitungszugriff auf die Funktion erlauben. Sie sind auch nützlich, wenn Sie eine modulare Preisgestaltung haben, wie z.B. ein preiswertes "Einsteigerpaket", das die Funktion nicht enthält, aber ein teureres "Unternehmenspaket", das die Funktion enthält.
• 📦 Operative Flags: Diese Flags steuern die operativen Knöpfe Ihrer Anwendung. Mit diesen Flags können Sie zum Beispiel steuern, ob Sie Ereignisse, die von Ihrer Anwendung gesendet werden, in Stapeln zusammenfassen, um die Anzahl der ausgehenden Anfragen zu minimieren. Sie können sie auch verwenden, um die Anzahl der Rechner zu steuern, die für die horizontale Skalierung Ihrer Anwendung verwendet werden. Darüber hinaus können Sie damit einen rechenintensiven, nicht unbedingt erforderlichen Dienst deaktivieren oder bei einem Ausfall einen reibungslosen Wechsel von einem Drittanbieterdienst zu einem anderen ermöglichen.
• 📝 Konfigurationsbasierte Software: Für jede Software oder jedes Produkt, das über eine Konfigurationsdatei betrieben wird, ist dies ein großartiger Ort, um nahtlos Experimentieren einzufügen, das geringe Wartungskosten verursacht und dennoch endloses Experimentieren mit dem Produkt ermöglicht. Bei einigen Unternehmen wird das Produktlayout beispielsweise durch eine Konfigurationsdatei gesteuert, die abstrakt beschreibt, ob verschiedene Module enthalten sind und wie sie auf dem Bildschirm positioniert werden. Mit dieser Architektur können Sie auch dann, wenn Sie gerade kein Experimentieren durchführen, zukünftige Produktexperimente ermöglichen.

Beachten Sie, dass selbst wenn ein Flag dauerhaft sein soll, Sie diese Flags und den sie umgebenden Code regelmäßig überprüfen sollten, um festzustellen, ob sie veraltet sind oder nicht mehr verwendet werden sollten. Andernfalls kann die Beibehaltung dieser permanenten Flags zu technischen Schulden in Ihrer Codebasis führen.

Einige Unternehmen nutzen eine Integration zwischen einem Aufgabenverfolgungssystem und ihrem Feature Flag- und Experiment-Service, um diesen Bereinigungsprozess nahtlos und schnell durchzuführen. Wenn der Status von Feature Flags und Experimenten mit einem Ticket-Tracking-Tool synchronisiert werden kann, kann ein Engineering Manager Abfragen für alle Feature Flags und Experimente durchführen, deren Status in den letzten 30 Tagen nicht geändert wurde, und die Owner der Feature Flags und Experimente ausfindig machen, um deren Überprüfung zu bewerten. Diese Strategie ist besonders nützlich in Unternehmen, die über ein zentrales Team verfügen, das die Erfolgsmethoden für Feature Flags überprüft.

In anderen Unternehmen gibt es einen wiederkehrenden Tag, an dem Feature Flags und Experimente entfernt werden, und an dem die Ingenieure die ältesten Einträge in der Liste regelmäßig überprüfen. Diese Strategie ist besonders nützlich, um verschiedene Teams, die ihre eigenen Feature Flags besitzen, dazu zu bringen, über die regelmäßige Entfernung nachzudenken.