GaliTech
یک تیم نرم‌افزاری می‌خواهد روش تازه‌ای برای پرداخت به فروشگاه اضافه کند. فعال‌کردن آن برای همهٔ مشتریان در یک لحظه، فرصت بررسی مشکلات را کم می‌کند. راه دیگری هم وجود دارد: کد قابلیت روی سامانه قرار بگیرد، اما ابتدا فقط گروه مشخصی از کاربران آن را ببینند. اگر عملکرد مناسب بود، دسترسی به‌تدریج گسترش پیدا کند.
Feature Flag یا «پرچم قابلیت» تصمیمی قابل تنظیم در برنامه است که مشخص می‌کند یک قابلیت برای چه شرایطی فعال باشد. وقتی کد لازم از قبل مستقر شده و برنامه برای دریافت این تنظیم طراحی شده باشد، تیم می‌تواند رفتار آن را بدون استقرار دوبارهٔ کد تغییر دهد. این روش، انتشار نرم‌افزار را کنترل‌پذیرتر می‌کند؛ کیفیت یا امنیت قابلیت را به‌تنهایی تضمین نمی‌کند. [۱]
از کد آماده تا قابلیت قابل استفاده
استقرار یعنی نسخه‌ای از کد و اجزای مورد نیاز آن روی محیط اجرا قرار بگیرد. عرضهٔ قابلیت یعنی کاربران بتوانند از آن استفاده کنند. این دو اتفاق می‌توانند هم‌زمان باشند، اما الزامی نیست. با Feature Flag، مسیر تازه در برنامه وجود دارد و تنظیم پرچم تعیین می‌کند چه زمانی و برای چه کسانی انتخاب شود. [۲]
برای نمونه، برنامه هنگام نمایش صفحهٔ پرداخت بررسی می‌کند که روش جدید برای این کاربر فعال است یا نه. اگر فعال باشد، مسیر تازه را نشان می‌دهد؛ در غیر این صورت، مسیر قبلی حفظ می‌شود. چنین شرطی فقط مربوط به ظاهر صفحه نیست و می‌تواند در منطق سمت سرور هم قرار بگیرد. محل آن باید با کاری که قابلیت انجام می‌دهد متناسب باشد.
عبارت «بدون انتشار نسخهٔ جدید» نباید به این معنا برداشت شود که هر قابلیت تازه‌ای بدون برنامه‌نویسی ایجاد می‌شود. ابتدا باید کد و وابستگی‌های لازم آماده و مستقر شوند. پس از آن، تغییر تنظیم می‌تواند دسترسی به همان قابلیت را کنترل کند. اگر قابلیت به تغییر ناسازگار پایگاه داده یا سرویس بیرونی نیاز دارد، یک پرچم ساده همهٔ مراحل را حل نمی‌کند.
مثال فرضی: روش پرداخت تازه در یک فروشگاه
در این سناریوی ساختگی، فروشگاه یک روش پرداخت پایدار دارد و تیم می‌خواهد روش دوم را اضافه کند. مثال به شرکت، محصول یا رخداد واقعی خاصی اشاره ندارد. هدف، توضیح تصمیم‌های تیم است؛ درصدها و معیارهای آن توصیهٔ ثابت برای تمام پروژه‌ها نیستند.
پیش از عرضه، تیم مسیر پرداخت، ثبت سفارش، پیام خطا و بازگشت از سرویس پرداخت را آزمایش می‌کند. روش قبلی نیز در دسترس می‌ماند. سپس نسخه‌ای را مستقر می‌کند که هر دو مسیر را دارد، ولی پرچم روش جدید برای مشتریان عمومی خاموش است. کارکنان مجاز می‌توانند آن را در شرایط کنترل‌شده بررسی کنند.
در مرحلهٔ بعد، گروه کوچکی از کاربران واجد شرایط وارد تجربهٔ تازه می‌شوند. برای مثال، تیم می‌تواند در این سناریو پنج درصد از یک گروه مشخص را انتخاب کند. انتخاب باید طوری انجام شود که کاربر در یک جریان خرید، ناگهان میان دو تجربه جابه‌جا نشود. معیار عضویت و نحوهٔ ثابت‌ماندن آن به طراحی سامانه بستگی دارد.
تیم فقط تعداد پرداخت‌های موفق را نگاه نمی‌کند. زمان پاسخ، خطاهای ثبت سفارش و تماس‌های پشتیبانی هم برای فهم نتیجه مهم‌اند. اگر کاربران روش تازه نتوانند خرید را کامل کنند، افزایش دسترسی متوقف می‌شود. اگر نتیجه قابل قبول باشد، گروه بزرگ‌تر می‌شود؛ تصمیم براساس معیارهای از پیش تعیین‌شده گرفته می‌شود، نه صرفاً گذشت چند روز.
خاموش‌کردن پرچم، کاربران بعدی را به مسیر قبلی هدایت می‌کند. اما پرداخت انجام‌شده، سفارش ثبت‌شده یا درخواست در حال پردازش را خودکار برنمی‌گرداند. تیم باید برای وضعیت‌های نیمه‌تمام و سازگاری داده‌ها برنامه داشته باشد. کنترل دسترسی به مسیر جدید، با اصلاح پیامدهای استفادهٔ قبلی از آن دو مسئلهٔ جداست.
کاربردهای اصلی Feature Flag
فعال‌سازی تدریجی قابلیت به تیم فرصت می‌دهد اثر تغییر را در دامنه‌ای محدود ببیند. این شیوه برای قابلیتی که رفتار کاربران یا بار سامانه را تغییر می‌دهد مفید است. با این حال، گروه آزمایشی کوچک ممکن است همهٔ شرایط واقعی را نشان ندهد؛ رفتار یک گروه، نتیجهٔ قطعی استفادهٔ عمومی نیست. [۲]
کاربرد دیگر، در اختیار گذاشتن قابلیت آماده برای کارکنان یا گروه مشخصی از کاربران است. تیم می‌تواند بازخورد بگیرد و سپس دربارهٔ عرضهٔ گسترده‌تر تصمیم بگیرد. چنین دسترسی‌ای باید از قبل تعریف شود؛ مخفی‌بودن یک دکمه، مجوز دسترسی به عملیات حساس ایجاد نمی‌کند.
پرچم می‌تواند ابزار اجرای آزمایش مقایسه‌ای هم باشد؛ مثلاً دو روش نمایش یک فرم به گروه‌های متفاوت ارائه شوند. اما فعال‌کردن دو حالت، به‌تنهایی یک آزمایش معتبر نمی‌سازد. پرسش، معیار، تقسیم گروه‌ها و روش تحلیل باید روشن باشند. گاهی هدف صرفاً عرضهٔ مرحله‌ای است و نیازی به ادعای آزمون علمی نیست. [۳]
غیرفعال‌کردن یک قابلیت مشکل‌دار نیز از کاربردهای مهم است. این امکان وقتی ارزش دارد که مسیر خاموش‌شدن، رفتار جایگزین و مسئول تصمیم از قبل مشخص باشند. در نمونهٔ فروشگاه، اگر روش قبلی از کار افتاده باشد، برگشت به آن راه‌حل قابل اتکایی نخواهد بود.
یک پرچم چگونه تصمیم می‌گیرد؟
در ساده‌ترین حالت، پرچم یک مقدار روشن یا خاموش دارد. در سامانه‌های پیشرفته‌تر، نتیجه می‌تواند با توجه به محیط، گروه کاربر یا ویژگی‌های مجاز دیگری تعیین شود. برنامه نتیجه را دریافت می‌کند و براساس آن مسیر مناسب را انتخاب می‌کند. داشتن نام روشن برای پرچم کمک می‌کند معنای هر حالت اشتباه فهمیده نشود. [۴]
تنظیم «خاموش» نیز نیاز به تعریف دارد. مستندات LaunchDarkly نشان می‌دهد که پرچم خاموش یک مقدار مشخص برای حالت خاموش برمی‌گرداند؛ در مقابل، مقدار جایگزین برای زمانی است که ارزیابی پرچم نتواند انجام شود. این دو مقدار ممکن است مشابه انتخاب شوند، اما یک وضعیت واحد نیستند. رفتار دقیق باید در ابزار مورد استفاده بررسی شود. [۵]
در نمونهٔ پرداخت، اگر دریافت تنظیم قطع شود، برنامه نباید بدون تصمیم قبلی یک مسیر نامعلوم را انتخاب کند. تیم باید مشخص کند حالت جایگزین چیست، خطا چگونه ثبت می‌شود و قابلیت اصلی خرید چگونه ادامه پیدا می‌کند. سرعت رسیدن تغییر تنظیم به همهٔ اجزا نیز به معماری و ابزار بستگی دارد؛ «خاموش‌شدن آنی در همه‌جا» وعدهٔ قابل تعمیمی نیست.
امنیت و کنترل دسترسی
پرچم قابلیت جای سامانهٔ احراز هویت و کنترل مجوز را نمی‌گیرد. اگر عملیات پرداخت یا دادهٔ حساس نیازمند مجوز است، این مجوز باید در محل معتبر اجرای عملیات بررسی شود. پنهان‌کردن رابط، به‌تنهایی مانع درخواست مستقیم به سرویس نیست. راهنمای OWASP نیز بر بررسی مجوزها در هر درخواست و جلوگیری از تکیه بر کنترل سمت کاربر تأکید می‌کند. [۶]
خودِ امکان تغییر تنظیم هم حساس است. فردی که می‌تواند پرچم پرداخت را عوض کند، روی تجربهٔ کاربران اثر می‌گذارد. به‌عنوان تصمیم مهندسی در این مثال، تیم می‌تواند دسترسی تغییر را محدود کند، تغییرات را ثبت کند و مسئول پاسخ‌گویی را تعیین کند. اطلاعات لازم برای گروه‌بندی کاربران نیز باید حداقلی باشد؛ دادهٔ بیشتر الزاماً تصمیم بهتری ایجاد نمی‌کند.
هزینه‌ای که با افزایش پرچم‌ها پنهان می‌ماند
هر پرچم مسیر دیگری به رفتار برنامه اضافه می‌کند. اگر چند پرچم به یک بخش وابسته باشند، ترکیب حالت‌ها می‌تواند آزمون و عیب‌یابی را دشوار کند. روشن و خاموش بودن یک قابلیت باید همراه با حالت‌های مهم مرتبط آزمایش شود. مقالهٔ Pete Hodgson در وب‌سایت Martin Fowler، هزینهٔ نگهداری و پیچیدگی اعتبارسنجی پرچم‌ها را از مسائل اصلی این روش می‌داند. [۳]
پرچمی که فقط برای عرضهٔ تدریجی ایجاد شده، نباید بدون دلیل سال‌ها در کد باقی بماند. برای مثال، پس از تثبیت روش پرداخت تازه، تیم می‌تواند دربارهٔ حذف مسیر قدیمی و پرچم تصمیم بگیرد. این تصمیم با نیاز عملیاتی محصول فرق دارد: بعضی کنترل‌ها طولانی‌مدت‌اند، ولی یک پرچم موقت نیازمند زمان بازبینی و مسئول مشخص است.
نام، هدف، مسئول و زمان بازبینی هر پرچم، اطلاعات مفیدی برای نگهداری‌اند. ثبت این موارد یک توصیهٔ اجرایی برای همین سناریوست. وقتی حادثه‌ای رخ می‌دهد، فهرستی از نام‌های مبهم یا پرچم‌های بی‌صاحب، تشخیص حالت واقعی برنامه را دشوار می‌کند.
OpenFeature چه نقشی دارد؟
OpenFeature مشخصات باز و رابط مشترکی برای کار با پرچم‌های قابلیت ارائه می‌کند. برنامه از یک رابط برنامه‌نویسی مشترک (API)، یعنی روش مشخصی برای درخواست نتیجهٔ پرچم، استفاده می‌کند. بخشی به نام Provider، یا اتصال‌دهنده، ارتباط با سامانهٔ مدیریت پرچم را برقرار می‌کند. هدف، کاهش وابستگی کد برنامه به رابط اختصاصی یک ارائه‌دهنده است. [۱]
OpenFeature به‌خودی‌خود جای همهٔ امکانات یک سامانهٔ مدیریت قابلیت را نمی‌گیرد. قوانین گروه‌بندی، پنل مدیریت و نحوهٔ توزیع تنظیم‌ها به راهکار متصل و پیاده‌سازی بستگی دارند. انتخاب آن باید با زبان برنامه، محیط اجرا و نیاز تیم سنجیده شود؛ استفاده از استاندارد مشترک، انتقال بدون بررسی میان همهٔ ابزارها را تضمین نمی‌کند.
از کجا شروع شود؟
برای یک تیم تازه‌کار، انتخاب یک قابلیت مشخص و قابل بازگشت، نقطهٔ شروع روشن‌تری از پرچم‌گذاری همهٔ بخش‌های محصول است. تیم باید بداند چه رفتاری کنترل می‌شود، چه کسی تغییر را مجاز می‌کند، موفقیت چگونه سنجیده می‌شود و اگر نتیجه مطلوب نبود، مسیر جایگزین چیست.
Feature Toggle زمانی مفید است که این تصمیم‌ها به طراحی و نگهداری واقعی وصل شوند. بررسی کاربرد آن در یک پروژه و مطالعهٔ مستندات ابزار انتخاب‌شده، از افزودن تعداد زیادی کلید روشن و خاموش مهم‌تر است. قابلیت آماده می‌تواند تدریجی فعال شود؛ آزمون نرم‌افزار، نظارت و کنترل امنیت همچنان مسئولیت‌های مستقل تیم باقی می‌مانند.