Written by Tak jaké šaty jsou lepší? Broskvové, meruňkové nebo oranžové? Volba je těžká a zásadní a v tomto případě, protože mezi těmito barvami asi neumím poznat rozdíl, bude rozhodnutí lépe přenechat někomu jinému. Komu? Vašim uživatelům.
A/B testování
Obecně jde o princip, kdy máte dvě možné varianty a chcete v praxi vyzkoušet obě dvě tak, že nějakým náhodným procesem někdy použijete A, jindy B a shromáždíte zpětnou vazbu. U aplikací může jít například o A coby aktuální verzi aplikace a B jako verze s novou nebo změněnou funkcí. Testování bude o tom, že například 10% přístupů bude aplikace servírovat funkce B. Chcete to ale udělat tak, že uživatel to nijak nepozná – tedy k aplikaci přistupuje stále stejně, na stejné adrese, jen najednou vidí třeba tlačítko navíc. Nebo možná A bude původní verze, B s tlačítkem vlevo a C s tlačítkem vpravo. Následně vyhodnotíte výsledky – třeba statistiky z GUI (kliknutí, pohyb myší), výkonnostní ukazatele nebo vyjádření uživatelů.
Jak ale provádět A/B testování produkční aplikace za plného provozu?
Helion Development Platform a routing pro A/B testování
V on-premise PaaS jako je Helion Development Platform postavené na Cloud Foundry, Stackato a Docker je to snadné, protože platforma se stará o provoz instancí aplikace (vytvoří obsah Docker image a řídí jeho život) a má v sobě balancer na jednotlivé instance. Nejprve tedy nahrajete B verzi jako novou aplikaci, která ve výchozím stavu poběží na své vlastní URL:
Verzi A necháme běžet třeba v pěti instancích (stačí použít posuvník a platforma sama vytvoří aplikační prostředí, kontejner, zprovozní a začlení do balancingu):
Pak přidáme B verzi aplikace do balancovací skupiny pro naší A verzi – 1 ze 6 přístupů tak bude obsloužen B instancí:
Jednoduché, že? Pro tradiční přístup k IT a aplikacím by něco takového v produkci bylo buď nemyslitelné nebo záležitostí několika měsíců. V moderním pojetí s využitím Platform as a Service je to ale hračka.
Podívejte se na to ve videu s českým komentářem, kde to máte celé:
