Ang deployment ay kapag dumating ang code sa produksyon. Ang paglabas ay kapag ang isang tao ay talagang magagamit ito. Ang pagkalito sa dalawa ay isa sa pinakamabilis na paraan para gawing medyo tense ang bawat deployment.
Ang feature flag ay nagsisilbing maglagay ng espasyo sa pagitan ng dalawang sandaling ito. Maaari kang mag-deploy ngayon, paganahin bukas para sa internal na team, pagkatapos ay para sa isang pilot na customer, pagkatapos ay para sa 10% ng mga user. Kung may mali, patayin ang bandila. Hindi mo kailangang i-rollback ang buong release.
Ang watawat ay hindi lamang kung
Sa teknikal, ito ay madalas na isang if. Sa kultura ito ay higit pa.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Ang maliit na if na iyon ay maaaring kumatawan sa isang unti-unting paglulunsad, isang eksperimento, isang migration, isang enterprise permit o isang operational kill switch. Ang problema ay kung hindi mo ito mapangasiwaan nang maayos, maaari rin itong maging teknikal na utang na mananatili sa code sa loob ng dalawang taon.
Saan pumapasok ang OpenFeature
Ang OpenFeature ay isang bukas na detalye para sa pagsusuri sa feature flag na may karaniwang API. Ang ideya ay simple: ang iyong application code ay hindi dapat nakadepende nang direkta sa vendor o panloob na sistema na ginagamit mo para sa mga flag.
Ang app ay nagtatanong:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Ang provider ang magpapasya kung saan nagmumula ang mga panuntunan: SaaS, file, panloob na serbisyo, na-flag, configuration ng GitOps. Kung isang araw ay babaguhin mo ang tampok na pag-flag ng backend, ang application ay hindi kailangang muling isulat sa lahat ng dako.
Ang paghihiwalay na ito ay tila isang detalye ng arkitektura, ngunit ito ay nararamdaman habang lumalaki ang proyekto.
Ang konteksto ay kalahati ng labanan
Ang isang on o off na flag para sa lahat ay kapaki-pakinabang, ngunit limitado. Ang progresibong paghahatid ay nabubuhay sa konteksto:
- panloob o panlabas na gumagamit;
- libre o plano ng negosyo;
- nayon;
- organisasyon;
- bersyon ng app;
- matatag na porsyento ng trapiko.
Ang mahalagang susi ay targetingKey: dapat itong maging matatag. Kung magbabago ito sa bawat kahilingan, ang isang user ay maaaring mapunta nang isang beses sa variant A at isang beses sa variant B. Para sa isang eksperimento, ito ay kakila-kilabot, para sa isang pag-checkout maaari itong maging nakapipinsala.
Isang makabuluhang paglulunsad
Ang isang daloy na gusto ko ay ito:
- deploy na may flag off;
- pag-aapoy para sa mga developer at QA;
- switch-on para sa isang pilot na customer o nangungupahan;
- 5% na paglulunsad;
- rollout sa 25%;
- 100% na paglulunsad;
- pag-alis ng lumang code at bandila.
Ang madalas na nakakalimutang punto ay ang huli. Ang isang pansamantalang bandila ay dapat may petsa ng kamatayan. Kung mananatili ito magpakailanman, ang bawat refactor sa hinaharap ay kailangang magtanong: "ngunit kapaki-pakinabang pa ba ang sangay na ito?".
Kill switch: ihanda muna ang mga ito
Ang kill switch ay ang watawat na nagliligtas sa iyo kapag ang isang panlabas na dependency ay nagsimulang manggulo sa iyo, ang isang trabaho ay kumonsumo ng masyadong maraming mapagkukunan, o ang bagong lohika ay gumagawa ng mga kakaibang pagkakamali.
Ang magandang kill switch ay dapat na:
- madaling mahanap;
- dokumentado sa runbook;
- sinubukan paminsan-minsan;
- mapapansin kapag isinaaktibo;
- independyente, hangga't maaari, mula sa bahaging maaaring masira.
Ang pinakamasamang bagay ay ang matuklasan sa panahon ng aksidente na ang bandila ay umiiral, ngunit walang nakakaalam kung gumagana pa rin ito.
Obserbasyon o hindi progresibong paghahatid
Ang pag-on ng feature sa 10% nang hindi tumitingin sa mga sukatan ay optimismo lang na may maraming hakbang.
Dapat sagutin ng bawat paglulunsad ang mga simpleng tanong:
- nadagdagan ba ang mga error?
- nagbago ba ang latency?
- kinukumpleto ba ng mga user ang daloy?
- mayroon pa bang mga tiket o muling pagsubok?
- ang isang variant ba ay nakakaapekto lamang sa isang segment?
Sinusuportahan ng OpenFeature ang mga hook sa paligid ng pagsusuri sa bandila. Kapaki-pakinabang ang mga ito para sa mga error sa pag-log, pagdaragdag ng mga sukatan o pag-link ng rating sa isang trace.
Pangalan at pagmamay-ari
Mahalaga ang mga pangalan. new_ui walang sinasabi. Marami pang sinasabi ang checkout.v2.enabled.
Para sa bawat watawat mamarkahan ko man lang:
- pangalan;
- paglalarawan;
- may-ari;
- ligtas na default;
- dahilan kung bakit ito umiiral;
- petsa o kundisyon ng pagtanggal.
Ang watawat na walang may-ari ay halos palaging isang watawat na walang aalisin.
Saan susuriin ang mga ito
Frontend, backend o gilid? depende.
Kung para sa layout, kopya, o onboarding ang flag, ayos lang ang frontend. Kung may kinalaman ito sa mga pahintulot, pagsingil, limitasyon o sensitibong data, dapat itong nasa backend. Kung nagsasangkot ito ng pagruruta o mga eksperimento sa mataas na trapiko, maaaring magkaroon ng kahulugan ang gilid.
Ang simpleng panuntunan: maaaring mapahusay ng frontend ang karanasan, ngunit hindi ito dapat ang tanging hadlang sa seguridad.
Konklusyon
Ang feature flag na ginawa ay nakapagpabago ng relasyon sa produksyon. Hindi nila inaalis ang panganib, ngunit ginagawa nila itong mas maliit at mas madaling pamahalaan. Maaari mong bitawan sa hiwa, obserbahan, huminto, bumalik, matuto.
Ang OpenFeature ay nagdaragdag ng malinis na pundasyon: isang karaniwang API, mga mapagpapalit na provider, at isang mas maayos na paraan upang mapalago ang system. Ngunit nananatili sa iyo ang disiplina: mga ligtas na default, malinaw na pangalan, sukatan, may-ari at kalinisan.
Ang pinakamahusay na bandila ay ang isa na tumutulong sa iyong bitawan nang mahinahon at pagkatapos ay mawawala kapag hindi na ito kailangan.