Wie kann man Entwickler davon überzeugen, Feature-Flag-Schalter zu verwenden?

Angenommen, das Umschalten der Feature-Flags ist eine gute Idee und sollte in Code implementiert werden, den Entwickler schreiben. Zum Beispiel schwört Etsy auf sie als einen wichtigen Teil ihrer Kultur .

Was ist ein guter Weg, um Entwickler davon zu überzeugen (und zu erzwingen), Feature-Flag-Schalter zu verwenden?

Weitere Informationen zum Umschalten von Feature-Flags finden Sie in F: Verwendung von Feature-Flags , F: Was sind Feature-Flags und was ist sehr ausführlich in Pete Hodgsons Artikel zu diesem Thema in Martin Fowlers Blog .

Feature-Toggles sind eine gängige Praxis in der Hochgeschwindigkeitsentwicklung, da sie die Entwicklung von der Freigabe entkoppeln. Entwicklerteams können ein neues Feature für die Produktion in einem deaktivierten Zustand "soft-release". Dadurch kann die Funktion jederzeit freigegeben werden. Wenn die Funktion von anderen Arbeiten oder Vorbereitungen abhängig ist, muss sie nicht auf die Serienreife einer Hauptversion warten.

Soweit Entwickler davon überzeugt werden, sie zu verwenden, ist dies eine Übung, um die Freiheit, die sie bieten, geltend zu machen. Ich habe die Erfahrung gemacht, dass es für Entwickler kein schwerer Verkauf ist. Das Management neigt dazu, neue Dinge nur ungern auszuprobieren. Versuche dies:

• Suchen Sie ein Feature-Toggle-Framework. Das Management / das Unternehmen ist möglicherweise eher dazu geneigt, etwas auszuprobieren, das von einem gemeinsamen System unterstützt wird
• Fangen Sie klein an. Stellen Sie das Umschaltsystem auf Probebasis für eine Funktion vor, die seine Nützlichkeit demonstriert.
• Demonstrieren Sie die Fähigkeit des Toggles, A / B-Tests durchzuführen. Aktivieren Sie das Umschalten für eine Teilmenge Ihrer Webfarm, und erfassen Sie dann Kennzahlen zum Verhalten. Es hat sich gezeigt, dass winzige Unterschiede im Seitenlayout enorme Auswirkungen auf den Umsatz von Einzelhandelsanwendungen haben (z. B. Ebay, Amazon).

In einer idealen Welt, denke ich, bringen Sie einen neuen Build heraus und überraschen Sie! Nichts verändert sich. Dies liegt daran, dass sich alle Ihre neuen Funktionen hinter Schaltern befinden, die bei ausgeschaltetem Schalter ausgehen.

Nach der Bereitstellung stellen Sie sicher, dass Ihr ausgerollter Dienst weiterhin funktioniert, die Telefone nicht mehr klingeln (es sei denn, das Klingeln ist Ihr Zweck) usw. Sobald Sie zu einem bekannten stabilen Betrieb zurückgekehrt sind, beginnen Sie mit der Aktivierung und Überprüfung Ihre neu bereitgestellten Funktionen.

Nun zu Ihrer Antwort: Wie möchten Sie in einem Team arbeiten, in dem Bereitschaft praktisch ein Kinderspiel ist und unsere Benutzer uns lieben, weil unsere Websites und Dienste absolut stabil sind?

Daran möchte ich arbeiten.

Sie können hier aufhören zu lesen, wenn Sie möchten.

Wenn Sie alles hinter einen Funktionsschalter stellen, kann dies überall zu Spaghetti-Code führen. Wenn Sie IoC verwenden und in der Lage sind, zwischen vNow / vNext / vPrevious zu wählen, kommt es darauf an, Ihre Konfiguration beizubehalten. Ja, mehr Check-Ins, ja, mehr Klassen (KomponenteV1, KomponenteV2, KomponenteV3 usw.), aber Sie haben tatsächlich ein stabileres System? Wie? vWeiter ist Wonky? Wechseln Sie mit Ihrem Kontrollturm zurück zu vNow. Schon eine Woche und vNow hat einen subtilen Fehler? Das Gleiche gilt - kehren Sie genauso einfach zu vPrevious zurück.

Kein Ärger, keine Sorgen, kein Schlafverlust, kein Stress.

Das ist kein Wunschtraum. Ich habe dort gearbeitet. Ich wünschte, ich könnte dies an mein aktuelles Team verkaufen.

Eine erfolgreiche Hochgeschwindigkeits-Entwicklungsumgebung basiert in der Regel auf einem recht strengen automatisierten System, das Qualitätsprüfungen mit Erkennung und Zurückweisung fehlerhafter Änderungen, die zu Regressionen führen, umfasst.

Feature-Toggles bieten die Möglichkeit, selbst in Bearbeitung befindliche, nicht getestete Änderungen festzuschreiben, ohne dass sie aufgrund von Regressionen im Integrationszweig abgelehnt werden. Dies ist ein sehr guter Anreiz , die Funktionsumschaltungen sehr früh im Leben der Funktion einzuführen.

Einer der Nachteile der Abweichung von der tatsächlichen CI und der Entwicklung sich bewegender Merkmale in Merkmalzweigen ist das Fehlen eines solchen Anreizes. Das spätere Hinzufügen des Feature-Toggles beim Zusammenführen des Feature-Zweigs mit dem Integrationszweig ist normalerweise schwieriger, wie bei jeder späten Integration.

Entwickler (und normalerweise Entwicklungsmanager) suchen in der Regel nach zwei mit dem Framework verbundenen Ergebnissen: Einfachheit der Verwaltung und Geschwindigkeit der Bereitstellung. Sie möchten Code schneller und einfacher versenden.

Den Nachweis erbringen, dass der Ansatz funktioniert; Versuchen Sie, einen kleinen POC mithilfe von Feature-Flags im Vergleich zur alten Methode zu erstellen. Fallstudien sind für taktische Leute (Entwickler / Ingenieure) weniger wichtig als für strategische Leute (mittleres Management / Produktdesigner).

Die Begründung für das Umschalten von Funktionen liegt nicht bei den Entwicklern. Dies ist etwas, das den Produktbesitzern wichtig ist. Entwickler ermöglichen diese Änderung auf die nachhaltigste und sicherste Weise. Ich kritisiere genau diese Frage.