Feature flagها
Pulse feature flagها را از کجا می‌خواند، چطور تغییرشان می‌دهید، و وقتی منبع در دسترس نیست چه می‌شود.
Feature flagها یک قابلیت محصول را برای کل استقرار، یا برای workspaceها، تیم‌ها، نقش‌ها یا کاربران انتخاب‌شده روشن یا خاموش می‌کنند. این صفحه برای کسانی است که یک استقرار Pulse را اداره می‌کنند. تنظیمات workspace در مدیریت آمده است.
Flag فقط یک قابلیت را نشان می‌دهد یا پنهان می‌کند و هیچ دسترسی‌ای نمی‌دهد: قابلیتی که روشن است هم همان permissionهای همیشگی را اعمال می‌کند.
Flagها از کجا می‌آیند
Flagها در flag store خود pulse-api نگه داشته می‌شوند. سطح‌شان platform است، پس یک تعریف همهٔ workspaceهای استقرار را پوشش می‌دهد. همهٔ اجزا آن‌ها را از pulse-api می‌خوانند:
| جزء | مسیر خواندن flag |
|---|---|
| pulse-api و scheduler | مستقیم از flag store |
| سرویس‌های Pulse Agent (pulse-agent و pulse-ai) | endpoint ارزیابی سرویس pulse-api |
| اپ‌های Web، Mac و iOS | endpoint کلاینت pulse-api (POST /api/v1/ofrep/v1/evaluate/flags) |
هیچ کلاینتی با Unleash تماس نمی‌گیرد.
انتخاب منبع
pulse-api، scheduler و pulse-agent هر کدام منبع خود را با FEATURE_FLAGS_SOURCE انتخاب می‌کنند:
| مقدار | پاسخ از |
|---|---|
pulse | flag store خود pulse-api. همین را به کار ببرید. |
unleash | یک سرور Unleash که با UNLEASH_URL و UNLEASH_API_TOKEN تنظیم می‌شود. بدون این دو، هر flag مقدار پیش‌فرض خود را می‌دهد. پیش‌فرض این متغیر همین است و برای استقرارهای قدیمی‌تر مانده است. |
none | هیچ منبعی. هر flag مقدار پیش‌فرض خود را می‌دهد. |
FEATURE_FLAGS_SOURCE=pulseمقدار خالی یا ناشناخته جلوی بالا آمدن سرویس را می‌گیرد. عوض کردن منبع یک restart لازم دارد.
- Pulse میزبانی‌شده روی
pulseاجرا می‌شود و دیگر از Unleash استفاده نمی‌کند. - نصب‌های pulse-ctl همیشه روی
pulseاجرا می‌شوند. pulse-ctl این تنظیم را خودش می‌نویسد وFEATURE_FLAGS_SOURCEو هر کلیدUNLEASH_*را درservice_envرد می‌کند. - pulse-ai تنظیمی ندارد و همیشه از pulse-api می‌خواند.
Unleash اختیاری است. اگر امروز از آن استفاده می‌کنید، یک platform admin می‌تواند flagهایش را با POST /api/v1/admin/feature-flags/import/unleash?dry_run=true به store کپی کند. برای نوشتن واقعی dry_run را بردارید. Flagهایی که store نمی‌تواند نشان بدهد، مثل rolloutهای درصدی یا variantها، به‌جای import گزارش می‌شوند.
زیر unleash، تغییرهایی که در flag store ذخیره می‌شوند اثری ندارند. پیش از مدیریت flagها در backoffice منبع را به pulse تغییر دهید.
مقدارهای پیش‌فرض
pulse-api هر بار که بالا می‌آید، هر flagی را که می‌شناسد و هنوز در store نیست با مقدار پیش‌فرضش اضافه می‌کند. Flagی که یک مدیر تغییر داده هیچ‌وقت reset نمی‌شود، پس نصب تازه به seed کردن نیاز ندارد.
| Flag | پیش‌فرض | چه چیزی را کنترل می‌کند |
|---|---|---|
pulse_agent | روشن | Pulse Agent در اپ‌ها و سرویس agent |
pulse_loops | روشن | Loopها: کار زمان‌بندی‌شده و event-محور agent. وقتی خاموش است، routeهای Loop پاسخ LOOPS_DISABLED می‌دهند و اپ‌ها Loopها را پنهان می‌کنند. |
subagents | روشن | sub-agentهای Pulse Agent |
project_coordinator | خاموش | agent مربوط به Project Coordinator |
pulse_live_effects_off | خاموش | یک kill switch: روشن بودنش افکت‌های بصری زنده را در اپ وب خاموش می‌کند. |
pulse_judgments | خاموش | judgmentهای TypeSafe در Pulse Agent. این‌ها متن workspace را به typesafe.ai می‌فرستند، پس flag تا وقتی مدیری روشنش نکند خاموش می‌ماند. |
environment_runner_routing | خاموش | فرستادن coding sessionها به runner بر اساس execution target محیط |
agent_apps | خاموش | agent appهای شخص ثالث |
تغییر یک flag
یک platform admin flagها را در backoffice زیر Feature flags (/feature-flags) یا از طریق /api/v1/admin/feature-flags تغییر می‌دهد. هر تغییر یک session واردشده لازم دارد. API key یا توکن یک OAuth application نمی‌تواند flagها را تغییر دهد.
هر flag یکی از حالت‌های on، off یا targeted را دارد. Flag از نوع targeted چند rule دارد و وقتی یکی از ruleها match شود روشن است. یک rule وقتی match می‌شود که همهٔ شرط‌هایش برقرار باشند:
- workspace یکی از workspaceهای فهرست باشد
- کاربر یکی از کاربران فهرست باشد
- کاربر عضو یکی از تیم‌های فهرست باشد
- نقش کاربر در workspace یکی از نقش‌های فهرست باشد
- کاربر platform admin باشد
Flag از نوع targeted برای هر کسی که هیچ ruleی با او match نشود خاموش است، پیش‌فرضش هر چه باشد. کار پس‌زمینه مثل اجرای زمان‌بندی‌شدهٔ Loop کاربر ندارد، پس فقط با شرط‌های workspace match می‌شود. pulse_loops را بر اساس workspace هدف بگیرید.
هر تغییر در تاریخچهٔ flag نگه داشته می‌شود. Archive کردن یک flag برگشت‌ناپذیر است: از آن به بعد مقدار پیش‌فرضش را می‌دهد و ویرایش نمی‌شود. برای کپی flagها بین استقرارها، آن‌ها را با GET /api/v1/admin/feature-flags/export export کنید و فایل را با POST /api/v1/admin/feature-flags/import import کنید.
هر سرویس یک تغییر را در حدود یک دقیقه می‌گیرد. هیچ چیز به restart یا config apply نیاز ندارد.
در استقراری که خودتان تنظیم می‌کنید، UNLEASH_OVERRIDES=flag=true,other=false روی pulse-api زیر هر منبعی یک مقدار را تحمیل می‌کند. pulse-ctl آن را نمی‌پذیرد، پس در نصب pulse-ctl به‌جایش flag را در backoffice تغییر دهید.
وقتی منبع در دسترس نیست
خواندن flag هیچ‌وقت شکست نمی‌خورد. وقتی منبع نمی‌تواند پاسخ بدهد، همهٔ اجزا یک‌جور fallback می‌کنند:
| وضعیت | پاسخ |
|---|---|
بدون منبع (none، یا unleash بدون سرور) | مقدار پیش‌فرض flag. |
| هنگام بالا آمدن، پیش از اولین پاسخ | آخرین مقدار شناخته‌شده اگر باشد، وگرنه پیش‌فرض. pulse_loops اینجا خاموش پاسخ می‌دهد، پس هیچ Loopی پیش از پاسخ منبع اجرا نمی‌شود. اجراهای زمان‌بندی‌شده صبر می‌کنند و دوباره تلاش می‌کنند. |
| منبع دیگر پاسخ نمی‌دهد | آخرین مقدارهای شناخته‌شده، تا وقتی خودش برگردد. |
| منبع آن flag را تعریف نکرده | مقدار پیش‌فرض flag. |
صفحهٔ Feature flags در backoffice وقتی store منبع نیست و تغییرها اثری ندارند هشدار می‌دهد. GET /api/v1/admin/feature-flags منبع و آماده یا stale بودنش را در status گزارش می‌کند، و pulse-api همین را با metricهای pulse_feature_flag_source_ready{source} و pulse_feature_flag_source_stale{source} export می‌کند.
آخرین به‌روزرسانی