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 একটি সাধারণ API দিয়ে feature flag মূল্যায়ন করার জন্য একটি উন্মুক্ত স্পেসিফিকেশন। ধারণাটি সহজ: আপনার অ্যাপ্লিকেশন কোড সরাসরি বিক্রেতা বা অভ্যন্তরীণ সিস্টেমের উপর নির্ভর করবে না যা আপনি পতাকার জন্য ব্যবহার করেন।
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- রানবুকে নথিভুক্ত;
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~
110ফ্রন্টএন্ড, ব্যাকএন্ড বা প্রান্ত? নির্ভর করে।
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~