Feature Toggles haben viele Einsatzm\u00f6glichkeiten, von der Unterst\u00fctzung der agilen Entwicklung bis hin zu Markttests und zur Optimierung laufender Operationen. Hinter dieser F\u00e4higkeit steckt aber auch die Gefahr, dass Ihr Code unn\u00f6tig komplexer wird. Sie m\u00fcssen mit Feature Toggles richtig umgehen k\u00f6nnen, um das Beste aus ihnen herauszuholen.<\/p>\n
In diesem Artikel bieten wir Ihnen einen \u00dcberblick dar\u00fcber, was Feature Toggles bewirken und wie Sie sie in Ihren Entwicklungs- und Produktionsumgebungen implementieren k\u00f6nnen. Dar\u00fcber hinaus stellen wir Ihnen einige Best Practices vor, die wir zur Verwendung dieser Toggles empfehlen.<\/p>\n
[toc content=“.entry-content“]<\/p>\n
<\/h2>\nWas genau ist ein Feature Toggle?<\/strong><\/h2>\nEinfach gesagt ist ein Feature Toggle ein leistungsstarkes \u201eIf\u201c-Statement, ab dem w\u00e4hrend der Laufzeit mindestens einem oder zwei verschiedenen Codepfaden abh\u00e4ngig von einer oder mehreren Bedingungen gefolgt wird. Hier ein konkretes Beispiel:<\/p>\n
normalFeature = {<\/em><\/span>
\n‚id‘: 1,<\/em><\/span>
\n‚description‘: u’basic service‘,<\/em><\/span>
\n’newstuff‘: False<\/em><\/span>
\n}<\/em><\/span><\/p>\ntestFeature = {<\/em><\/span>
\n‚id‘: 2,<\/em><\/span>
\n‚description‘: u’much better service‘,<\/em><\/span>
\n’newstuff‘: True<\/em><\/span>
\n}<\/em><\/span><\/p>\n@app.route(‚\/ourapp\/api\/v1.1\/storefront‘, methods=[‚GET‘])<\/em><\/span>
\ndef get_tasks():<\/em><\/span>
\nif internalTester == True:<\/em><\/span>
\nreturn jsonify({‚feature‘: testFeature})<\/em><\/span>
\nelse:<\/em><\/span>
\nreturn jsonify({‚feature‘: normalFeature})<\/em><\/span><\/p>\nHier haben wir zwei verschiedene generische Features definiert: normalFeature und testFeature. W\u00e4hrend der Laufzeit pr\u00fcft die Applikation in der Konfiguration, ob das Feature von einem oder einer interne(n) Test-UserIn geladen wird. Wenn ja, l\u00e4dt die Applikation das Test-Feature, das sich in der Entwicklung befindet. Wenn nicht, sieht der oder die \u201enormale\u201c KundIn das aktuelle Feature.<\/p>\n![\"Feature](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/feature-toggles-testing-1024x876.png\")
Beispiel eines Feature Toggle, das zwei Codepfade steuert (Quelle<\/a>)<\/span><\/figcaption><\/figure>\nFeature Toggles k\u00f6nnen alles sein, ein einfaches \u201eIf\u201c-Statement oder komplexe Entscheidungsb\u00e4ume, die auf viele verschiedene Variablen einwirken.<\/strong> Um festzulegen, welche Richtung ein Toggle nehmen soll, k\u00f6nnen zahlreiche Bedingungen verwendet werden, u.\u00a0a.\u00a0Ergebnisse von Tauglichkeitstests aus anderen Features in der Codebase, eine Einstellung in der Feature Management Software oder eine Variable aus einer Konfig-Datei.<\/p>\nVerschiedene Feature Toggles f\u00fcr verschiedene Aufgaben<\/strong><\/h2>\nGehen Sie mit Feature Toggles jeweils unterschiedlich um, je nachdem, wie Sie sie bereitstellen m\u00f6chten. Es kann n\u00fctzlich 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\u00f6nnen wir Feature Toggles in vier verschiedene Kategorien unterteilen:<\/p>\n
\n- Release Toggles<\/li>\n
- Experiment Toggles<\/li>\n
- Ops Toggles<\/li>\n
- Permission Toggles<\/li>\n<\/ul>\n
![\"Diagramm](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/toggle-chart.png\")
<\/p>\n
Ein Diagramm der vier Kategorien der Feature Toggles (Quelle<\/a>)<\/span><\/p>\nRelease Toggles<\/h3>\n
Diese Toggles unterst\u00fctzen 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\u00e4hrend an ihm gearbeitet wird. Die Entwickler k\u00f6nnen den Trunk Code nach wie vor in die Produktion geben, um ihre Auslieferungsziele zu erf\u00fcllen.<\/p>\n
Release Toggles sollen in der Regel kein fester Bestandteil<\/strong> Ihrer Codebase sein.<\/strong> Sobald das zugeh\u00f6rige Feature endg\u00fcltig 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.<\/p>\nBeispiel f\u00fcr ein Release Toggle<\/strong><\/p>\nEin e-Commerce-Unternehmen entwickelt auf Anfrage eines hochkar\u00e4tigen Kunden eine neue Konfiguratorfunktion. Der Konfigurator \u00fcberwacht Artikel, die der Kunde bereits zus\u00e4tzlich ausgew\u00e4hlt hat, und schl\u00e4gt Artikel-Sets vor, um seine Bestellung abzurunden.<\/p>\n
Das Unternehmen m\u00f6chte 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\u00fcr dieses neue Feature ein Release Toggle, das es inaktiv l\u00e4sst.<\/p>\n
Experiment Toggles<\/h3>\n
Diese Toggles werden verwendet, um A\/B-Tests<\/a> oder multivariable Tests einfacher zu machen. Sie erstellen einen Toggle Point, hinter dem zwei oder mehrere Codepfade mit den zu testenden Features liegen. W\u00e4hrend der Laufzeit teilt das System \u2013 oder das Toggle selbst \u2013 Nutzer in verschiedene Kohorten auf, an denen diese Features getestet werden.<\/p>\nDurch die Verfolgung aggregierter Experience-Daten bei jeder Kohorte k\u00f6nnen Sie die Wirkung der verschiedenen Features vergleichen.<\/strong> Experiment Toggles sind eine beliebte Methode f\u00fcr die Optimierung von Marketing-Initiativen, User Experiences<\/a> und anderer Features f\u00fcr UserInnen.<\/p>\nIn der Regel sollten Experiment Toggles nur so lange existieren, bis keine Daten zum Feature-Testing mehr gesammelt werden m\u00fcssen. Der exakte Zeitrahmen h\u00e4ngt vom Traffic-Volumen bei diesem Feature ab, bel\u00e4uft sich aber in der Regel auf mehrere Wochen bis mehrere Monate. Diese Einschr\u00e4nkung 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\u00e4ften.<\/p>\n
Beispiel f\u00fcr ein Experiment Toggle<\/strong><\/p>\nUnser e-Commerce-Unternehmen hat die Fehler in seinem neuen Konfigurator beseitigt. Aber es wird dar\u00fcber diskutiert, welcher der beiden Vorschlagsalgorithmen die beste Experience bietet. Man entschlie\u00dft sich f\u00fcr einen A\/B-Test, um Daten aus der realen Welt zu erhalten.<\/p>\n
Das Unternehmen f\u00fcgt 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\u00fcltige Daten zu haben, die zeigen, dass mehr UserInnen ihre Bestellungen mit dem Algorithmus B abschlie\u00dfen. Das e-Commerce-Unternehmen entfernt das Experiment Toggle und der Algorithmus B wird f\u00fcr alle UserInnen live geschaltet.<\/p>\n![\"A\/B](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/AB-Testing-2.png\")
A\/B Test Beispiel (Quelle<\/a>)<\/span><\/figcaption><\/figure>\nOps Toggles<\/h3>\n
Ops Toggles werden zum Abschalten von Features verwendet \u2013 wie ein \u201eKill Switch\u201c \u2013 oder um die Performance der Features anzupassen. Wenn zum Beispiel bestimmte Bedingungen nicht erf\u00fcllt 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\u00fcr die Programmierung neuer Features kurz nach dem Testing oder bei ressourcenintensiven Features n\u00fctzlich.<\/p>\n
Die Langlebigkeit von Ops Toggles h\u00e4ngt von den jeweiligen Anwendungsf\u00e4llen 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.<\/strong> Beispielsweise sind Ops Toggles tendenziell relativ statisch, wenn sie nur mit einer Leistungskennzahl verbunden sind.<\/p>\nBeispiel f\u00fcr ein Ops Toggle<\/strong><\/p>\nUnser e-Commerce-Unternehmen bereitet sich auf eine Traffic-Spitze f\u00fcr den j\u00e4hrlichen Schlussverkauf vor. Das ist der erste Sale, bei dem der Konfigurator in der Produktion ist. W\u00e4hrend der Tests haben die Entwickler festgestellt, dass der vom User bevorzugte B-Algorithmus Systemressourcen stark beansprucht.<\/p>\n
Die Operators verlangten einen Kill Switch f\u00fcr 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.<\/p>\n
Permission Toggles<\/h3>\n
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.<\/strong> Beispielsweise k\u00f6nnen Sie ein Permission Toggle verwenden, um ausschlie\u00dflich 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\u00fcr eine oder einen UserIn getriggert werden.<\/p>\nBeispiel f\u00fcr ein Permission Toggle<\/strong><\/p>\nDas einfache Beispiel am Anfang dieses Artikels l\u00e4sst sich praktisch mit einem Permission Toggle vergleichen. Nach dem j\u00e4hrlichen 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:<\/p>\n
normalFeature = {<\/em>
\n‚id‘: 1,<\/em>
\n‚description‘: u’basic service‘,<\/em>
\n‚configurator‘: False<\/em>
\n}<\/em><\/p>\npremiumFeature = {<\/em>
\n‚id‘: 2,<\/em>
\n‚description‘: u’the better configurator‘,<\/em>
\n‚configurator‘: True<\/em>
\n}<\/em><\/p>\n@app.route(‚\/ourapp\/api\/v1.1\/storefront‘, methods=[‚GET‘])<\/em>
\ndef get_tasks():<\/em>
\nif premiumUser == True:<\/em>
\nreturn jsonify({‚feature‘: premiumFeature})<\/em>
\nelse:<\/em>
\nreturn jsonify({‚feature‘: normalFeature})<\/em><\/p>\nFeature Toggles vs. Feature Flags<\/strong><\/h2>\nEine kleine Randbemerkung: Es gibt einige Diskussionen \u00fcber den Begriff Feature Toggle verglichen zum Begriff Feature Flag. \u201eToggle\u201c trifft eher zu, wenn der Code bei mehreren Hauptzweigen des Codes ein- oder ausgeschaltet ist. \u201eFlag\u201c trifft eher zu, wenn auf einen Entscheidungspunkt multikonditionale oder eine gro\u00dfe Anzahl an Codepfaden folgen.<\/p>\n
Feature Toggles in Ihre Roadmap zur Unterst\u00fctzung agiler Workflows integrieren<\/strong><\/h2>\nMit Feature Toggles in Ihrem Entwicklungsprozess werden neuere agile Ans\u00e4tze<\/a> unterst\u00fctzt. Sie k\u00f6nnen eine Software ver\u00f6ffentlichen, w\u00e4hrend noch Code Sprints f\u00fcr neue Features bearbeitet werden. Diese Features m\u00fcssen lediglich hinter Toggles verborgen werden, bis sie f\u00fcr die Ver\u00f6ffentlichung, Marketingtests oder den n\u00e4chsten Schritt im Entwicklungsprozess tauglich sind.<\/p>\nIn der Regel w\u00fcrden Sie die k\u00fcrzlich vom User oder von der Userin gew\u00fcnschten Features auf Code-Verzweigungen unter einem eher herk\u00f6mmlichen Wasserfallmodell schreiben. Diese Features w\u00fcrden im Anschluss einen langen Test- und QA-Prozess durchlaufen, bevor Ihr Team die Features wieder in den Trunk Code zur\u00fcckf\u00fchren kann. Mit Feature Toggles k\u00f6nnen Sie den gesamten Entwicklungs- und Testprozess direkt auf dem Trunk Code durchf\u00fchren.<\/p>\n
Unsere Best Practices f\u00fcr die Verwendung von Feature Toggles<\/strong><\/h2>\nWie bereits erw\u00e4hnt, stehen Feature Toggles f\u00fcr eine leistungsstarke und flexible Entwicklungsmethode. Wenn Sie Ihre Toggles nicht sorgf\u00e4ltig implementieren und managen, k\u00f6nnen sie schnell eine chaotische Codebase erhalten.<\/p>\n
Es wurden viele verschiedene Best Practices zum Coden von Feature Toggles\u00a0 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\u00f6nnen Sie solche Probleme in Schach halten.<\/p>\n
![\"Website](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/code-5113374_1920-1024x683.jpg\")
<\/p>\n
Verwenden Sie Feature Toggles, um langsam zur agilen Entwicklung zu wechseln<\/h3>\n
Wenn Ihr Team agile Entwicklungs- und Testmethoden<\/a> ausprobieren m\u00f6chte, ohne sich v\u00f6llig in eine neue Entwicklungsmethode st\u00fcrzen zu m\u00fcssen, dann sind Feature Toggles in Ihrer Roadmap ein ausgezeichnetes Mittel f\u00fcr den Anfang. Die Kosten f\u00fcr diese Versuche sind gering. So k\u00f6nnte zum Beispiel zun\u00e4chst nur ein Team ein Experiment Toggle f\u00fcr einen ersten Canary Release verwenden.<\/p>\nWenn der Versuch gelingt, k\u00f6nnen Sie das Experiment Toggle durch ein Ops Toggle ersetzen, wenn das Feature in die Produktion geht.<\/strong> Dann weiten Sie die Nutzung des Toggles auf andere Teams oder Prozesse aus. F\u00fchren Sie dieses Toggle fr\u00fcher in die Entwicklungszyklen ein als Release Toggles. Dann sind Sie langsam aber sicher auf dem Weg zur v\u00f6llig agilen Entwicklung.<\/p>\nVerwenden Sie Toggles sowohl f\u00fcr interne als auch externe Features<\/h3>\n
Jetzt m\u00fcsste klar sein: Feature Toggles haben w\u00e4hrend des gesamten Entwicklungs- und Produktionslebenszyklus Ihrer Software Ihren Zweck. Schr\u00e4nken Sie die Toggle-Nutzung nicht auf Features ein, die nur von KundInnen gesehen werden. Sie k\u00f6nnen Release und Ops Toggles auch f\u00fcr 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\u00e4ndert werden, die einen entscheidenden Einfluss darauf haben, wie Ihr System performt.<\/p>\n
Lassen Sie die Toggle-Planung in Ihre Design-Phase einflie\u00dfen<\/h3>\n
Vom Toggle-Namen und den Konfigurationseinstellungen bis zum Entfernen der Toggles und der Zugangskontrolle \u2013 alles h\u00e4ngt davon ab, wie Sie neue Features gleich zu Beginn entwerfen. Bauen Sie diese Toggle-Planung in Ihren Designprozess ein und die n\u00e4chsten sechs Monate Ihres Feature Managements werden um einiges einfacher sein.<\/p>\n
Verwenden Sie ein standardisiertes Toggle Namensschema<\/h3>\n
Viele Unternehmen verwenden einen Style Guide f\u00fcr Entwickler, der festlegt, wie sie Code schreiben und organisieren sollen, wie sie zum Beispiel Abst\u00e4nde, Reihenfolge und Klammern beim Naming anwenden. Wenn Sie Feature Toggles verwenden wollen, sollten Sie auch den Naming-Stil schon fr\u00fchzeitig im Einf\u00fchrungsprozess Ihrer Toggles standardisieren.<\/p>\n
Kurz und b\u00fcndig zu sein, ist beim Coden f\u00fcr andere Aspekte wichtig. Wenn es aber um Toggle-Namen geht, seien Sie ausf\u00fchrlich. Details bedeuten Klarheit. Ausf\u00fchrliche Toggle Namen helfen Entwicklern und Ops Teams au\u00dferhalb Ihres Kernteams zu verstehen, was sie pr\u00fcfen,<\/strong> wenn ihr einziger Bezug der Toggle Name ist, den Sie sechs Monate zuvor aus einer Laune heraus gew\u00e4hlt haben.<\/p>\nEinige weitere Toggle-Namenskonventionen, die wir vorschlagen:<\/p>\n
\n- Binden Sie den Namen des Teams oder Projekts ein.<\/li>\n
- Binden Sie das Datum ein, an dem das Toggle erstellt wurde.<\/li>\n
- Identifizieren Sie die Kategorie des Flags.<\/li>\n
- Beschreiben Sie das tats\u00e4chliche Toggle-Verhalten.<\/li>\n<\/ul>\n
Hier ein Beispiel: algteam_10-12-2021_Ops_configurator-killswitch<\/em><\/p>\nDieser Name bietet einige n\u00fctzliche 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.<\/p>\n
Unterschiedliche Toggles unterschiedlich handhaben<\/h3>\n
Es scheint selbstverst\u00e4ndlich, ist aber ein wichtiger Punkt, den es hervorzuheben gilt. Wie wir bereits oben erw\u00e4hnt haben, k\u00f6nnen Feature Toggles in vier allgemeine Kategorien unterteilt werden. Sie sollten die einzelnen Kategorien unterschiedlich handhaben.<\/p>\n
Denken Sie an den oben erw\u00e4hnten Konfigurator, als er die Entwicklungsphase, dann Markttests und anschlie\u00dfend 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\u00e4ndert werden.<\/p>\n
Zu Beginn der Entwicklung kann das Toggle einfach in der Versionskontrolle konfiguriert werden. W\u00e4hrend das e-Commerce-Unternehmen A\/B-Tests durchf\u00fchrt, kann das Toggle auf einer Feature Management-Plattform sein. Wenn das Ops-Team einen Kill Switch hinzuf\u00fcgt, kann es sich entscheiden, es in derselben Feature Management-Plattform, aber auf einem anderen Dashboard zu lassen.<\/p>\n
![\"Feature](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/feature_management_feature_flag-1.svg\")
<\/a><\/p>\n
Einfach gesagt ist ein Feature Toggle ein leistungsstarkes \u201eIf\u201c-Statement, ab dem w\u00e4hrend der Laufzeit mindestens einem oder zwei verschiedenen Codepfaden abh\u00e4ngig von einer oder mehreren Bedingungen gefolgt wird. Hier ein konkretes Beispiel:<\/p>\n
normalFeature = {<\/em><\/span> testFeature = {<\/em><\/span> @app.route(‚\/ourapp\/api\/v1.1\/storefront‘, methods=[‚GET‘])<\/em><\/span> Hier haben wir zwei verschiedene generische Features definiert: normalFeature und testFeature. W\u00e4hrend der Laufzeit pr\u00fcft die Applikation in der Konfiguration, ob das Feature von einem oder einer interne(n) Test-UserIn geladen wird. Wenn ja, l\u00e4dt die Applikation das Test-Feature, das sich in der Entwicklung befindet. Wenn nicht, sieht der oder die \u201enormale\u201c KundIn das aktuelle Feature.<\/p>\n Feature Toggles k\u00f6nnen alles sein, ein einfaches \u201eIf\u201c-Statement oder komplexe Entscheidungsb\u00e4ume, die auf viele verschiedene Variablen einwirken.<\/strong> Um festzulegen, welche Richtung ein Toggle nehmen soll, k\u00f6nnen zahlreiche Bedingungen verwendet werden, u.\u00a0a.\u00a0Ergebnisse von Tauglichkeitstests aus anderen Features in der Codebase, eine Einstellung in der Feature Management Software oder eine Variable aus einer Konfig-Datei.<\/p>\n Gehen Sie mit Feature Toggles jeweils unterschiedlich um, je nachdem, wie Sie sie bereitstellen m\u00f6chten. Es kann n\u00fctzlich 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\u00f6nnen wir Feature Toggles in vier verschiedene Kategorien unterteilen:<\/p>\n Ein Diagramm der vier Kategorien der Feature Toggles (Quelle<\/a>)<\/span><\/p>\n Diese Toggles unterst\u00fctzen 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\u00e4hrend an ihm gearbeitet wird. Die Entwickler k\u00f6nnen den Trunk Code nach wie vor in die Produktion geben, um ihre Auslieferungsziele zu erf\u00fcllen.<\/p>\n Release Toggles sollen in der Regel kein fester Bestandteil<\/strong> Ihrer Codebase sein.<\/strong> Sobald das zugeh\u00f6rige Feature endg\u00fcltig 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.<\/p>\n Beispiel f\u00fcr ein Release Toggle<\/strong><\/p>\n Ein e-Commerce-Unternehmen entwickelt auf Anfrage eines hochkar\u00e4tigen Kunden eine neue Konfiguratorfunktion. Der Konfigurator \u00fcberwacht Artikel, die der Kunde bereits zus\u00e4tzlich ausgew\u00e4hlt hat, und schl\u00e4gt Artikel-Sets vor, um seine Bestellung abzurunden.<\/p>\n Das Unternehmen m\u00f6chte 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\u00fcr dieses neue Feature ein Release Toggle, das es inaktiv l\u00e4sst.<\/p>\n Diese Toggles werden verwendet, um A\/B-Tests<\/a> oder multivariable Tests einfacher zu machen. Sie erstellen einen Toggle Point, hinter dem zwei oder mehrere Codepfade mit den zu testenden Features liegen. W\u00e4hrend der Laufzeit teilt das System \u2013 oder das Toggle selbst \u2013 Nutzer in verschiedene Kohorten auf, an denen diese Features getestet werden.<\/p>\n Durch die Verfolgung aggregierter Experience-Daten bei jeder Kohorte k\u00f6nnen Sie die Wirkung der verschiedenen Features vergleichen.<\/strong> Experiment Toggles sind eine beliebte Methode f\u00fcr die Optimierung von Marketing-Initiativen, User Experiences<\/a> und anderer Features f\u00fcr UserInnen.<\/p>\n In der Regel sollten Experiment Toggles nur so lange existieren, bis keine Daten zum Feature-Testing mehr gesammelt werden m\u00fcssen. Der exakte Zeitrahmen h\u00e4ngt vom Traffic-Volumen bei diesem Feature ab, bel\u00e4uft sich aber in der Regel auf mehrere Wochen bis mehrere Monate. Diese Einschr\u00e4nkung 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\u00e4ften.<\/p>\n Beispiel f\u00fcr ein Experiment Toggle<\/strong><\/p>\n Unser e-Commerce-Unternehmen hat die Fehler in seinem neuen Konfigurator beseitigt. Aber es wird dar\u00fcber diskutiert, welcher der beiden Vorschlagsalgorithmen die beste Experience bietet. Man entschlie\u00dft sich f\u00fcr einen A\/B-Test, um Daten aus der realen Welt zu erhalten.<\/p>\n Das Unternehmen f\u00fcgt 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\u00fcltige Daten zu haben, die zeigen, dass mehr UserInnen ihre Bestellungen mit dem Algorithmus B abschlie\u00dfen. Das e-Commerce-Unternehmen entfernt das Experiment Toggle und der Algorithmus B wird f\u00fcr alle UserInnen live geschaltet.<\/p>\n Ops Toggles werden zum Abschalten von Features verwendet \u2013 wie ein \u201eKill Switch\u201c \u2013 oder um die Performance der Features anzupassen. Wenn zum Beispiel bestimmte Bedingungen nicht erf\u00fcllt 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\u00fcr die Programmierung neuer Features kurz nach dem Testing oder bei ressourcenintensiven Features n\u00fctzlich.<\/p>\n Die Langlebigkeit von Ops Toggles h\u00e4ngt von den jeweiligen Anwendungsf\u00e4llen 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.<\/strong> Beispielsweise sind Ops Toggles tendenziell relativ statisch, wenn sie nur mit einer Leistungskennzahl verbunden sind.<\/p>\n Beispiel f\u00fcr ein Ops Toggle<\/strong><\/p>\n Unser e-Commerce-Unternehmen bereitet sich auf eine Traffic-Spitze f\u00fcr den j\u00e4hrlichen Schlussverkauf vor. Das ist der erste Sale, bei dem der Konfigurator in der Produktion ist. W\u00e4hrend der Tests haben die Entwickler festgestellt, dass der vom User bevorzugte B-Algorithmus Systemressourcen stark beansprucht.<\/p>\n Die Operators verlangten einen Kill Switch f\u00fcr 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.<\/p>\n 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.<\/strong> Beispielsweise k\u00f6nnen Sie ein Permission Toggle verwenden, um ausschlie\u00dflich 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\u00fcr eine oder einen UserIn getriggert werden.<\/p>\n Beispiel f\u00fcr ein Permission Toggle<\/strong><\/p>\n Das einfache Beispiel am Anfang dieses Artikels l\u00e4sst sich praktisch mit einem Permission Toggle vergleichen. Nach dem j\u00e4hrlichen 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:<\/p>\n normalFeature = {<\/em> premiumFeature = {<\/em> @app.route(‚\/ourapp\/api\/v1.1\/storefront‘, methods=[‚GET‘])<\/em> Eine kleine Randbemerkung: Es gibt einige Diskussionen \u00fcber den Begriff Feature Toggle verglichen zum Begriff Feature Flag. \u201eToggle\u201c trifft eher zu, wenn der Code bei mehreren Hauptzweigen des Codes ein- oder ausgeschaltet ist. \u201eFlag\u201c trifft eher zu, wenn auf einen Entscheidungspunkt multikonditionale oder eine gro\u00dfe Anzahl an Codepfaden folgen.<\/p>\n Mit Feature Toggles in Ihrem Entwicklungsprozess werden neuere agile Ans\u00e4tze<\/a> unterst\u00fctzt. Sie k\u00f6nnen eine Software ver\u00f6ffentlichen, w\u00e4hrend noch Code Sprints f\u00fcr neue Features bearbeitet werden. Diese Features m\u00fcssen lediglich hinter Toggles verborgen werden, bis sie f\u00fcr die Ver\u00f6ffentlichung, Marketingtests oder den n\u00e4chsten Schritt im Entwicklungsprozess tauglich sind.<\/p>\n In der Regel w\u00fcrden Sie die k\u00fcrzlich vom User oder von der Userin gew\u00fcnschten Features auf Code-Verzweigungen unter einem eher herk\u00f6mmlichen Wasserfallmodell schreiben. Diese Features w\u00fcrden im Anschluss einen langen Test- und QA-Prozess durchlaufen, bevor Ihr Team die Features wieder in den Trunk Code zur\u00fcckf\u00fchren kann. Mit Feature Toggles k\u00f6nnen Sie den gesamten Entwicklungs- und Testprozess direkt auf dem Trunk Code durchf\u00fchren.<\/p>\n Wie bereits erw\u00e4hnt, stehen Feature Toggles f\u00fcr eine leistungsstarke und flexible Entwicklungsmethode. Wenn Sie Ihre Toggles nicht sorgf\u00e4ltig implementieren und managen, k\u00f6nnen sie schnell eine chaotische Codebase erhalten.<\/p>\n Es wurden viele verschiedene Best Practices zum Coden von Feature Toggles\u00a0 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\u00f6nnen Sie solche Probleme in Schach halten.<\/p>\n Wenn Ihr Team agile Entwicklungs- und Testmethoden<\/a> ausprobieren m\u00f6chte, ohne sich v\u00f6llig in eine neue Entwicklungsmethode st\u00fcrzen zu m\u00fcssen, dann sind Feature Toggles in Ihrer Roadmap ein ausgezeichnetes Mittel f\u00fcr den Anfang. Die Kosten f\u00fcr diese Versuche sind gering. So k\u00f6nnte zum Beispiel zun\u00e4chst nur ein Team ein Experiment Toggle f\u00fcr einen ersten Canary Release verwenden.<\/p>\n Wenn der Versuch gelingt, k\u00f6nnen Sie das Experiment Toggle durch ein Ops Toggle ersetzen, wenn das Feature in die Produktion geht.<\/strong> Dann weiten Sie die Nutzung des Toggles auf andere Teams oder Prozesse aus. F\u00fchren Sie dieses Toggle fr\u00fcher in die Entwicklungszyklen ein als Release Toggles. Dann sind Sie langsam aber sicher auf dem Weg zur v\u00f6llig agilen Entwicklung.<\/p>\n Jetzt m\u00fcsste klar sein: Feature Toggles haben w\u00e4hrend des gesamten Entwicklungs- und Produktionslebenszyklus Ihrer Software Ihren Zweck. Schr\u00e4nken Sie die Toggle-Nutzung nicht auf Features ein, die nur von KundInnen gesehen werden. Sie k\u00f6nnen Release und Ops Toggles auch f\u00fcr 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\u00e4ndert werden, die einen entscheidenden Einfluss darauf haben, wie Ihr System performt.<\/p>\n Vom Toggle-Namen und den Konfigurationseinstellungen bis zum Entfernen der Toggles und der Zugangskontrolle \u2013 alles h\u00e4ngt davon ab, wie Sie neue Features gleich zu Beginn entwerfen. Bauen Sie diese Toggle-Planung in Ihren Designprozess ein und die n\u00e4chsten sechs Monate Ihres Feature Managements werden um einiges einfacher sein.<\/p>\n Viele Unternehmen verwenden einen Style Guide f\u00fcr Entwickler, der festlegt, wie sie Code schreiben und organisieren sollen, wie sie zum Beispiel Abst\u00e4nde, Reihenfolge und Klammern beim Naming anwenden. Wenn Sie Feature Toggles verwenden wollen, sollten Sie auch den Naming-Stil schon fr\u00fchzeitig im Einf\u00fchrungsprozess Ihrer Toggles standardisieren.<\/p>\n Kurz und b\u00fcndig zu sein, ist beim Coden f\u00fcr andere Aspekte wichtig. Wenn es aber um Toggle-Namen geht, seien Sie ausf\u00fchrlich. Details bedeuten Klarheit. Ausf\u00fchrliche Toggle Namen helfen Entwicklern und Ops Teams au\u00dferhalb Ihres Kernteams zu verstehen, was sie pr\u00fcfen,<\/strong> wenn ihr einziger Bezug der Toggle Name ist, den Sie sechs Monate zuvor aus einer Laune heraus gew\u00e4hlt haben.<\/p>\n Einige weitere Toggle-Namenskonventionen, die wir vorschlagen:<\/p>\n Hier ein Beispiel: algteam_10-12-2021_Ops_configurator-killswitch<\/em><\/p>\n Dieser Name bietet einige n\u00fctzliche 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.<\/p>\n Es scheint selbstverst\u00e4ndlich, ist aber ein wichtiger Punkt, den es hervorzuheben gilt. Wie wir bereits oben erw\u00e4hnt haben, k\u00f6nnen Feature Toggles in vier allgemeine Kategorien unterteilt werden. Sie sollten die einzelnen Kategorien unterschiedlich handhaben.<\/p>\n Denken Sie an den oben erw\u00e4hnten Konfigurator, als er die Entwicklungsphase, dann Markttests und anschlie\u00dfend 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\u00e4ndert werden.<\/p>\n Zu Beginn der Entwicklung kann das Toggle einfach in der Versionskontrolle konfiguriert werden. W\u00e4hrend das e-Commerce-Unternehmen A\/B-Tests durchf\u00fchrt, kann das Toggle auf einer Feature Management-Plattform sein. Wenn das Ops-Team einen Kill Switch hinzuf\u00fcgt, kann es sich entscheiden, es in derselben Feature Management-Plattform, aber auf einem anderen Dashboard zu lassen.<\/p>\n
\n‚id‘: 1,<\/em><\/span>
\n‚description‘: u’basic service‘,<\/em><\/span>
\n’newstuff‘: False<\/em><\/span>
\n}<\/em><\/span><\/p>\n
\n‚id‘: 2,<\/em><\/span>
\n‚description‘: u’much better service‘,<\/em><\/span>
\n’newstuff‘: True<\/em><\/span>
\n}<\/em><\/span><\/p>\n
\ndef get_tasks():<\/em><\/span>
\nif internalTester == True:<\/em><\/span>
\nreturn jsonify({‚feature‘: testFeature})<\/em><\/span>
\nelse:<\/em><\/span>
\nreturn jsonify({‚feature‘: normalFeature})<\/em><\/span><\/p>\nVerschiedene Feature Toggles f\u00fcr verschiedene Aufgaben<\/strong><\/h2>\n
\n
<\/p>\nRelease Toggles<\/h3>\n
Experiment Toggles<\/h3>\n
Ops Toggles<\/h3>\n
Permission Toggles<\/h3>\n
\n‚id‘: 1,<\/em>
\n‚description‘: u’basic service‘,<\/em>
\n‚configurator‘: False<\/em>
\n}<\/em><\/p>\n
\n‚id‘: 2,<\/em>
\n‚description‘: u’the better configurator‘,<\/em>
\n‚configurator‘: True<\/em>
\n}<\/em><\/p>\n
\ndef get_tasks():<\/em>
\nif premiumUser == True:<\/em>
\nreturn jsonify({‚feature‘: premiumFeature})<\/em>
\nelse:<\/em>
\nreturn jsonify({‚feature‘: normalFeature})<\/em><\/p>\nFeature Toggles vs. Feature Flags<\/strong><\/h2>\n
Feature Toggles in Ihre Roadmap zur Unterst\u00fctzung agiler Workflows integrieren<\/strong><\/h2>\n
Unsere Best Practices f\u00fcr die Verwendung von Feature Toggles<\/strong><\/h2>\n
<\/p>\nVerwenden Sie Feature Toggles, um langsam zur agilen Entwicklung zu wechseln<\/h3>\n
Verwenden Sie Toggles sowohl f\u00fcr interne als auch externe Features<\/h3>\n
Lassen Sie die Toggle-Planung in Ihre Design-Phase einflie\u00dfen<\/h3>\n
Verwenden Sie ein standardisiertes Toggle Namensschema<\/h3>\n
\n
Unterschiedliche Toggles unterschiedlich handhaben<\/h3>\n
<\/a><\/p>\n
![\"Developer](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/employee-4604126_1920-1024x680.jpg\")