Feature Flag হল একটি ডেভেলপমেন্ট কৌশল যেখানে অ্যাপ্লিকেশনের কার্যকারিতা রানটাইমে শর্তসাপেক্ষ সুইচের মাধ্যমে সক্রিয় বা নিষ্ক্রিয় করা হয়, নতুন কোড ডিপ্লয় না করেই। ঐতিহ্যগত পদ্ধতি “commit — deploy”-এর পরিবর্তে, feature flags ডিপ্লয়মেন্টের মুহূর্তকে কার্যকারিতা সক্রিয় করার মুহূর্ত থেকে আলাদা করতে দেয়। LaunchDarkly (2024)-এর তথ্য অনুসারে, feature flags ব্যবহারকারী দলগুলি নতুন বৈশিষ্ট্য রোলআউটের সময় 40% কমিয়ে দেয়। Feature flags আধুনিক মোবাইল এবং ওয়েব অ্যাপ্লিকেশনের জন্য CI/CD-এর একটি অপরিহার্য উপাদান হয়ে উঠেছে।
মূল বিষয়
Feature Flag (ফিচার টগল) হল একটি প্রক্রিয়া যা কোড পরিবর্তন না করেই অ্যাপ্লিকেশনের আচরণ পরিবর্তন করতে দেয়। এর সহজতম আকারে, এটি একটি শর্তসাপেক্ষ নির্মাণ যা নতুন কার্যকারিতা সম্পাদনের আগে ফ্ল্যাগ মান পরীক্ষা করে। ফ্ল্যাগটি একটি কনফিগারেশন ফাইল, ডাটাবেস বা বাহ্যিক পরিষেবায় সংরক্ষণ করা যেতে পারে এবং রিয়েল টাইমে পরিবর্তন করা যেতে পারে। এই পদ্ধতি দলগুলিকে মূল শাখায় অসম্পূর্ণ কোড কমিট করার ক্ষমতা দেয়, বিকাশ সম্পূর্ণ হওয়ার আগে এটি ব্যবহারকারীদের কাছে পৌঁছানোর ভয় ছাড়াই।
Feature flags-এর মূল উদ্দেশ্য হল ডিপ্লয়মেন্টকে রিলিজ থেকে আলাদা করা। ডিপ্লয়মেন্ট হল সার্ভার বা অ্যাপ স্টোরে কোড স্থাপনের প্রক্রিয়া। রিলিজ হল সেই মুহূর্ত যখন কার্যকারিতা ব্যবহারকারীর জন্য উপলব্ধ হয়। Feature flags ছাড়া, এই ঘটনাগুলি মিলে যায়: কোড প্রোডাকশনে যায় — ব্যবহারকারীরা এটি দেখে। Feature flags-এর সাথে, কোড রিলিজের সপ্তাহ আগে প্রোডাকশনে ডিপ্লয় করা যেতে পারে, অভ্যন্তরীণ পরীক্ষার জন্য সক্রিয় করা যেতে পারে, বা ধীরে ধীরে দর্শকদের কাছে রোলআউট করা যেতে পারে। এটি trunk-based development এবং ক্রমাগত ডেলিভারির জন্য অত্যন্ত গুরুত্বপূর্ণ।
একটি মোবাইল Kotlin অ্যাপ্লিকেশনে একটি মৌলিক feature flag বাস্তবায়ন বিবেচনা করুন। ফ্ল্যাগটি Firebase Remote Config-এ সংরক্ষণ করা হয় এবং অ্যাপ শুরু হলে লোড হয়। ফ্ল্যাগ মানের উপর নির্ভর করে, পুরানো বা নতুন প্রোফাইল স্ক্রিন দেখানো হয়। এই বাস্তবায়ন App Store-এ আপডেট প্রকাশ না করেই প্রোফাইলের একটি নতুন সংস্করণ প্রকাশের অনুমতি দেয় — শুধু Firebase কনসোলে মান পরিবর্তন করুন।
class ProfileFeature {
private val flags = FeatureFlagProvider()
private val profileFlag = FlagKey("new_profile_enabled")
fun getProfileScreen(): Screen {
return if (flags.isEnabled(profileFlag)) {
NewProfileScreen()
} else {
LegacyProfileScreen()
}
}
}
class FeatureFlagProvider {
fun isEnabled(key: FlagKey): Boolean {
val raw = Firebase.remoteConfig.getString(key.name)
return raw.toBoolean()
}
}
সব feature flags এক রকম নয়। মার্টিন ফাউলারের শ্রেণীবিভাগ চার প্রকার ফ্ল্যাগ চিহ্নিত করে, যা ব্যবহারের উদ্দেশ্য, জীবনকাল এবং ব্যবস্থাপনার প্রয়োজনীয়তায় ভিন্ন। সঠিক ফ্ল্যাগ শ্রেণীবিভাগ উপযুক্ত অবকাঠামো বেছে নিতে এবং সাধারণ সমস্যা এড়াতে সাহায্য করে।
Release toggles হল সবচেয়ে সাধারণ ধরনের ফ্ল্যাগ। এগুলি প্রোডাকশনে অসম্পূর্ণ কার্যকারিতা লুকানোর জন্য ব্যবহৃত হয়। ডেভেলপার একটি ফ্ল্যাগে মোড়ানো কোড মূল শাখায় কমিট করে এবং ধীরে ধীরে কার্যকারিতা সম্পূর্ণ করে। সম্পূর্ণতা এবং পরীক্ষার পরে, ফ্ল্যাগটি সমস্ত ব্যবহারকারীর জন্য সক্রিয় করা হয়। এই ধরনের ফ্ল্যাগের জীবনচক্র কয়েক দিন থেকে দুই সপ্তাহ পর্যন্ত হয়। সম্পূর্ণ রোলআউটের পরে, ফ্ল্যাগটি কোড থেকে সরানো হয়। Release toggles trunk-based development-এর ভিত্তি।
Experiment toggles A/B পরীক্ষার সাথে একসাথে কাজ করে। তারা কেবল কার্যকারিতা চালু/বন্ধ করে না, বরং ব্যবহারকারীকে পরীক্ষামূলক গ্রুপগুলির একটিতে নির্দেশ দেয়। এই ধরনের ফ্ল্যাগ প্রায়শই জটিল টার্গেটিং নিয়ম (অঞ্চল, OS সংস্করণ, সাবস্ক্রিপশন অনুসারে) এবং বিশ্লেষণ সিস্টেমের সাথে একীকরণ সমর্থন করে। Ops toggles অপারেশনাল নিয়ন্ত্রণের জন্য ব্যবহৃত হয় — উদাহরণস্বরূপ, উচ্চ লোডের অধীনে একটি ভারী বৈশিষ্ট্য নিষ্ক্রিয় করা বা তাত্ক্ষণিক ডিপ্লয় ছাড়া একটি সমস্যাযুক্ত মডিউল সাময়িকভাবে বন্ধ করা। Ops toggles যতটা সম্ভব দ্রুত এবং নির্ভরযোগ্য হতে হবে, কারণ পরিষেবার স্থিতিশীলতা তাদের উপর নির্ভর করে।
| প্রকার | মেয়াদ | গতিশীলতা | উদ্দেশ্য |
|---|---|---|---|
| Release | দিন-সপ্তাহ | স্থির | অসম্পূর্ণ কোড লুকানো |
| Experiment | দিন-মাস | গতিশীল | A/B পরীক্ষা এবং রোলআউট |
| Ops | ঘন্টা-দিন | গতিশীল | অপারেশনাল নিয়ন্ত্রণ |
| Permission | মাস+ | স্থির | অ্যাক্সেস নিয়ন্ত্রণ |
Feature flags ব্যবস্থাপনা একটি পৃথক শৃঙ্খলা যা ফ্ল্যাগের স্টোরেজ, কনফিগারেশন, পর্যবেক্ষণ এবং নিরীক্ষণ অন্তর্ভুক্ত করে। ব্যবস্থাপনা সিস্টেম ছাড়া, ফ্ল্যাগগুলি অনিয়ন্ত্রিত প্রযুক্তিগত ঋণে পরিণত হয় যা উন্নয়নকে ধীর করে দেয়। আসুন একটি প্রোডাকশন সিস্টেমের উদাহরণ ব্যবহার করে ব্যবস্থাপনার মূল দিকগুলি দেখি।
প্রতিটি feature flag চারটি পর্যায়ে যায়: সৃষ্টি, ব্যবহার, স্থিতিশীলতা এবং অপসারণ। সৃষ্টি পর্যায়ে, ফ্ল্যাগ কী, প্রকার এবং ডিফল্ট মান নির্ধারণ করা হয়। ব্যবহারের সময়, দল পর্যবেক্ষণ করে কে ফ্ল্যাগ সক্রিয় করেছে, কোন দর্শকের জন্য এবং কী উদ্দেশ্যে। স্থিতিশীলতার পরে (কার্যকারিতা সম্পূর্ণ প্রস্তুত এবং পরীক্ষিত), ফ্ল্যাগটি কোড থেকে সরানো আবশ্যক। অপসারণ প্রক্রিয়া কোড পর্যালোচনার মাধ্যমে স্বয়ংক্রিয় হয়: CI পরীক্ষা করে যে 100% ব্যবহারকারীর জন্য সক্রিয় সমস্ত ফ্ল্যাগের একটি অপসারণ কাজ রয়েছে।
Feature flags কেন্দ্রীয়ভাবে সংরক্ষণ করা উচিত, প্রতিটি পরিষেবার কনফিগারেশন ফাইলে ছড়িয়ে না দিয়ে। আদর্শভাবে — UI সহ একটি ডেডিকেটেড পরিষেবা (LaunchDarkly, Unleash)। ন্যূনতম গ্রহণযোগ্য বিকল্প হল রিপোজিটরিতে একটি JSON কনফিগার যা পরিবর্তনের জন্য কোড পর্যালোচনা সহ। ফ্ল্যাগ সংরক্ষণের জন্য ডাটাবেস কম পছন্দের কারণ এটির জন্য একটি পৃথক ব্যবস্থাপনা ইন্টারফেস প্রয়োজন। প্রতিটি ফ্ল্যাগের একটি মালিক (দল বা নির্দিষ্ট ডেভেলপার), বিবরণ এবং জীবনকাল (TTL) থাকা উচিত। পুরনো ফ্ল্যাগের নিয়মিত নিরীক্ষণ একটি বাধ্যতামূলক অনুশীলন, একটি CI কাজের মাধ্যমে স্বয়ংক্রিয় যা N দিনের বেশি অপরিবর্তিত ফ্ল্যাগ পরীক্ষা করে।
Feature flags ব্যবস্থাপনা সরঞ্জামের বাজারে সম্পূর্ণ ব্যবস্থাপনা চক্র সহ বাণিজ্যিক প্ল্যাটফর্ম এবং স্ব-ডিপ্লয়মেন্টের জন্য ওপেন-সোর্স সমাধান উভয়ই অন্তর্ভুক্ত। সরঞ্জামের পছন্দ দলের আকার, লেটেন্সি প্রয়োজনীয়তা এবং সম্মতির উপর নির্ভর করে।
LaunchDarkly সমস্ত জনপ্রিয় ভাষা এবং প্ল্যাটফর্মের (iOS, Android, Web, Backend) জন্য SDK সহ বাজারের নেতা। এটি মাল্টি-এনভায়রনমেন্ট, নিয়ম-ভিত্তিক টার্গেটিং, A/B পরীক্ষা এবং স্বয়ংক্রিয় ফ্ল্যাগ অপসারণ সমর্থন করে। Split এন্টারপ্রাইজ বৈশিষ্ট্যগুলিতে ফোকাস সহ একটি বিকল্প: ভূমিকা-ভিত্তিক অ্যাক্সেস, অডিট লগ এবং সম্মতি (SOC2, HIPAA)। ConfigCat একটি হালকা এবং আরও সাশ্রয়ী মূল্যের সমাধান যা ছোট দলের জন্য উপযুক্ত। সমস্ত প্ল্যাটফর্ম মান ক্যাশিং এবং অ্যাপ্লিকেশন লেটেন্সিতে ন্যূনতম প্রভাব সহ SDK প্রদান করে।
Unleash UI, API এবং সমস্ত প্রধান প্ল্যাটফর্মের জন্য SDK সহ সবচেয়ে জনপ্রিয় ওপেন-সোর্স সমাধান। এটি অ্যাক্টিভেশন কৌশল, কাস্টম কনটেক্সট এবং পর্যবেক্ষণের জন্য Prometheus-এর সাথে একীকরণ সমর্থন করে। Flagsmith বিল্ট-ইন A/B পরীক্ষা এবং পরিবেশ ব্যবস্থাপনা সহ একটি বিকল্প। ওপেন-সোর্স সমাধানগুলির জন্য অবকাঠামো ডিপ্লয়মেন্ট এবং রক্ষণাবেক্ষণ প্রয়োজন, তবে ডেটার উপর সম্পূর্ণ নিয়ন্ত্রণ দেয় এবং কোনো লাইসেন্সিং সীমাবদ্ধতা নেই। মোবাইল অ্যাপ্লিকেশনের জন্য, উভয় সমাধান অফলাইন ফ্ল্যাগ মান ক্যাশিং সহ নেটিভ SDK প্রদান করে।
Feature flags একটি শক্তিশালী সরঞ্জাম, কিন্তু শৃঙ্খলা ছাড়া তারা প্রযুক্তিগত ঋণ তৈরি করে এবং কোড জটিল করে। মার্টিন ফাউলার এবং LaunchDarkly ইঞ্জিনিয়াররা অনুশীলনের একটি সেট তৈরি করেছেন যা নেতিবাচক পরিণতি ছাড়া feature flags থেকে সর্বাধিক সুবিধা পেতে সহায়তা করে। আসুন প্রোডাকশন সিস্টেমের জন্য মূল সুপারিশগুলি পর্যালোচনা করি।
প্রতিটি feature flag যা রোলআউট সম্পূর্ণ হওয়ার পরে সরানো হয়নি তা প্রযুক্তিগত ঋণে পরিণত হয়। LaunchDarkly (2024)-এর একটি গবেষণায় দেখা গেছে যে গড়ে 30–40% ফ্ল্যাগ প্রয়োজন না হওয়ার পরেও কোডে থেকে যায়। সমাধান: “একটি ফ্ল্যাগ — একটি কাজ” নিয়ম প্রয়োগ করুন। একটি ফ্ল্যাগ তৈরি করার সময়, টাস্ক ট্র্যাকারে একটি সময়সীমা সহ একটি অপসারণ কাজ তৈরি করা হয়। CI পরীক্ষা করে যে 30 দিনের বেশি 100% সক্রিয় কোনো ফ্ল্যাগ নেই। কোড পর্যালোচনা শুধুমাত্র ফ্ল্যাগ যোগ করা নয়, অপসারণও পরীক্ষা করা উচিত।
Feature flags পরীক্ষার জন্য সংমিশ্রণগত জটিলতা তৈরি করে: প্রতিটি ফ্ল্যাগ অ্যাপ্লিকেশনের সম্ভাব্য অবস্থার সংখ্যা দ্বিগুণ করে। এই জটিলতা পরিচালনা করার জন্য, ম্যাট্রিক্স পরীক্ষা যা সমস্ত ফ্ল্যাগ সংমিশ্রণ পরীক্ষা করে এবং ফ্ল্যাগ টগলিং ইন্টিগ্রেশন পরীক্ষা ব্যবহার করা হয়। CI পাইপলাইনে একটি ধাপ যোগ করা হয় যা বিভিন্ন ফ্ল্যাগ মান সংমিশ্রণ সহ পরীক্ষা চালায়। গুরুত্বপূর্ণ ফ্ল্যাগের (ops toggles) জন্য, লোড পরীক্ষা বাধ্যতামূলক যাতে যাচাই করা যায় যে ফ্ল্যাগ পরিবর্তন লেটেন্সি স্পাইক বা ত্রুটি সৃষ্টি করে না।
class FeatureFlagService:
def __init__(self, storage):
self.storage = storage
def is_enabled(self, flag_key, user_context):
flag = self.storage.get(flag_key)
if not flag:
return False
for rule in flag["rules"]:
if self._match_rule(rule, user_context):
return rule["value"]
return flag["default"]
def _match_rule(self, rule, context):
return (
rule["percentage"] > self._hash(context.user_id)
)
প্রায়শই জিজ্ঞাসিত প্রশ্ন
শব্দগুলি প্রায়শই একে অপরের পরিবর্তে ব্যবহার করা হয়, কিন্তু একটি সূক্ষ্মতা আছে: feature flag সাধারণত কেন্দ্রীভূত ব্যবস্থাপনা, UI এবং SDK সহ আরও পরিণত সিস্টেম বোঝায়, যখন feature toggle কোডে একটি সাধারণ বাইনারি সুইচ। মার্টিন ফাউলার feature toggle একটি সাধারণ শব্দ হিসাবে ব্যবহার করেন, কিন্তু শিল্পে feature flag প্রায়শই বাণিজ্যিক প্ল্যাটফর্মের (LaunchDarkly, Split) সাথে যুক্ত।
সঠিক বাস্তবায়নের সাথে কর্মক্ষমতার উপর প্রভাব ন্যূনতম। সেরা অনুশীলন: 30–60 সেকেন্ডের TTL সহ মেমরিতে ফ্ল্যাগ মান ক্যাশ করুন, ফ্ল্যাগ পরীক্ষা করার সময় সিঙ্ক্রোনাস HTTP কল এড়িয়ে চলুন, স্থানীয় ক্যাশ এবং ব্যাকগ্রাউন্ড সিঙ্ক্রোনাইজেশন সহ SDK ব্যবহার করুন। LaunchDarkly-এর মতে, তাদের SDK-এর p99 লেটেন্সি 5 ms-এর কম, যা বেশিরভাগ অ্যাপ্লিকেশনের জন্য নগণ্য।
গুরুত্বপূর্ণ আর্থিক কার্যক্রমে ব্যবসায়িক যুক্তি পরিবর্তন করার জন্য feature flags ব্যবহার করার পরামর্শ দেওয়া হয় না, যেখানে কোন কোড চলছে তা সঠিকভাবে জানা গুরুত্বপূর্ণ। সুরক্ষা ফাংশনের (অনুমোদন, এনক্রিপশন) জন্যও ফ্ল্যাগ এড়িয়ে চলুন — এই ধরনের ফ্ল্যাগ নিষ্ক্রিয় করলে দুর্বলতা তৈরি হয়। অবকাঠামো পরিবর্তনের (ডাটাবেস মাইগ্রেশন, নতুন আর্কিটেকচারে মাইগ্রেশন) জন্য, feature flags উপকারী কিন্তু বিশেষভাবে পুঙ্খানুপুঙ্খ পরীক্ষা প্রয়োজন।
প্রধান পদ্ধতি হল ম্যাট্রিক্স পরীক্ষা: সমস্ত ফ্ল্যাগ সংমিশ্রণ সহ পরীক্ষা চালানো। CI/CD-এর জন্য এটি খুব ব্যয়বহুল হতে পারে (2^n সংমিশ্রণ), তাই বাস্তবে সমস্ত ফ্ল্যাগ পৃথকভাবে উভয় অবস্থায় (চালু/বন্ধ) পরীক্ষা করা হয় এবং শুধুমাত্র গুরুত্বপূর্ণ সংমিশ্রণগুলি পরীক্ষা করা হয়। ইউনিট পরীক্ষাগুলি ফ্ল্যাগ মান মক করা উচিত। ইন্টিগ্রেশন পরীক্ষাগুলি পরিচিত ফ্ল্যাগ মান সহ নির্দিষ্ট পরিস্থিতি পরীক্ষা করে। E2E পরীক্ষাগুলি সবচেয়ে সম্ভাব্য সংমিশ্রণগুলি কভার করে।
অপসারণ প্রক্রিয়া: 1) নিশ্চিত করুন যে ফ্ল্যাগটি সমস্ত ব্যবহারকারীর জন্য 100% সক্রিয় এবং পরীক্ষা মোডে ব্যবহার করা হচ্ছে না; 2) কোড থেকে ফ্ল্যাগের সমস্ত শর্তসাপেক্ষ পরীক্ষা সরান, শুধুমাত্র “নতুন” শাখা রেখে; 3) ব্যবস্থাপনা সিস্টেম থেকে ফ্ল্যাগ সংজ্ঞা সরান; 4) সরানো ফ্ল্যাগের মক সরিয়ে পরীক্ষাগুলি আপডেট করুন। CI-এর মাধ্যমে এই প্রক্রিয়াটি স্বয়ংক্রিয় করার পরামর্শ দেওয়া হয়: N দিনের বেশি অপরিবর্তিত ফ্ল্যাগগুলি পুরনো হিসাবে চিহ্নিত হয় এবং অপসারণ নিশ্চিতকরণ প্রয়োজন।
সারসংক্ষেপ
আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব
IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।
আরও পড়ুন