Feature flag: আপনার শ্বাস না ধরে ছেড়ে দিন
· 4 min read · Filippo Spinella · DevOps, OpenFeature, CI/CD, Software Architecture
যখন কোডটি উৎপাদনে আসে তখন স্থাপনা। রিলিজ হল যখন কেউ আসলে এটি ব্যবহার করতে পারে। দুটিকে বিভ্রান্ত করা প্রতিটি স্থাপনাকে একটু উত্তেজনাপূর্ণ মুহূর্ত করার দ্রুততম উপায়গুলির মধ্যে একটি।
feature flag এই দুটি মুহুর্তের মধ্যে স্থান রাখে। আপনি আজকে স্থাপন করতে পারেন, আগামীকাল অভ্যন্তরীণ দলের জন্য, তারপর একজন পাইলট গ্রাহকের জন্য, তারপর 10% ব্যবহারকারীর জন্য। যদি কিছু ভুল হয়ে যায়, পতাকা বন্ধ করুন। আপনাকে অগত্যা পুরো রিলিজটি রোলব্যাক করতে হবে না।
পতাকা শুধু একটি যদি নয়
প্রযুক্তিগতভাবে এটি প্রায়ই একটি if হয়। সাংস্কৃতিকভাবে এটা অনেক বেশি।
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
এই সামান্য if একটি ধীরে ধীরে রোলআউট, একটি পরীক্ষা, একটি স্থানান্তর, একটি এন্টারপ্রাইজ পারমিট বা একটি অপারেশনাল kill switch প্রতিনিধিত্ব করতে পারে। সমস্যা হল যে আপনি যদি এটি ভালভাবে পরিচালনা না করেন তবে এটি প্রযুক্তিগত ঋণও হতে পারে যা কোডে দুই বছরের জন্য থাকে।
কোথায় OpenFeature আসে
OpenFeature একটি সাধারণ API দিয়ে feature flag মূল্যায়ন করার জন্য একটি উন্মুক্ত স্পেসিফিকেশন। ধারণাটি সহজ: আপনার অ্যাপ্লিকেশন কোড সরাসরি বিক্রেতা বা অভ্যন্তরীণ সিস্টেমের উপর নির্ভর করবে না যা আপনি পতাকার জন্য ব্যবহার করেন।
অ্যাপটি জিজ্ঞাসা করে:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
প্রদানকারী সিদ্ধান্ত নেয় যে নিয়মগুলি কোথা থেকে এসেছে: SaaS, ফাইল, অভ্যন্তরীণ পরিষেবা, পতাকাঙ্কিত, GitOps কনফিগারেশন৷ যদি একদিন আপনি বৈশিষ্ট্য ফ্ল্যাগিং ব্যাকএন্ড পরিবর্তন করেন, অ্যাপ্লিকেশনটিকে সর্বত্র পুনরায় লিখতে হবে না।
এই বিচ্ছেদটি একটি স্থাপত্যের বিশদটির মতো মনে হয়, তবে প্রকল্পটি বাড়ার সাথে সাথে এটি অনুভূত হয়।
প্রসঙ্গ অর্ধেক যুদ্ধ
প্রত্যেকের জন্য একটি চালু বা বন্ধ পতাকা দরকারী, কিন্তু সীমিত। প্রগতিশীল ডেলিভারি প্রসঙ্গে বেঁচে থাকে:
- অভ্যন্তরীণ বা বহিরাগত ব্যবহারকারী;
- বিনামূল্যে বা এন্টারপ্রাইজ পরিকল্পনা;
- গ্রাম;
- সংগঠন;
- অ্যাপ সংস্করণ;
- ট্রাফিকের স্থিতিশীল শতাংশ।
গুরুত্বপূর্ণ কী হল targetingKey: এটি অবশ্যই স্থিতিশীল হতে হবে। যদি এটি প্রতিটি অনুরোধের সাথে পরিবর্তিত হয়, একজন ব্যবহারকারী একবার A ভেরিয়েন্টে এবং একবার B ভেরিয়েন্টে শেষ করতে পারেন৷ একটি পরীক্ষার জন্য এটি ভয়ানক, একটি চেকআউটের জন্য এটি বিপর্যয়কর হতে পারে৷
একটি বুদ্ধিমান রোলআউট
আমার পছন্দের একটি প্রবাহ হল:
- পতাকা বন্ধ সঙ্গে স্থাপন;
- বিকাশকারীদের জন্য ইগনিশন এবং QA;
- একজন পাইলট গ্রাহক বা ভাড়াটে জন্য সুইচ-অন;
- 5% রোলআউট;
- 25% এ রোলআউট;
- 100% রোলআউট;
- পুরানো কোড এবং পতাকা অপসারণ.
প্রায়শই ভুলে যাওয়া পয়েন্টটি শেষ। একটি অস্থায়ী পতাকার একটি মৃত্যু তারিখ থাকতে হবে। যদি এটি চিরতরে থেকে যায়, প্রতিটি ভবিষ্যতের রিফ্যাক্টরকে জিজ্ঞাসা করতে হবে: "কিন্তু এই শাখাটি কি এখনও কার্যকর?"।
Kill switch: আগে তাদের প্রস্তুত করুন
kill switch হল সেই পতাকা যা আপনাকে বাঁচায় যখন কোনো বাহ্যিক নির্ভরতা আপনার সাথে বিশৃঙ্খলা শুরু করে, একটি কাজ অনেক বেশি সম্পদ খরচ করে, বা নতুন যুক্তি অদ্ভুত ত্রুটি তৈরি করে।
একটি ভাল kill switch হতে হবে:
- খুঁজে পাওয়া সহজ;
- রানবুকে নথিভুক্ত;
- মাঝে মাঝে পরীক্ষা করা হয়;
- সক্রিয় করা হলে পর্যবেক্ষণযোগ্য;
- স্বাধীন, যতদূর সম্ভব, ভাঙতে পারে এমন অংশ থেকে।
সবচেয়ে খারাপ জিনিস হল দুর্ঘটনার সময় আবিষ্কার করা যে পতাকাটি বিদ্যমান, তবে এটি এখনও কাজ করে কিনা তা কেউ জানে না।
পর্যবেক্ষণযোগ্যতা বা প্রগতিশীল বিতরণ না
মেট্রিক্সের দিকে না তাকিয়ে 10% এ একটি বৈশিষ্ট্য চালু করা একাধিক পদক্ষেপের সাথে শুধুমাত্র আশাবাদ।
প্রতিটি রোলআউটের সহজ প্রশ্নের উত্তর দেওয়া উচিত:
- ত্রুটি বেড়েছে?
- বিলম্ব কি পরিবর্তিত হয়েছে?
- ব্যবহারকারীরা কি প্রবাহ সম্পূর্ণ করে?
- আরো টিকিট বা পুনরায় চেষ্টা আছে?
- একটি বৈকল্পিক শুধুমাত্র একটি অংশ প্রভাবিত করে?
OpenFeature পতাকা মূল্যায়নের চারপাশে হুক সমর্থন করে। এগুলি লগিং ত্রুটির জন্য, মেট্রিক্স যোগ করার জন্য বা একটি trace এর সাথে রেটিং লিঙ্ক করার জন্য দরকারী৷
নামকরণ এবং মালিকানা
নাম গুরুত্বপূর্ণ। new_ui কিছুই বলে না। checkout.v2.enabled আরও অনেক কিছু বলে।
প্রতিটি পতাকার জন্য আমি অন্তত চিহ্নিত করব:
- নাম;
- বর্ণনা;
- মালিক;
- নিরাপদ ডিফল্ট;
- কেন এটি বিদ্যমান;
- তারিখ বা অপসারণের শর্ত।
একটি মালিকহীন পতাকা প্রায় সর্বদা একটি পতাকা যা কেউ পরিষ্কার করবে না।
কোথায় তাদের মূল্যায়ন করবেন
ফ্রন্টএন্ড, ব্যাকএন্ড বা প্রান্ত? নির্ভর করে।
যদি পতাকা লেআউট, অনুলিপি বা অনবোর্ডিংয়ের জন্য হয়, তাহলে ফ্রন্টএন্ড ঠিক আছে। যদি এটি অনুমতি, বিলিং, সীমা বা সংবেদনশীল ডেটা সম্পর্কিত হয় তবে এটি অবশ্যই ব্যাকএন্ডে থাকতে হবে। যদি এটি রাউটিং বা উচ্চ-ট্রাফিক পরীক্ষা-নিরীক্ষার সাথে জড়িত থাকে, তাহলে প্রান্তটি অর্থপূর্ণ হতে পারে।
সহজ নিয়ম: ফ্রন্টএন্ড অভিজ্ঞতা উন্নত করতে পারে, কিন্তু এটি একমাত্র নিরাপত্তা বাধা হওয়া উচিত নয়।
উপসংহার
feature flag ভালোভাবে সম্পন্ন করেছে উৎপাদনের সাথে সম্পর্ক পরিবর্তন করে। তারা ঝুঁকি দূর করে না, তবে তারা এটিকে আরও ছোট এবং আরও পরিচালনাযোগ্য করে তোলে। আপনি টুকরো টুকরো করে ছেড়ে দিতে পারেন, পর্যবেক্ষণ করতে পারেন, থামতে পারেন, ফিরে যেতে পারেন, শিখতে পারেন।
OpenFeature একটি পরিচ্ছন্ন ভিত্তি যোগ করে: একটি সাধারণ API, বিনিময়যোগ্য প্রদানকারী, এবং সিস্টেম বৃদ্ধির একটি সুশৃঙ্খল উপায়৷ কিন্তু শৃঙ্খলা আপনার থেকে যায়: নিরাপদ ডিফল্ট, পরিষ্কার নাম, মেট্রিক্স, মালিক এবং পরিচ্ছন্নতা।
সর্বোত্তম পতাকা হল একটি যা আপনাকে শান্তভাবে মুক্তি দিতে সাহায্য করে এবং তারপর অদৃশ্য হয়ে যায় যখন এটি আর প্রয়োজন হয় না।