A/B-Tests als Code versionieren

In vielen Unternehmen entsteht der Code von A/B-Tests in einem Textfeld im Browser. Jemand schreibt JavaScript und CSS direkt in die Oberfläche des Experimentier-Werkzeugs, speichert und startet den Test. Dieser Code läuft danach bei einem Teil der Kundschaft in der Produktion, im Checkout, auf der Zahlungsseite.

Er hat kein Review gesehen, keine Historie und keinen Bezug zu einem Ticket. Für jeden anderen Code in der Produktion wäre das undenkbar.

Die Idee

Ich habe ein kleines Kommandozeilenwerkzeug geschrieben, das den Code jeder Variante als Dateien im Repository ablegt und mit dem Experimentier-Werkzeug abgleicht. Es hat vier Befehle:

abtest init SHOP-123 4711   # Experiment einem Ticket zuordnen, Dateien anlegen
abtest pull                 # Stand aus dem Werkzeug ins Repository holen
abtest push --dry-run       # zeigen, was hochgeladen würde
abtest preview              # Vorschau-Links je Variante ausgeben

Damit gilt für A/B-Tests derselbe Weg wie für jeden anderen Code: Branch, Pull Request, Review, Merge. Die Vorschau-Links stehen im Pull Request, sodass die Variante angesehen werden kann, bevor sie jemand freigibt.

Was das Werkzeug absichtlich nicht kann

Ein Werkzeug, das in ein Produktivsystem schreibt, braucht Grenzen. Diese hier habe ich fest eingebaut:

• Es startet nie ein Experiment und veröffentlicht nie eines. Hochgeladen wird nur als Entwurf. Den Start macht weiterhin ein Mensch in der Oberfläche.
• Es lehnt fremde Projekte ab. Gehört ein Experiment zu einem anderen Projekt als dem konfigurierten, bricht der Befehl ab.
• Es schreibt nur in bearbeitbare Zustände. Ein laufendes Experiment bleibt unangetastet.

Der vergessene Doppelstrich

Die lehrreichste Stelle war eine Kleinigkeit. Wer das Werkzeug über ein Paket-Skript startet, muss Optionen hinter einem Doppelstrich übergeben:

npm run abtest push -- --dry-run   # richtig
npm run abtest push --dry-run      # die Option kommt nie an

Im zweiten Fall verschluckt der Paketmanager die Option. Das Werkzeug sieht einen ganz normalen push und lädt hoch, obwohl die Person nur nachsehen wollte. Genau der Befehl, der Sicherheit geben soll, wird so zur Falle.

Das Werkzeug erkennt diesen Fall jetzt und bricht ab, statt zu schreiben. Die Lehre daraus gilt für jedes Werkzeug mit Trockenlauf: Der sichere Weg muss der sein, der bei einem Tippfehler herauskommt.

Was sich dadurch ändert

• Experimente sind nachvollziehbar. Im Git-Verlauf steht, wer welche Variante wann geändert hat und zu welchem Ticket sie gehört.
• Varianten lassen sich wiederverwenden. Ein erfolgreicher Test wird zur Vorlage für den nächsten, statt in einem abgeschlossenen Experiment zu verschwinden.
• Gewinner wandern leichter in den Code. Wenn eine Variante gewinnt, liegt ihr Code schon dort, wo die dauerhafte Umsetzung entsteht.
• Tests gelten auch hier. Das Werkzeug selbst hat eine feste Schwelle für die Testabdeckung von 80 %.

Für wen sich das lohnt

Wenn Ihr Team zwei Experimente im Jahr fährt, reicht das Textfeld. Sobald Experimente regelmäßig laufen und mehrere Personen daran arbeiten, lohnt sich der Abgleich mit dem Repository und spart die erste unangenehme Überraschung in der Produktion.