Implementarea este atunci când codul ajunge în producție. Eliberarea este atunci când cineva o poate folosi efectiv. Confuzia celor două este una dintre cele mai rapide modalități de a face din fiecare implementare un moment puțin tensionat.
feature flag servesc pentru a pune spațiu între aceste două momente. Puteți implementa astăzi, puteți activa mâine pentru echipa internă, apoi pentru un client pilot, apoi pentru 10% dintre utilizatori. Dacă ceva nu merge bine, opriți steagul. Nu trebuie neapărat să anulați întreaga versiune.
Steagul nu este doar un dacă
Din punct de vedere tehnic, este adesea un if. Cultural este mult mai mult.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Acel mic if poate reprezenta o lansare treptată, un experiment, o migrare, un permis de întreprindere sau un kill switch operațional. Problema este că dacă nu o gestionezi bine, poate deveni și datorie tehnică care rămâne în cod doi ani.
Unde intervine OpenFeature
OpenFeature este o specificație deschisă pentru evaluarea feature flag cu un API comun. Ideea este simplă: codul aplicației dvs. nu ar trebui să depindă direct de furnizor sau de sistemul intern pe care îl utilizați pentru steaguri.
Aplicația întreabă:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Furnizorul decide de unde provin regulile: SaaS, fișier, serviciu intern, flagd, configurație GitOps. Dacă într-o zi schimbați backend-ul de semnalizare a caracteristicilor, aplicația nu trebuie să fie rescrisă peste tot.
Această separare pare un detaliu arhitectural, dar se simte pe măsură ce proiectul crește.
Contextul este jumătate din bătălie
Un steag pornit sau oprit pentru toată lumea este util, dar limitat. Livrarea progresivă trăiește în context:
- utilizator intern sau extern;
- plan gratuit sau de întreprindere;
- sat;
- organizare;
- versiunea aplicației;
- procent stabil de trafic.
Cheia importantă este targetingKey: trebuie să fie stabilă. Dacă se schimbă la fiecare solicitare, un utilizator poate ajunge o dată în varianta A și o dată în varianta B. Pentru un experiment este groaznic, pentru un checkout poate fi dezastruos.
O lansare sensibilă
Un flux care îmi place este acesta:
- desfășurare cu flag off;
- aprindere pentru dezvoltatori și QA;
- pornire pentru un client pilot sau chiriaș;
- 5% lansare;
- lansare la 25%;
- lansare 100%;
- eliminarea vechiului cod și steag.
Punctul adesea uitat este ultimul. Un steag temporar trebuie să aibă o dată de deces. Dacă rămâne pentru totdeauna, fiecare viitor refactor va trebui să se întrebe: „dar mai este utilă această ramură?”.
Kill switch: pregătiți-le mai întâi
kill switch este indicatorul care te salvează atunci când o dependență externă începe să te încurce, un job consumă prea multe resurse sau o nouă logică produce erori ciudate.
Un kill switch bun trebuie să fie:
- usor de gasit;
- documentat în runbook;
- testat ocazional;
- observabil când este activat;
- independent, pe cât posibil, de partea care s-ar putea rupe.
Cel mai rău este să descoperi în timpul accidentului că steagul există, dar nimeni nu știe dacă mai funcționează.
Observabilitate sau nu livrare progresivă
Activarea unei funcții la 10% fără să se uite la valori este doar optimism cu mai mulți pași.
Fiecare lansare ar trebui să răspundă la întrebări simple:
- au crescut erorile?
- s-a schimbat latența?
- utilizatorii completează fluxul?
- există mai multe bilete sau reîncercări?
- o variantă afectează doar un segment?
OpenFeature acceptă cârlige în jurul evaluării steagului. Sunt utile pentru înregistrarea erorilor, adăugarea de valori sau legarea evaluării la un trace.
Denumirea și proprietatea
Numele contează. new_ui nu spune nimic. checkout.v2.enabled spune mult mai multe.
Pentru fiecare steag aș marca cel puțin:
- nume;
- descriere;
- proprietar;
- implicit sigur;
- motivul pentru care există;
- data sau starea înlăturării.
Un steag fără proprietar este aproape întotdeauna un steag pe care nimeni nu îl va șterge.
Unde să le evaluăm
Frontend, backend sau edge? Depinde.
Dacă marcajul este pentru aspect, copiere sau onboarding, interfața este în regulă. Dacă se referă la permisiuni, facturare, limite sau date sensibile, trebuie să fie pe backend. Dacă implică rutare sau experimente cu trafic ridicat, marginea poate avea sens.
Regula simplă: frontend-ul poate îmbunătăți experiența, dar nu ar trebui să fie singura barieră de securitate.
Concluzie
feature flag bine făcut schimbă relația cu producția. Ele nu elimină riscul, dar îl fac mai mic și mai ușor de gestionat. Poți să eliberezi în felii, să observi, să te oprești, să te întorci, să înveți.
OpenFeature adaugă o bază curată: un API obișnuit, furnizori interschimbabili și o modalitate mai ordonată de a dezvolta sistemul. Dar disciplina rămâne a ta: valori implicite sigure, nume clare, valori, proprietari și curățenie.
Cel mai bun steag este cel care te ajută să te eliberezi calm și apoi dispare când nu mai este nevoie.