1 
2استقرار زمانی است که کد وارد تولید می شود. انتشار زمانی است که شخصی بتواند واقعاً از آن استفاده کند. گیج کردن این دو یکی از سریع ترین راه ها برای ایجاد هر لحظه کمی پرتنش است.
3 
4feature flag برای ایجاد فاصله بین این دو لحظه خدمت می کند. شما می توانید امروز را مستقر کنید، فردا برای تیم داخلی، سپس برای یک مشتری آزمایشی، سپس برای 10٪ از کاربران فعال شوید. اگر مشکلی پیش آمد، پرچم را خاموش کنید. لزوماً لازم نیست کل نسخه را به عقب برگردانید.
5 
6## پرچم فقط یک اگر نیست
7 
8از نظر فنی اغلب یک `if` است. از نظر فرهنگی خیلی بیشتر است.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18آن `if` کوچک می‌تواند نشان دهنده یک عرضه تدریجی، یک آزمایش، یک مهاجرت، یک مجوز سازمانی یا یک kill switch عملیاتی باشد. مشکل این است که اگر آن را خوب مدیریت نکنید، می تواند به بدهی فنی نیز تبدیل شود که دو سال در کد می ماند.
19 
20## OpenFeature از کجا وارد می شود
21 
22OpenFeature یک مشخصات باز برای ارزیابی feature flag با یک API مشترک است. ایده ساده است: کد برنامه شما نباید مستقیماً به فروشنده یا سیستم داخلی که برای پرچم استفاده می کنید بستگی داشته باشد.
23 
24برنامه می پرسد:
25 
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33 
34ارائه دهنده تصمیم می گیرد که قوانین از کجا آمده باشند: SaaS، فایل، سرویس داخلی، پرچم، پیکربندی GitOps. اگر روزی ویژگی پرچم‌گذاری باطن را تغییر دهید، لازم نیست برنامه در همه جا بازنویسی شود.
35 
36این جدایی مانند یک جزئیات معماری به نظر می رسد، اما با رشد پروژه احساس می شود.
37 
38## زمینه نیمی از نبرد است
39 
40یک پرچم روشن یا خاموش برای همه مفید است، اما محدود است. تحویل پیشرونده در زمینه زندگی می کند:
41 
42- کاربر داخلی یا خارجی؛
43- طرح رایگان یا سازمانی؛
44- روستا؛
45- سازمان؛
46- نسخه برنامه؛
47- درصد ثابت ترافیک
48 
49کلید مهم `targetingKey` است: باید پایدار باشد. اگر با هر درخواست تغییر کند، یک کاربر می‌تواند یک بار در نوع A و یک بار در نوع B باشد. برای یک آزمایش وحشتناک است، برای پرداخت می‌تواند فاجعه‌بار باشد.
50 
51## عرضه معقول
52 
53جریانی که من دوست دارم این است:
54 
551. استقرار با پرچم خاموش.
562. احتراق برای توسعه دهندگان و QA.
573. روشن شدن برای مشتری یا مستاجر خلبان.
584. 5% عرضه؛
595. عرضه در 25%;
606. عرضه 100%؛
617. حذف کد و پرچم قدیمی.
62 
63نکته ای که اغلب فراموش می شود آخرین مورد است. یک پرچم موقت باید تاریخ مرگ داشته باشد. اگر برای همیشه باقی بماند، هر بازساز آینده باید بپرسد: "اما آیا این شاخه هنوز مفید است؟".
64 
65## Kill switch: ابتدا آنها را آماده کنید
66 
67kill switch پرچمی است که زمانی که یک وابستگی خارجی شروع به مزاحمت می‌کند، یک شغل منابع زیادی را مصرف می‌کند یا منطق جدید خطاهای عجیبی ایجاد می‌کند، شما را نجات می‌دهد.
68 
69یک kill switch خوب باید باشد:
70 
71- پیدا کردن آسان؛
72- مستند در runbook.
73- گاهی اوقات آزمایش می شود.
74- هنگام فعال شدن قابل مشاهده است.
75- مستقل، تا آنجا که ممکن است، از بخشی که ممکن است شکسته شود.
76 
77بدترین چیز این است که در طول تصادف کشف کنید که پرچم وجود دارد، اما هیچ کس نمی داند که آیا هنوز کار می کند یا خیر.
78 
79## قابلیت مشاهده یا عدم تحویل پیشرونده
80 
81روشن کردن یک ویژگی با 10٪ بدون بررسی معیارها فقط خوش بینی با چند مرحله است.
82 
83هر عرضه باید به سوالات ساده پاسخ دهد:
84 
85- آیا خطاها افزایش یافته است؟
86- آیا تاخیر تغییر کرده است؟
87- آیا کاربران جریان را کامل می کنند؟
88- آیا بلیط های بیشتری وجود دارد یا تلاش مجدد؟
89- آیا یک نوع تنها بر یک بخش تأثیر می گذارد؟
90 
91OpenFeature از قلاب‌ها در اطراف ارزیابی پرچم پشتیبانی می‌کند. آنها برای ثبت خطاها، افزودن معیارها یا پیوند دادن رتبه به trace مفید هستند.
92 
93## نامگذاری و مالکیت
94 
95نام ها مهم است `new_ui` چیزی نمی گوید. `checkout.v2.enabled` خیلی بیشتر می گوید.
96 
97برای هر پرچم حداقل علامت گذاری می کنم:
98 
99- نام؛
100- شرح؛
101- مالک؛
102- پیش فرض ایمن؛
103- دلیل وجود آن؛
104- تاریخ یا شرایط حذف
105 
106پرچم بدون صاحب تقریباً همیشه پرچمی است که هیچ کس آن را پاک نمی کند.
107 
108## کجا آنها را ارزیابی کنیم
109 
110Frontend، Backend یا Edge؟ بستگی دارد.
111 
112اگر پرچم برای چیدمان، کپی یا نصب است، قسمت جلویی مناسب است. اگر مربوط به مجوزها، صورت‌حساب، محدودیت‌ها یا داده‌های حساس است، باید در باطن باشد. اگر شامل مسیریابی یا آزمایش‌هایی با ترافیک بالا باشد، ممکن است لبه منطقی باشد.
113 
114قانون ساده: فرانت اند می تواند تجربه را بهبود بخشد، اما نباید تنها مانع امنیتی باشد.
115 
116## نتیجه گیری
117 
118feature flag به خوبی انجام شده رابطه با تولید را تغییر می دهد. آنها خطر را از بین نمی برند، اما آن را کوچکتر و قابل کنترل تر می کنند. می توانید تکه تکه رها کنید، مشاهده کنید، توقف کنید، به عقب برگردید، یاد بگیرید.
119 
120OpenFeature یک پایه تمیز اضافه می کند: یک API رایج، ارائه دهندگان قابل تعویض، و یک روش مرتب تر برای رشد سیستم. اما نظم و انضباط از آن شماست: پیش‌فرض‌های ایمن، نام‌های روشن، معیارها، مالکان و پاکیزگی.
121 
122بهترین پرچم پرچمی است که به شما کمک می کند با آرامش رها کنید و سپس زمانی که دیگر به آن نیاز ندارید ناپدید می شود.
123 
124## منابع
125 
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131