Blogartikel

5min. Lesezeit

1,000 Experiments Club: Ein Gespräch mit Jonny Longden von Journey Further

Ist Experimentieren für jeden etwas? Ein klares Ja, sagt Jonny Longden. Alles, was Sie brauchen, sind zwei Zutaten: Einen starken Willen und die Ausdauer, es umzusetzen.

Es gibt einen gefährlichen Mythos, der sich hartnäckig hält: und zwar, dass man ein großes Unternehmen sein muss, um experimentieren zu können. Dabei sind es gerade die kleineren Unternehmen und Start-ups, die Experimente am meisten brauchen, sagt Jonny Longden.

Mit mehr als einem Jahrzehnt Erfahrung in den Bereichen Conversion-Optimierung und Personalisierung hat Jonny Longden die Performance-Marketing-Agentur Journey Further mitbegründet, um Kunden dabei zu helfen, Experimente in das Kerngeschäft einzubinden. Derzeit leitet er die Conversion-Abteilung der Agentur, die sich auch auf PPC, SEO, PR – neben anderen Marketing-Spezialisierungen – konzentriert.

Jedes Unternehmen, das irgendeine Art von Entdeckung machen will, sollte experimentieren. Vor allem Start-ups, die sich in der Erkundungsphase ihrer Entwicklung befinden. „Für Experimente braucht man keine bestimmte Größe: Es kommt nur darauf an, wie man es angeht“, sagte Jonny im Gespräch mit Marylin Montoya, VP Marketing von AB Tasty.

Hier sind einige der wichtigsten Erkenntnisse aus dem Gespräch mit Jonny.

Die Demokratisierung des Experimentierens

Die meisten Experimentierteams und -programme werden in großen Unternehmen aufgebaut, aber das bedeutet nicht unbedingt, dass andere Unternehmen unterschiedlicher Größe nicht auch experimentieren können. Auch kleinere Unternehmen und Start-ups können davon profitieren, sofern sie die nötige Ausdauer und die Fähigkeiten zur Umsetzung haben.

Sie müssen wirklich daran glauben, dass Ihre Ideen ohne Experimente nicht funktionieren werden, sagt Jonny. Es gibt Dinge, von denen man glaubt, dass sie funktionieren werden, und doch tun sie es nicht. Umgekehrt gibt es viele Dinge, von denen man glaubt, dass sie nicht funktionieren, die sich aber am Ende doch positiv auswirken. Die einzige Möglichkeit, zu diesem Ergebnis zu kommen, ist das Experimentieren.

Die größten Entdeckungen (z. B. in den Bereichen Raumfahrt, Reisen, Medizin usw.) beruhen letztlich auf einer wissenschaftlichen Methodik, die nur aus Beobachtung, Hypothesen, Tests und Optimierung besteht. Wenn man mit dieser Einstellung an das Experimentieren herangeht, ist es ein Kinderspiel.

Erstellen der richtigen Roadmaps mit Produktteams

Die Einbindung von Experimenten an der Spitze des Produktentwicklungsprozesses ist wichtig, aber trotzdem tun es die meisten nicht, sagt Jonny. Aus rein geschäftlicher Sicht geht es darum, das Risiko der Entwicklung zu verringern und den Wert einer Änderung oder eines Features zu beweisen, bevor weitere Zeit, Geld und Ressourcen investiert werden.

Glücklicherweise ist die agile Methodik, die von vielen modernen Teams angewandt wird, dem Experimentieren ähnlich. Beide beruhen auf der iterativen Zusammenarbeit mit dem Kunden und einem Zyklus aus rigoroser Forschung, quantitativer und qualitativer Datenerfassung, Validierung und Iteration. Der springende Punkt ist die Sammlung sowohl quantitativer als auch qualitativer Daten – ein ausgewogenes Verhältnis von Feedback und Umfang.

Der Erfolg der Erstellung einer Roadmap für ein Experimentierprogramm hängt vom Verständnis der Organisationsstruktur eines Unternehmens oder einer Branche ab. In SaaS-Unternehmen sind Experimente in die Produktteams eingebettet, während sie bei E-Commerce-Unternehmen besser in die Marketingabteilung passen. Sobald Sie den Verantwortlichen und die Ziele des Experiments bestimmt haben, müssen Sie sich darüber klar werden, ob Sie die Tests effektiv durchführen können und über die richtigen Prozesse verfügen, um die Ergebnisse eines Tests umzusetzen.

Experimentieren ist letztendlich Innovation

Je mehr Sie experimentieren, desto mehr Wert schaffen Sie. Das Experimentieren in großem Maßstab ermöglicht es den Menschen, zu lernen und auf der Grundlage dieser Erkenntnisse weitere Tests durchzuführen. Nutzen Sie das Testen nicht nur, um die Gewinner zu ermitteln, denn aus den fehlgeschlagenen Tests können viel mehr Erkenntnisse gewonnen werden. Es kann zum Beispiel sein, dass nur einer von zehn Tests funktioniert. Der wahre Wert liegt in den neun Lektionen, die Sie gelernt haben, und nicht nur in dem einen Test, der positive Auswirkungen gezeigt hat.

Wenn Sie das Ganze so betrachten, werden Sie erkennen, dass die Untersuchungen nach dem Test und die anschließenden Maßnahmen von entscheidender Bedeutung sind: Dort werden Sie weitere Fortschritte in Richtung größerer Innovationen erzielen.

Jonny nennt dies den Schneeballeffekt des Experimentierens. Experimentieren ist Innovation – wenn es richtig gemacht wird. Im Grunde geht es darum, zu entdecken, wie Ihre Kunden darauf reagieren. Und solange Sie aus den Ergebnissen Ihrer Tests lernen, werden Sie in der Lage sein, schneller zu Innovationen zu kommen, gerade weil Sie auf diesen Erkenntnissen aufbauen. So treiben Sie Innovationen voran, die tatsächlich funktionieren.

Was können Sie noch aus unserem Gespräch mit Jonny Longden lernen?

  • Übergang vom Experimentieren zur Validierung
  • Wie man die Kreativität während des Experimentierens beibehält
  • Verwenden von CRO, um die richtigen Probleme zu identifizieren, die angegangen werden müssen
  • Die erforderlichen Bausteine für erfolgreiche Experimente
Über Jonny Longden

Jonny Longden leitet die Conversion-Abteilung von Journey Further, einer Performance-Marketing-Agentur, die sich auf PPC, SEO, PR usw. spezialisiert hat. Die in Großbritannien ansässige Agentur, die teils Agentur, teils Beratungsunternehmen ist, hilft Unternehmen, datengesteuert zu arbeiten und Experimente in ihre Programme einzubauen. Davor war Jonny über ein Jahrzehnt in den Bereichen Conversion-Optimierung, Experimentieren und Personalisierung tätig und arbeitete mit Sky, Visa, Nike, O2, Mvideo, Principal Hotels und Nokia zusammen.

Über den 1,000 Experiments Club

Der 1,000 Experiments Club ist ein von AB Tasty produzierter Podcast, der von Marylin Montoya, VP of Marketing bei AB Tasty, moderiert wird. Begleiten Sie Marylin und das Marketing-Team, wenn sie sich mit den erfahrensten Experten in der Welt des Experimentierens zusammensetzen, um ihre Erkenntnisse darüber zu enthüllen, was nötig ist, um erfolgreiche Experimentierte zu entwickeln und durchzuführen.

Kennst du diese Folge schon?

Wenn nicht, wirf doch gerne direkt einen Blick in unseren letzten Artikel zur Podcast-Episode mit Chad Sanderson, mit dem wir über die erfolgreichsten Arten von Experimentation gesprochen haben.

Abonniere
unseren Newsletter

bloc Newsletter DE

Wir verarbeiten und speichern deine persönlichen Daten, um deine Anfrage zu beantworten. Siehe dir unsere Datenschutzerklärung an.

Blogartikel

17min. Lesezeit

Feature Toggles: Ein Überblick & unsere Best Practices

Feature Toggles zählen zu den leistungsfähigsten Methoden, wenn es um die Unterstützung von Continuous Integration und Continuous Delivery (CI/CD) geht. Feature Toggles – auch Feature Flags genannt – sind eine Methode, mit der Features während der Laufzeit geändert werden können, ohne dabei den Code zu ändern.

Entwickler können zum Erstellen von Features Toggles einen „Decision Point“ coden, an dem das System ein bestimmtes Feature ausführt, abhängig davon, ob bestimmte Bedingungen erfüllt werden oder nicht. Mit anderen Worten, mit Feature Toggles können Sie kontextsensitive Software schnell und effizient ausliefern.

Feature Toggles haben viele Einsatzmöglichkeiten, von der Unterstützung der agilen Entwicklung bis hin zu Markttests und zur Optimierung laufender Operationen. Hinter dieser Fähigkeit steckt aber auch die Gefahr, dass Ihr Code unnötig komplexer wird. Sie müssen mit Feature Toggles richtig umgehen können, um das Beste aus ihnen herauszuholen.

In diesem Artikel bieten wir Ihnen einen Überblick darüber, was Feature Toggles bewirken und wie Sie sie in Ihren Entwicklungs- und Produktionsumgebungen implementieren können. Darüber hinaus stellen wir Ihnen einige Best Practices vor, die wir zur Verwendung dieser Toggles empfehlen.

 

[toc content=“.entry-content“]

 

Was genau ist ein Feature Toggle?

Einfach gesagt ist ein Feature Toggle ein leistungsstarkes „If“-Statement, ab dem während der Laufzeit mindestens einem oder zwei verschiedenen Codepfaden abhängig von einer oder mehreren Bedingungen gefolgt wird. Hier ein konkretes Beispiel:

normalFeature = {
‚id‘: 1,
‚description‘: u’basic service‘,
’newstuff‘: False
}

testFeature = {
‚id‘: 2,
‚description‘: u’much better service‘,
’newstuff‘: True
}

@app.route(‚/ourapp/api/v1.1/storefront‘, methods=[‚GET‘])
def get_tasks():
if internalTester == True:
return jsonify({‚feature‘: testFeature})
else:
return jsonify({‚feature‘: normalFeature})

 

Hier haben wir zwei verschiedene generische Features definiert: normalFeature und testFeature. Während der Laufzeit prüft die Applikation in der Konfiguration, ob das Feature von einem oder einer interne(n) Test-UserIn geladen wird. Wenn ja, lädt die Applikation das Test-Feature, das sich in der Entwicklung befindet. Wenn nicht, sieht der oder die „normale“ KundIn das aktuelle Feature.

Feature Toggles Testing
Beispiel eines Feature Toggle, das zwei Codepfade steuert (Quelle)

 

Feature Toggles können alles sein, ein einfaches „If“-Statement oder komplexe Entscheidungsbäume, die auf viele verschiedene Variablen einwirken. Um festzulegen, welche Richtung ein Toggle nehmen soll, können zahlreiche Bedingungen verwendet werden, u. a. Ergebnisse von Tauglichkeitstests aus anderen Features in der Codebase, eine Einstellung in der Feature Management Software oder eine Variable aus einer Konfig-Datei.

 

Verschiedene Feature Toggles für verschiedene Aufgaben

Gehen Sie mit Feature Toggles jeweils unterschiedlich um, je nachdem, wie Sie sie bereitstellen möchten. Es kann nützlich sein, Toggles in Kategorien nach zwei Aspekten zu unterteilen: wie lange Toggles in der Entwicklung sind bzw. live geschaltet bleiben und wie dynamisch ihre Funktion ist. Demzufolge können wir Feature Toggles in vier verschiedene Kategorien unterteilen:

  • Release Toggles
  • Experiment Toggles
  • Ops Toggles
  • Permission Toggles

Diagramm der Feature Toggles-Kategorien

Ein Diagramm der vier Kategorien der Feature Toggles (Quelle)

 

Release Toggles

Diese Toggles unterstützen Entwicklerteams, wenn sie neue Features schreiben. Statt einen Zweig zu erstellen, in dem das Team das neue Feature schreibt, generiert es ein Release Toggle in der Master Codebase, wobei der Code inaktiv bleibt, während an ihm gearbeitet wird. Die Entwickler können den Trunk Code nach wie vor in die Produktion geben, um ihre Auslieferungsziele zu erfüllen.

Release Toggles sollen in der Regel kein fester Bestandteil Ihrer Codebase sein. Sobald das zugehörige Feature endgültig ist, sollten die Toggles entfernt werden. In der Praxis bedeutet dies in der Regel, dass diese Toggles einen Lebenszyklus von einigen Tagen bis zu einigen Wochen durchlaufen und sich in puncto Langlebigkeit somit auf einer Skala im unteren Bereich befinden. Release Toggles sind auch nicht besonders dynamisch. Entweder steht das Feature zur Freigabe bereit oder nicht.

Beispiel für ein Release Toggle

Ein e-Commerce-Unternehmen entwickelt auf Anfrage eines hochkarätigen Kunden eine neue Konfiguratorfunktion. Der Konfigurator überwacht Artikel, die der Kunde bereits zusätzlich ausgewählt hat, und schlägt Artikel-Sets vor, um seine Bestellung abzurunden.

Das Unternehmen möchte dieses Feature im Endeffekt allen Kunden anbieten. Aber derzeit funktioniert der Konfigurator nur nach den Vorgaben dieses einen Kunden. Das Entwicklerteam dieses Konfigurators aktiviert für dieses neue Feature ein Release Toggle, das es inaktiv lässt.

 

Experiment Toggles

Diese Toggles werden verwendet, um A/B-Tests oder multivariable Tests einfacher zu machen. Sie erstellen einen Toggle Point, hinter dem zwei oder mehrere Codepfade mit den zu testenden Features liegen. Während der Laufzeit teilt das System – oder das Toggle selbst – Nutzer in verschiedene Kohorten auf, an denen diese Features getestet werden.

Durch die Verfolgung aggregierter Experience-Daten bei jeder Kohorte können Sie die Wirkung der verschiedenen Features vergleichen. Experiment Toggles sind eine beliebte Methode für die Optimierung von Marketing-Initiativen, User Experiences und anderer Features für UserInnen.

In der Regel sollten Experiment Toggles nur so lange existieren, bis keine Daten zum Feature-Testing mehr gesammelt werden müssen. Der exakte Zeitrahmen hängt vom Traffic-Volumen bei diesem Feature ab, beläuft sich aber in der Regel auf mehrere Wochen bis mehrere Monate. Diese Einschränkung bezieht sich eher auf den Test selbst als auf das Toggle. Der Nutzen der gesammelten Daten verliert sich im Laufe der Zeit, wenn andere Feature- und Code-Updates Vergleiche mit zuvor gesammelten Nutzerdaten entkräften.

Beispiel für ein Experiment Toggle

Unser e-Commerce-Unternehmen hat die Fehler in seinem neuen Konfigurator beseitigt. Aber es wird darüber diskutiert, welcher der beiden Vorschlagsalgorithmen die beste Experience bietet. Man entschließt sich für einen A/B-Test, um Daten aus der realen Welt zu erhalten.

Das Unternehmen fügt ein Experiment Toggle zum Produktionskonfigurator mit zwei verschiedenen Vorschlagsalgorithmen dahinter hinzu. Das Toggle teilt die UserInnen in zwei Kohorten mit einem Modulo auf, wenn sie versuchen, den Konfigurator zu laden. Nach drei Wochen ist das Team der Meinung, endgültige Daten zu haben, die zeigen, dass mehr UserInnen ihre Bestellungen mit dem Algorithmus B abschließen. Das e-Commerce-Unternehmen entfernt das Experiment Toggle und der Algorithmus B wird für alle UserInnen live geschaltet.

 

A/B Testing
A/B Test Beispiel (Quelle)

 

Ops Toggles

Ops Toggles werden zum Abschalten von Features verwendet – wie ein „Kill Switch“ – oder um die Performance der Features anzupassen. Wenn zum Beispiel bestimmte Bedingungen nicht erfüllt werden und etwa KPI-Ziele unter einem Schwellenwert liegen, schaltet das Toggle das betreffende Feature ab, bis sich die Bedingungen verbessern. Ops Toggles sind für die Programmierung neuer Features kurz nach dem Testing oder bei ressourcenintensiven Features nützlich.

Die Langlebigkeit von Ops Toggles hängt von den jeweiligen Anwendungsfällen ab. Wenn Sie ein Ops Toggle zum Einstellen eines neuen Features kurz nach der Entwicklung verwenden, dann brauchen Sie das Toggle wahrscheinlich nur ein paar Monate. Ein Kill Switch-Toggle wird in der Regel jedoch als permanenter Bestandteil des Codes erstellt. Ops Toggles sind in der Regel genauso statisch oder dynamisch wie die Bedingungen, unter denen das kontrollierte Feature genutzt wird. Beispielsweise sind Ops Toggles tendenziell relativ statisch, wenn sie nur mit einer Leistungskennzahl verbunden sind.

Beispiel für ein Ops Toggle

Unser e-Commerce-Unternehmen bereitet sich auf eine Traffic-Spitze für den jährlichen Schlussverkauf vor. Das ist der erste Sale, bei dem der Konfigurator in der Produktion ist. Während der Tests haben die Entwickler festgestellt, dass der vom User bevorzugte B-Algorithmus Systemressourcen stark beansprucht.

Die Operators verlangten einen Kill Switch für den Konfigurator, bevor die Sales-Angebote live geschaltet wurden. Sie wollten nur ein einziges Toggle, auf das sie in der Release Management Software klicken mussten, falls die Performance nachlassen sollte. Und siehe da, am ersten Tag des Schlussverkaufs begann die Performance beim Konfigurator zu fallen. Und das Ops-Team konnte das Feature schnell abschalten, bevor es von zu vielen UserInnen wahrgenommen wurde.

 

Permission Toggles

Permission Toggles sollen langlebiger sein oder sogar ein fester Bestandteil in Ihrem Code. Sie werden als Methode verwendet, um einem bestimmten Teil von UserInnen Features anzuzeigen. Beispielsweise können Sie ein Permission Toggle verwenden, um ausschließlich Premium UserInnen auf Ihrer Website Premium Inhalte anzubieten. Permission Toggles sind generell die dynamischsten Toggles unter den vier hier definierten Kategorien, da sie in der Regel für eine oder einen UserIn getriggert werden.

Beispiel für ein Permission Toggle

Das einfache Beispiel am Anfang dieses Artikels lässt sich praktisch mit einem Permission Toggle vergleichen. Nach dem jährlichen Schlussverkauf ist unser e-Commerce-Unternehmen der Meinung, Algorithmus B sei zu ressourcenintensiv, um das Feature allen UserInnen anzuzeigen. Stattdessen entscheidet sich das Unternehmen, ein Premium Feature zu erstellen. Das Permission Toggle kann sich wie folgt darstellen:

normalFeature = {
‚id‘: 1,
‚description‘: u’basic service‘,
‚configurator‘: False
}

premiumFeature = {
‚id‘: 2,
‚description‘: u’the better configurator‘,
‚configurator‘: True
}

@app.route(‚/ourapp/api/v1.1/storefront‘, methods=[‚GET‘])
def get_tasks():
if premiumUser == True:
return jsonify({‚feature‘: premiumFeature})
else:
return jsonify({‚feature‘: normalFeature})

 

Feature Toggles vs. Feature Flags

Eine kleine Randbemerkung: Es gibt einige Diskussionen über den Begriff Feature Toggle verglichen zum Begriff Feature Flag. „Toggle“ trifft eher zu, wenn der Code bei mehreren Hauptzweigen des Codes ein- oder ausgeschaltet ist. „Flag“ trifft eher zu, wenn auf einen Entscheidungspunkt multikonditionale oder eine große Anzahl an Codepfaden folgen.

 

Feature Toggles in Ihre Roadmap zur Unterstützung agiler Workflows integrieren

Mit Feature Toggles in Ihrem Entwicklungsprozess werden neuere agile Ansätze unterstützt. Sie können eine Software veröffentlichen, während noch Code Sprints für neue Features bearbeitet werden. Diese Features müssen lediglich hinter Toggles verborgen werden, bis sie für die Veröffentlichung, Marketingtests oder den nächsten Schritt im Entwicklungsprozess tauglich sind.

In der Regel würden Sie die kürzlich vom User oder von der Userin gewünschten Features auf Code-Verzweigungen unter einem eher herkömmlichen Wasserfallmodell schreiben. Diese Features würden im Anschluss einen langen Test- und QA-Prozess durchlaufen, bevor Ihr Team die Features wieder in den Trunk Code zurückführen kann. Mit Feature Toggles können Sie den gesamten Entwicklungs- und Testprozess direkt auf dem Trunk Code durchführen.

 

Unsere Best Practices für die Verwendung von Feature Toggles

Wie bereits erwähnt, stehen Feature Toggles für eine leistungsstarke und flexible Entwicklungsmethode. Wenn Sie Ihre Toggles nicht sorgfältig implementieren und managen, können sie schnell eine chaotische Codebase erhalten.

Es wurden viele verschiedene Best Practices zum Coden von Feature Toggles  vorgeschlagen, aber wir wollten Ihnen einige unserer eigenen Toggles anbieten. Sobald ein unsauberer Entscheidungspunkt in Ihre Codebase geschrieben wird, scheinen viele weitere zu folgen. Wenn diese Best Practices von Anfang an befolgt werden, können Sie solche Probleme in Schach halten.

Website Code

 

Verwenden Sie Feature Toggles, um langsam zur agilen Entwicklung zu wechseln

Wenn Ihr Team agile Entwicklungs- und Testmethoden ausprobieren möchte, ohne sich völlig in eine neue Entwicklungsmethode stürzen zu müssen, dann sind Feature Toggles in Ihrer Roadmap ein ausgezeichnetes Mittel für den Anfang. Die Kosten für diese Versuche sind gering. So könnte zum Beispiel zunächst nur ein Team ein Experiment Toggle für einen ersten Canary Release verwenden.

Wenn der Versuch gelingt, können Sie das Experiment Toggle durch ein Ops Toggle ersetzen, wenn das Feature in die Produktion geht. Dann weiten Sie die Nutzung des Toggles auf andere Teams oder Prozesse aus. Führen Sie dieses Toggle früher in die Entwicklungszyklen ein als Release Toggles. Dann sind Sie langsam aber sicher auf dem Weg zur völlig agilen Entwicklung.

 

Verwenden Sie Toggles sowohl für interne als auch externe Features

Jetzt müsste klar sein: Feature Toggles haben während des gesamten Entwicklungs- und Produktionslebenszyklus Ihrer Software Ihren Zweck. Schränken Sie die Toggle-Nutzung nicht auf Features ein, die nur von KundInnen gesehen werden. Sie können Release und Ops Toggles auch für Backend-Features verwenden. Die Toggles bieten DevOps Teams eine besonders granulare Stufe beim Kontroll- und Risikomanagement des Codes, was wichtig sein kann, wenn Backend-Features geändert werden, die einen entscheidenden Einfluss darauf haben, wie Ihr System performt.

 

Lassen Sie die Toggle-Planung in Ihre Design-Phase einfließen

Vom Toggle-Namen und den Konfigurationseinstellungen bis zum Entfernen der Toggles und der Zugangskontrolle – alles hängt davon ab, wie Sie neue Features gleich zu Beginn entwerfen. Bauen Sie diese Toggle-Planung in Ihren Designprozess ein und die nächsten sechs Monate Ihres Feature Managements werden um einiges einfacher sein.

 

Verwenden Sie ein standardisiertes Toggle Namensschema

Viele Unternehmen verwenden einen Style Guide für Entwickler, der festlegt, wie sie Code schreiben und organisieren sollen, wie sie zum Beispiel Abstände, Reihenfolge und Klammern beim Naming anwenden. Wenn Sie Feature Toggles verwenden wollen, sollten Sie auch den Naming-Stil schon frühzeitig im Einführungsprozess Ihrer Toggles standardisieren.

Kurz und bündig zu sein, ist beim Coden für andere Aspekte wichtig. Wenn es aber um Toggle-Namen geht, seien Sie ausführlich. Details bedeuten Klarheit. Ausführliche Toggle Namen helfen Entwicklern und Ops Teams außerhalb Ihres Kernteams zu verstehen, was sie prüfen, wenn ihr einziger Bezug der Toggle Name ist, den Sie sechs Monate zuvor aus einer Laune heraus gewählt haben.

Einige weitere Toggle-Namenskonventionen, die wir vorschlagen:

  • Binden Sie den Namen des Teams oder Projekts ein.
  • Binden Sie das Datum ein, an dem das Toggle erstellt wurde.
  • Identifizieren Sie die Kategorie des Flags.
  • Beschreiben Sie das tatsächliche Toggle-Verhalten.

 

Hier ein Beispiel: algteam_10-12-2021_Ops_configurator-killswitch

Dieser Name bietet einige nützliche Informationen, aus denen jeder oder jede in einem Team ableiten kann, worum es sich handelt, wenn ein Toggle in einer Fehlermeldung genannt wird. Sie wissen, wer das Toggle geschrieben hat, wie lange es in der Codebase war und was das Toggle bewirkt.

Unterschiedliche Toggles unterschiedlich handhaben

Es scheint selbstverständlich, ist aber ein wichtiger Punkt, den es hervorzuheben gilt. Wie wir bereits oben erwähnt haben, können Feature Toggles in vier allgemeine Kategorien unterteilt werden. Sie sollten die einzelnen Kategorien unterschiedlich handhaben.

Denken Sie an den oben erwähnten Konfigurator, als er die Entwicklungsphase, dann Markttests und anschließend den laufenden Betrieb durchlief. Der Konfiguratorcode befand sich die gesamte Zeit hinter einem dieser Features Toggles. Aber die Art und Weise, wie die Entwicklungs- und Produktteams mit diesem Toggle interagieren, muss in jedem Stadium geändert werden.

Zu Beginn der Entwicklung kann das Toggle einfach in der Versionskontrolle konfiguriert werden. Während das e-Commerce-Unternehmen A/B-Tests durchführt, kann das Toggle auf einer Feature Management-Plattform sein. Wenn das Ops-Team einen Kill Switch hinzufügt, kann es sich entscheiden, es in derselben Feature Management-Plattform, aber auf einem anderen Dashboard zu lassen.

Feature Management Plattform Dashboard

AB Tasty Flagship Dashboard (Source)

Feature Toggle-Konfigurationen immer darlegen

Wie bei jedem anderen Codeobjekt auch, ist es besser, Feature Toggle-Konfigurationen als Metadaten zu dokumentieren, damit andere Entwickler, Tester und Produktionsteams ein Dokument in Papierform haben, dem sie folgen können, um genau zu verstehen, wie Ihr Feature Toggle in einer bestimmten Umgebung läuft. Am besten, Sie speichern Ihre Toggle-Konfiguration in einem für Menschen lesbaren Format, damit auch andere außerhalb Ihres Teams verstehen, was ein Toggle bewirkt.

Diese Best Practice ist für die Features nützlich, bei denen längerfristig Toggles verwendet werden sollen. Denken Sie wieder an unser Konfiguratorbeispiel. Ein völlig neuer Product Operator, der versucht, einen plötzlichen, unerwarteten Performance-Rückgang zu verstehen, würde sehr dankbar für eine Datei sein, die für Menschen lesbar ist und ihm erklärt, dass der B-Algorithmus bei Tests ein Jahr zuvor plötzlich ressourcenintensiv wurde.

 

Behalten Sie die Haltekosten für Feature Toggles im Auge

Wenn Sie Feature Toggles zum ersten Mal benutzen, sollten Sie sich nicht hinreißen lassen, alle auf einmal überall im Code zu verwenden. Feature Toggles lassen sich zwar einfach erstellen, müssen aber richtig gehandhabt und getestet werden, um einen wirklichen Nutzen zu ziehen. Setzen Sie nach und nach mehr Feature Toggles ein oder ziehen Sie die Integration einer Feature Management-Plattform in Ihre Entwicklungs- und Ihre Testumgebung in Betracht.

Stellen Sie Feature Toggles strategisch bereit und halten Sie Ihren Toggle-Bestand so niedrig wie möglich. Verwenden Sie sie, wenn es notwendig ist. Aber überprüfen Sie, ob Toggles die angemessene Methode für die Lösung eines bestimmten Problems sind.

Lassen Sie keine alten Toggles in Ihrem Code. Streichen Sie die Toggles zusammen, sobald sie ausgedient haben. Je mehr inaktive Toggles im Code, desto größer der Mehraufwand für Ihr Team, diese Toggles zu managen. Sie können Toggles entfernen, wenn Sie Code Cleanups auf die To-Do-Liste Ihrer Teams setzen oder diesen Prozess in Ihre Management-Plattform integrieren.

Developer von Features Toggles
Entwickler bei der Arbeit (Quelle)

 

Halten Sie den Toggle Scope möglichst klein

Aufgrund der Wirkung der Toggles neigt man dazu, große Codeabschnitte von einer komplexen Toggle-Reihe zu steuern. Bleiben Sie „standhaft“ und halten Sie den Toggle Scope bei jeder Aufgabe möglichst klein.

Sollte ein Toggle auf mehrere Features übergreifen, kann es für den Rest des Teams zum Albtraum werden, Bugs zu beheben, die Wochen oder Monate zurückliegen und sich jetzt auf die Arbeit des Teams auswirken.

Nehmen wir noch einmal unser Konfiguratorbeispiel. Unser Dev-Team erstellt vier separate Widgets, die der oder die UserIn im Konfiguratortool benutzt. In diesem Szenario würden wir fünf Toggles empfehlen: eins für den Konfigurator selbst und eins für jedes einzelne Widget. Coden Sie die Widget Toggles abhängig vom Konfigurator-Toggle. Wenn in diesem Framework eines der Widgets nicht richtig lädt, werden die anderen dem oder der UserIn angezeigt.

Feature Toggles können den gesamten Entwicklungsprozess verändern

Feature Toggles sind für die Entwicklung, Tests und Steuerung von Code Features im Framework der Continuous Integration und Continuous Delivery eine wirkungsvolle Methode. Sie stehen für eine einfache Methode, mit der Ihr Team einen stabileren Code höherer Qualität nach agilen Prinzipien ausliefern kann.

In diesem Artikel haben wir erklärt, wie Feature Toggles funktionieren, welche Toggles Sie erstellen und wie Sie diese Toggles in Ihrem agilen Prozess verwenden – oder sie in einem Entwicklungsprozess ausprobieren können. Darüber hinaus haben wir Ihnen einige unserer empfohlenen Best Practices vorgestellt, damit Ihr Unternehmen das Beste aus Feature Toggles herausholen kann.

 

Fangen Sie klein an, um im größeren Rahmen fortzufahren

Es gibt keinen Grund, nicht schon heute Feature Toggles zu nutzen. Fangen Sie klein an und nutzen Sie zunehmend mehr Features Toggles, wenn Ihr Team sich daran gewöhnt und verstanden hat, wie diese Toggles funktionieren. Wenn Sie gerade beginnen, ein vollkommen neues Feature zu coden, richten Sie ein Release Toggle im Trunk Code ein. So brauchen Sie keine Verzweigung. Wenn Sie mit Markttests beginnen, richten Sie ein Experiment Toggle für Split Testings ein.

Wenn Ihr Team sich im Klaren ist, wie es Feature Toggles verwenden möchte, ziehen Sie eventuell eine Feature Management-Plattform für eine optimierte Administration der Toggles in Betracht. Die Optimierung von Entwicklung und Testing war genau das, woran wir gedacht hatten, als wir Flagship, unsere Release- und Feature Management-Plattform, entwickelt haben.

Mit Flagship hat Ihr Team das richtige Tool zur Hand, um Toggle Workflows und Kommunikation zu optimieren. Unabhängig von den Aufgaben oder dem Fokus eines Teams bringt Flagship, unser Feature Management-Tool, alle Voraussetzungen mit, um die richtigen Features auf richtige Weise bereitzustellen.