Az üzembe helyezés az, amikor a kód megérkezik az éles rendszerbe. A kiadás az, amikor valaki ténylegesen használhatja. A kettő összekeverése az egyik leggyorsabb módja annak, hogy minden telepítést egy kicsit feszült pillanatokká varázsoljunk.
A feature flag arra szolgál, hogy helyet tegyen e két pillanat közé. Ma telepítheti, holnap elindíthatja a belső csapatot, majd egy kísérleti ügyfélnél, majd a felhasználók 10%-ánál. Ha valami elromlik, kapcsolja ki a zászlót. Nem feltétlenül kell visszaállítania a teljes kiadást.
A zászló nem csak egy ha
Technikailag gyakran if. Kulturálisan ez sokkal több.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Ez a kis if jelenthet fokozatos bevezetést, kísérletet, migrációt, vállalkozási engedélyt vagy működési kill switch-t. A probléma az, hogy ha nem jól kezeled, akkor technikai adósság is lehet belőle, ami két évig a kódban marad.
Hol jön be az OpenFeature?
A OpenFeature egy nyílt specifikáció a feature flag kiértékeléséhez egy közös API-vel. Az ötlet egyszerű: az alkalmazás kódja nem függhet közvetlenül a jelzőkhöz használt szállítótól vagy belső rendszertől.
Az alkalmazás megkérdezi:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
A szolgáltató dönti el, honnan származnak a szabályok: SaaS, fájl, belső szolgáltatás, megjelölt, GitOps konfiguráció. Ha egy nap megváltoztatja a funkciójelző háttérrendszert, az alkalmazást nem kell mindenhol átírni.
Ez az elválasztás építészeti részletnek tűnik, de a projekt növekedésével érezhető.
A kontextus fél siker
A be- vagy kikapcsolási jelző mindenki számára hasznos, de korlátozott. A progresszív szállítás a következő összefüggésekben él:
- belső vagy külső felhasználó;
- ingyenes vagy vállalati csomag;
- falu;
- szervezés;
- az alkalmazás verziója;
- stabil százalékos forgalom.
A fontos kulcs a targetingKey: stabilnak kell lennie. Ha minden kéréssel változik, a felhasználó egyszer az A változatba, egyszer pedig a B változatba kerülhet. Egy kísérletnél ez szörnyű, egy fizetésnél katasztrofális lehet.
Ésszerű bevezetés
Egy áramlás, amit szeretek, ez:
- telepítés kikapcsolt jelzővel;
- gyújtás a fejlesztőknek és a minőségbiztosításnak;
- bekapcsolás kísérleti ügyfél vagy bérlő számára;
- 5%-os bevezetés;
- 25%-os bevezetés;
- 100%-os bevezetés;
- a régi kód és zászló eltávolítása.
A gyakran elfelejtett pont az utolsó. Az ideiglenes zászlónak tartalmaznia kell a halál dátumát. Ha ez örökre megmarad, minden leendő refaktornak meg kell kérdeznie: "de hasznos-e még ez az ág?".
Kill switch: először készítse elő őket
A kill switch az a jelző, amely megmenti Önt, ha egy külső függőség zavarja Önt, egy feladat túl sok erőforrást fogyaszt, vagy az új logika furcsa hibákat produkál.
A jó kill switch-nek a következőnek kell lennie:
- könnyen megtalálható;
- a runbookban dokumentálva;
- alkalmanként tesztelve;
- aktivált állapotban megfigyelhető;
- lehetőség szerint független attól a résztől, amely eltörhet.
A legrosszabb az, ha a baleset során felfedezzük, hogy a zászló létezik, de senki sem tudja, működik-e még.
Megfigyelhetőség vagy nem progresszív szállítás
Egy funkció 10%-os bekapcsolása a mutatók megtekintése nélkül csak optimizmus, több lépéssel.
Minden kiadásnak meg kell válaszolnia az egyszerű kérdéseket:
- nőtt a hibák száma?
- változott a késleltetés?
- a felhasználók befejezik a folyamatot?
- van több jegy vagy próbálkozás?
- egy változat csak egy szegmenst érint?
A OpenFeature támogatja a zászlóértékelés körüli horgokat. Hasznosak a hibák naplózásához, mérőszámok hozzáadásához vagy az értékelés trace-hez való kapcsolásához.
Elnevezés és tulajdonjog
A nevek számítanak. new_ui nem mond semmit. checkout.v2.enabled sokkal többet mond.
Minden zászlónál legalább a következőket jelölném:
- név;
- leírás;
- tulajdonos;
- biztonságos alapértelmezett;
- a létezés oka;
- az eltávolítás dátuma vagy feltétele.
A gazdátlan zászló szinte mindig olyan zászló, amelyet senki sem fog letörölni.
Hol kell értékelni őket
Frontend, backend vagy edge? attól függ.
Ha a zászló az elrendezésre, a másolásra vagy a beépítésre vonatkozik, az előtér rendben van. Ha engedélyekre, számlázásra, korlátokra vagy bizalmas adatokra vonatkozik, akkor a háttérben kell lennie. Ha ez útválasztást vagy nagy forgalmú kísérleteket foglal magában, az élnek lehet értelme.
Az egyszerű szabály: a frontend javíthatja az élményt, de nem ez lehet az egyetlen biztonsági akadály.
Következtetés
A jól sikerült feature flag megváltoztatja a termeléshez való viszonyt. Nem szüntetik meg a kockázatot, de kisebbé és kezelhetőbbé teszik. Lehet szeletekben elengedni, megfigyelni, megállni, visszamenni, tanulni.
Az OpenFeature tiszta alapot ad: egy közös API, cserélhető szolgáltatókat és egy rendezettebb módszert a rendszer bővítésére. De a fegyelem a tiéd marad: biztonságos alapértelmezések, egyértelmű nevek, mutatók, tulajdonosok és tisztaság.
A legjobb zászló az, amely segít nyugodtan elengedni, majd eltűnik, amikor már nincs rá szükség.