ব্লু/গ্রীন ও ক্যানারি ডিপ্লয়মেন্ট: একটি স্পষ্ট রিলিজ স্ট্র্যাটেজি

ব্লু/গ্রীন এবং ক্যানারি ডিপ্লয়মেন্ট কী বোঝায়

নতুন কোড পাঠানো ঝুঁকিপূর্ণ—কারণ ব্যবহারকারীরা আসলে আছড়ে পড়লে কিভাবে আচরণ করবে তা আপনি সম্পূর্ণভাবে জানেন না। ব্লু/গ্রীন এবং ক্যানারি—এই দুইটি প্রচলিত উপায় ঝুঁকি কমায় এবং ডাউনটাইম শূন্যের কাছাকাছি রাখে।

সরল ভাষায় ব্লু/গ্রীন

একটি ব্লু/গ্রীন ডিপ্লয়মেন্ট দুইটি আলাদা কিন্তু অনুরূপ পরিবেশ ব্যবহার করে:

• Blue: বর্তমানে ব্যবহারকারীদের সার্ভ করা সংস্করণ ("লাইভ" সেটআপ)।
• Green: এক বিকল্প, প্রস্তুত পরিবেশ যেখানে নতুন সংস্করণ ডিপ্লয় করা হয়।

Green পটভূমিতে প্রস্তুত করা হয়—নতুন বিল্ড ডিপ্লয়, চেক চালানো, ওয়র্মআপ করা—তারপর আপনি আত্মবিশ্বাসী হলে Blue থেকে Green-এ ট্রাফিক সুইচ করেন। সমস্যা হলে দ্রুত ফিরে যাওয়া যায়।

মূল ধারণা হল “দুই রঙ” নয়, বরং একটি পরিষ্কার, উল্টে ফেলা যায় এমন কাটওভার।

সরল ভাষায় ক্যানারি

ক্যানারি রিলিজ হল ধাপে ধাপে রোলআউট। সবাইকে একবারে না পাঠিয়ে নতুন সংস্করণ প্রথমে একটি ছোট ব্যবহারকারী অংশে পাঠানো হয় (উদাহরণ: 1–5%)। সবকিছু ঠিক থাকলে ধাপে ধাপে বাড়িয়ে 100% করা হয়।

কী বলা হয় তা হল পূর্ণভাবে প্রতিশ্রুতি দেয়ার আগে বাস্তব ট্র্যাফিক থেকে শেখা।

সাধারণ লক্ষ্য: কম ঝুঁকি ও কম ডাউনটাইম

উভয় পদ্ধতির লক্ষ্য:

• কোনো সমস্যা হলে ব্যবহারকারীর উপর প্রভাব কমানো
• জিরো ডাউনটাইম ডিপ্লয় (অথবা আপনার সিস্টেম যতটা সম্ভব কাছে) সমর্থন করা
• রোলব্যাককে কম চাপযুক্ত এবং পূর্বানুমেয় করা

পদ্ধতিগুলো আলাদা উপায়ে এটা করে: ব্লু/গ্রীন দ্রুত পরিবেশ-পরিবর্তনের ওপর গুরুত্ব দেয়, ক্যানারি নিয়ন্ত্রিত এক্সপোজারের মাধ্যমে ট্রাফিক শিফটিং-এ বেশি জোর দেয়।

একক “সেরা” নেই

কোনও এক পদ্ধতি সবসময় সেরা নয়। সঠিক নির্বাচন নির্ভর করে প্রোডাক্ট কীভাবে ব্যবহার হয়, আপনি পরীক্ষায় কতটা আত্মবিশ্বাসী, কত দ্রুত ফিডব্যাক চান, এবং কোন ধরনের ত্রুটি এড়াতে চান।

অনেক দল দুটো মিশিয়ে ব্যবহার করে—অপারেশনাল সরলতার জন্য ব্লু/গ্রীন এবং ধাপে ধাপে এক্সপোজারের জন্য ক্যানারি টেকনিক।

পরবর্তী অংশগুলোতে আমরা সরাসরি তুলনা করবো এবং কোথায় কোনটি ভাল কাজ করে দেখাবো।

ব্লু/গ্রীন বনাম ক্যানারি: দ্রুত তুলনা

ব্লু/গ্রীন এবং ক্যানারি—উভয়ই ব্যবহারকারী বিঘ্ন না করেই পরিবর্তন রিলিজ করার উপায়, কিন্তু তারা আলাদা ভাবে ট্র্যাফিক নতুন সংস্করণে সরায়।

ট্র্যাফিক কিভাবে বদলে যায়

ব্লু/গ্রীন দুটি পূর্ণ পরিবেশ চালায়: "Blue" (বর্তমান) এবং "Green" (নতুন)। Green যাচাই করে আপনি সব ট্রাফিক একবারে সুইচ করেন—একটি নিয়ন্ত্রিত সুইচের মত।

ক্যানারি নতুন সংস্করণ প্রথমে ছোট একটি অংশে পাঠায় (উদাহরণ: 1–5%), তারপর বাস্তব পারফরম্যান্স পর্যবেক্ষণ করে ধীরে ধীরে ট্র্যাফিক বাড়ায়।

প্রাসঙ্গিক সুবিধা–অসুবিধা

নির্বাচন নির্দেশিকা

বড়, মাইগ্রেশন-জাতীয়, অথবা এমন রিলিজ যেখানে পুরনো বনাম নতুন স্পষ্টভাবে আলাদা থাকা দরকার—সেক্ষেত্রে ব্লু/গ্রীন বেছে নিন।

আপনি যদি ঘন ঘন শিপ করেন, বাস্তব ব্যবহার থেকে শেখা চান, এবং ব্লাস্ট রেডিয়াস কমাতে চান—তবে ক্যানারি বেছে নিন।

অনিশ্চিত হলে, অপারেশনাল সরলতার জন্য ব্লু/গ্রীন দিয়ে শুরু করুন, তারপর মনিটরিং ও রোলব্যাক অভ্যাস মজবুত হলে উচ্চ-ঝুঁকির সার্ভিসগুলিতে ক্যানারি যোগ করুন।

যখন ব্লু/গ্রীন সঠিক ফিট

ব্লু/গ্রীন ভাল বিকল্প যখন আপনি রিলিজকে "একটি সুইচ"এর মতো স্বচ্ছ এবং পূর্বানুমेय করতে চান। দুটি প্রোডাকশন-অনুরূপ পরিবেশ চালান: Blue (বর্তমান) এবং Green (নতুন)। Green যাচাই হলে ব্যবহারকারীদের туда রুট করুন।

প্রায়-জিরো ডাউনটাইম দরকার হলে

আপনার প্রোডাক্ট যদি দৃশ্যমান মেইনটেন্যান্স উইন্ডো সহ্য না করে—চেকআউট, বুকিং, লগ-ইন ড্যাশবোর্ড—তবে ব্লু/গ্রীন উপকারী কারণ নতুন সংস্করণ শুরু, ওয়ার্ম এবং চেক করা হয় ব্যাকগ্রাউন্ডে। বেশিরভাগ "ডিপ্লয় টাইম" গ্রাহকের সামনে নয়।

সবচেয়ে সহজ রোলব্যাক চাইলে

রোলব্যাক প্রায়শই শুধু ট্র্যাফিক আবার Blue-তে-কেন্দ্রিক করা। তা দরকারি যখন:

• রিলিজকে মিনিটের মধ্যে উল্টে দিতে হবে
• জরুরি হটফিক্সের চাপ এড়াতে চান
• একটি পরিষ্কার, পুনরাবৃত্তযোগ্য ব্যর্থতা প্রতিক্রিয়া চান

গুরুত্বপূর্ণ সুফল হল রোলব্যাক পুনর্নির্মাণ বা পুনঃডিপ্লয় ছাড়া ট্র্যাফিক সুইচ করেই করা যায়।

যখন ডাটাবেস পরিবর্তন সামঞ্জস্য রাখা যায়

ব্লু/গ্রীন সহজ থাকে যখন ডাটাবেস মাইগ্রেশন ব্যাকওয়ার্ড-কম্প্যাটিবল—কারণ স্বল্প সময় Blue এবং Green দুটোই থাকতে পারে (এবং কিভাবে পড়া/লেখা হবে তা আপনার রাউটিং ও জব সেটআপের উপর নির্ভর করে)।

ভালো ফিট:

• অ্যাডিটিভ স্কিমা পরিবর্তন (নতুন নাল-যোগ্য কলাম, নতুন টেবিল)
• ডাটা ফরম্যাট বাড়ানো যাতে পুরানো কোড উপেক্ষা করতে পারে

ঝুঁকিপূর্ণ ফিট: কলাম মুছা, ফিল্ড নাম বদলানো, বা মান বদলানো—এগুলো সুইচ ব্যাকের প্রতিশ্রুতি ভাঙতে পারে যদি আপনি বহু-ধাপ মাইগ্রেশন না করে থাকেন।

যদি দ্বৈত পরিবেশ ও রাউটিং কন্ট্রোল সামর্থ্য থাকে

ব্লু/গ্রীন অতিরিক্ত ক্যাপাসিটি (দুই স্ট্যাক) এবং ট্র্যাফিক নির্দেশ করার উপায় (লোড ব্যালান্সার, ইনগ্রেস, প্ল্যাটফর্ম রাউটিং) চায়। যদি আপনি স্বয়ংক্রিয়ভাবে পরিবেশ প্রোভিশন ও পরিষ্কার রাউটিং লেভার রাখেন, ব্লু/গ্রীন উচ্চ-আস্থা ও কম নাটকীয় রিলিজের জন্য ডিফল্ট হয়ে উঠতে পারে।

যখন ক্যানারি রিলিজ বেশি যুক্তিযুক্ত

ক্যানারি রিলিজ হল ধাপে ধাপে রোলআউট যেখানে প্রথমে কেবল ছোট অংশে পরিবর্তন দেখানো হয়, শেখা হয়, তারপর বাড়ানো হয়। এটি সেই সময়ে সঠিক যখন আপনি বড় শিশু ছাড়াই ঝুঁকি কমাতে চান।

প্রচুর ট্র্যাফিক এবং পরিষ্কার সিগন্যাল থাকলে

ক্যানারি উচ্চ-ট্র্যাফিক অ্যাপের জন্য শ্রেষ্ঠ কারণ কেবল 1–5% ট্র্যাফিকও দ্রুত অর্থপূর্ণ ডেটা দিতে পারে। যদি আপনি ইতিমধ্যে স্পষ্ট মেট্রিক্স (এরর রেট, ল্যাটেন্সি, কনভারশন, চেকআউট সম্পন্ন হওয়া) ট্র্যাক করেন, তাহলে বাস্তব ব্যবহার থেকে যাচাই করা যায়।

পারফরম্যান্স ও এজ-কেস নিয়ে চিন্তা থাকলে

কিছু সমস্যা কেবল বাস্তব লোডে প্রকাশ পায়: ধীর DB কোয়েরি, ক্যাশ মিস, আঞ্চলিক লেটেন্সি, বিরল ডিভাইস বা ইউজার ফ্লো। ক্যানারি দিয়ে আপনি নিশ্চিত করতে পারেন যে পরিবর্তন ত্রুটির হার বাড়াচ্ছে না বা পারফরম্যান্স খারাপ করছে না আগে সবাই পৌঁছানোর আগে।

পর্যায়ভিত্তিক রোলআউট দরকার হলে

আপনি যদি ঘন ঘন শিপ করেন, একাধিক টিম যুক্ত থাকে, বা এমন পরিবর্তন থাকে যা ধীরে ধীরে চালু করা যায় (UI টুইক, মূল্য পরীক্ষা, রিকমেন্ডেশন লজিক), ক্যানারি উপযুক্ত। 1% → 10% → 50% → 100% এইভাবে বাড়ান আপনার দেখা অনুযায়ী।

ফিচার ফ্ল্যাগ আপনার টুলকিটে থাকলে

ক্যানারি বিশেষভাবে ভালো কাজ করে ফিচার ফ্ল্যাগের সঙ্গে: কোড নিরাপদে ডিপ্লয় করে তারপর নির্দিষ্ট ব্যবহারকারীর সাবসেট, অঞ্চল, বা অ্যাকাউন্টের জন্য ফিচার চালু করা যায়। রোলব্যাকও কম নাটকীয়—অften আপনি একটি ফ্ল্যাগ বন্ধ করলেই হয়।

প্রগ্রেসিভ ডেলিভারির দিকে যাওয়ার পরিকল্পনা থাকলে ক্যানারি প্রায়শই নমনীয় শুরু বিন্দু।

See also: /blog/feature-flags-and-progressive-delivery

ট্রাফিক শিফটিং মৌলিক (সরল ভাষায়)

ট্রাফিক শিফটিং মানে হল কে নতুন সংস্করণ পাবে এবং কখন তা নিয়ন্ত্রণ করা। সবাইকে একসাথে না করে ধীরে ধীরে (বা নির্বাচিতভাবে) অনুরোধগুলো পুরনো থেকে নতুনে সরানো—এটাই ব্লু/গ্রীন ও ক্যানারির ব্যবহারিক মূল এবং এটিই জিরো ডাউনটাইম ডিপ্লয়কে বাস্তবসম্মত করে।

“স্টিয়ারিং হুইল”: ট্র্যাফিক কোথায় রাউট হয়

স্ট্যাকের কয়েকটি সাধারণ পয়েন্টে আপনি ট্রাফিক শিফট করতে পারেন। সঠিক পয়েন্ট আপনার চালানো পরিবেশ ও কত সূক্ষ্ম নিয়ন্ত্রণ লাগে তার ওপর নির্ভর করে।

• লোড ব্যালান্সার: ইনকামিং রিকোয়েস্ট দুই পরিবেশ বা সার্ভারের সেটের মধ্যে ভাগ করে।
• ইনগ্রেস কন্ট্রোলার (Kubernetes): নিয়ম অনুসারে ভিন্ন সার্ভিসে রুট করে।
• সার্ভিস মেশ: সাফ নিয়ম এবং ভাল দৃশ্যমানতা নিয়ে সার্ভিসগুলোর মধ্যে ট্রাফিক নিয়ন্ত্রণ করে।
• CDN / এজ রাউটিং: যখন আপনি ব্যবহারকারীর কাছাকাছি রাউটিং চান, ওয়েব ট্র্যাফিকের জন্য উপযোগী।

আপনাকে সব লেয়ারই দরকার নেই—একটি "সোর্স অব ট্রুথ" বেছে নিন যাতে আপনার রিলিজ ম্যানেজমেন্ট অনুমানহীন না হয়।

ট্র্যাফিক বিভাজনের সাধারণ উপায়

অধিকাংশ টিম এই পদ্ধতিগুলোর এক (বা মিশ্র) ব্যবহার করে ট্রাফিক শিফটিং-এর জন্য:

• পারসেন্টেজ-বেসড: 1% → 5% → 25% → 50% → 100% (ক্লাসিক ক্যানারি)\
• হেডার-বেসড: একটি নির্দিষ্ট হেডারযুক্ত অনুরোধ নতুন সংস্করণে পাঠানো হয় (QA টুল বা ইন্টারনাল টেস্টারদের জন্য)\
• ইউজার কোহর্ট: নির্দিষ্ট গ্রুপ—কর্মীরা, বিটা ব্যবহারকারী, একটি অঞ্চল, বা গ্রাহক স্তর—প্রথমে পরিবর্তন পায়

পারসেন্টেজ বোঝাতে সহজ, কিন্তু কোহর্ট অনেক সময় নিরাপদ—কারণ আপনি নির্ধারণ করতে পারেন কাদের পরিবর্তন দেখা যাবে (এবং প্রথম ঘন্টায় আপনার বড় গ্রাহকদের বিস্ময়কর না করার বিষয়টি নিয়ন্ত্রণ করতে পারেন)।

সেশন ও ক্যাশ: দুটো “গটচা”

দুই জিনিস সাধারণত ভাল পরিকল্পনাকেও ভেঙে দেয়:

স্টিকি সেশন (সেশন অ্যাফিনিটি). যদি সিস্টেম একটি ব্যবহারকারীকে একটি নির্দিষ্ট সার্ভার/সংস্করণে বাঁধা করে, একটি 10% ট্র্যাফিক বিভাজন 10% এর মত আচরণ নাও করতে পারে। ব্যবহারকারী যদি সংস্করণগুলোর মধ্যে ঝাঁপিয়ে পড়ে তখন বিভ্রান্তিকর বাগও দেখা দিতে পারে। সম্ভব হলে শেয়ার্ড সেশন স্টোর বা নিশ্চিত করুন রাউটিং ব্যবহারকারীকে ধারাবাহিকভাবে একই সংস্করণে রাখে।

ক্যাশ ওয়ার্মিং। নতুন সংস্করণ প্রায়ই ঠান্ডা ক্যাশে আঘাত করে (CDN, অ্যাপ ক্যাশ, DB কোয়েরি ক্যাশ)। এতে পারফরম্যান্স রিগ্রেশন মনে হতে পারে যদিও কোড ঠিক আছে। উচ্চ-ট্র্যাফিক পেজ ও ব্যয়বহুল এন্ডপয়েন্টগুলোর জন্য র্যাম্প করার আগে ক্যাশ গরম করার সময় প্ল্যান করুন।

ট্রাফিক পরিবর্তনকে নিয়ন্ত্রিত অপারেশন হিসাবে আচরণ করুন

রাউটিং পরিবর্তনগুলোকে উৎপাদন পরিবর্তন হিসেবেই বিবেচনা করুন, কোনো এলোমেলো বোতাম ক্লিক নয়।

দলিল করুন:

• কে ট্র্যাফিক স্প্লিট পরিবর্তন করতে পারে
• কিভাবে এটি অনুমোদিত (অন-কল? রিলিজ ম্যানেজার? চেঞ্জ টিকিট?)
• কোথায় এটি করা হয় (লোড ব্যালান্সার কনফিগ, ইনগ্রেস নিয়ম, মেশ পলিসি)
• "স্টপ" কেমন দেখায় (রোলআউট থামাতে এবং রোলব্যাক প্ল্যান অনুসরণ করার ট্রিগার)

এই ছোট গবর্ন্যান্সটি ভাল ইচ্ছুক মানুষকে "ইতিমধ্যেই 50% করে দাও" বলতে বাধা দেয় যখন আপনি এখনও ক্যানারি সুস্থ কিনা খুঁজছেন।

রোলআউটের সময় কী মনিটর করবেন

রোলআউট শুধু "ডিপ্লয় সফল হলে হ্যাঁ/না" নয়—এটি হল "বাস্তব ব্যবহারকারীরা কি খারাপ অভিজ্ঞতা পাচ্ছে?" ব্লু/গ্রীন বা ক্যানারি চলাকালীন শান্ত থাকার সহজ উপায় হল কয়েকটি সিগন্যাল দেখার যারা বলে: সিস্টেম কি স্বাস্থ্যবান, এবং পরিবর্তন কি গ্রাহকদের ক্ষতিগ্রস্ত করছে?

চারটি মূল সিগন্যাল: এরর, ল্যাটেন্সি, স্যাচুরেশন, ব্যবহারকারী-প্রভাব

এরর রেট: HTTP 5xx, রিকোয়েস্ট ব্যর্থতা, টাইমআউট, এবং ডিপেন্ডেন্সি এরর (DB, পেমেন্ট, থার্ড-পার্টি)। একটি ক্যানারি যা "ছোট" এরর বাড়ায় তবুও সমর্থন বোঝার উপর বড় প্রভাব ফেলতে পারে।

ল্যাটেন্সি: p50 ও p95 (আরো থাকলে p99)। গড় ল্যাটেন্সি স্থিতিশীল থাকলেও লং-টেইল স্লোগ দেখে ব্যবহারকারীরা অনুভব করতে পারেন।

স্যাচুরেশন: সিস্টেম কতটা "ভরা"—CPU, মেমরি, ডিস্ক IO, DB কানেকশন, কিউ গভীরতা, থ্রেড পুল। স্যাচুরেশন সমস্যা প্রায়ই ফুল আউটের আগে দেখা দেয়।

ব্যবহারকারী-প্রভাব সিগন্যাল: ব্যবহারকারীরা আসলে কি পাচ্ছে—চেকআউট ব্যর্থতা, সাইন-ইন সাকসেস রেট, সার্চ ফলাফল, অ্যাপ ক্র্যাশ রেট, মূল পেজ লোড টাইম। এগুলো অবকাঠামো স্ট্যাটস থেকে বেশি অর্থবহ হতে পারে।

"রিলিজ ড্যাশবোর্ড" তৈরি করুন যে সবাই পড়তে পারে

একটি ছোট ড্যাশবোর্ড বানান যা একটি স্ক্রীনে ফিট করে এবং আপনার রিলিজ চ্যানেলে শেয়ার করা হয়। প্রতিটি রোলআউটে এটি ধারাবাহিক রাখুন যাতে মানুষ গ্রাফ খুঁজে পেতে সময় নষ্ট না করে।

শামিল করুন:

• এরর রেট (সমগ্র + মূল এন্ডপয়েন্ট)\
• ল্যাটেন্সি (ক্রিটিক্যাল পথের p50/p95)\
• স্যাচুরেশন (স্ট্যাকের শীর্ষ ৩ সীমাবদ্ধতা, উদাহরণ: অ্যাপ CPU, DB কানেকশন, কিউ গভীরতা)\
• ব্যবহারকারী-প্রভাব KPIs (আপনার শীর্ষ 1–3 ব্যবসায়িক-গুরুত্বপূর্ণ ফ্লোগুলি)

যদি আপনি ক্যানারি রিলিজ চালান, সংস্করণ/ইনস্ট্যান্স গ্রুপ অনুযায়ী মেট্রিকস সেগমেন্ট করুন যাতে ক্যানারি বনাম বেসলাইন সরাসরি তুলনা করা যায়। ব্লু/গ্রীন-এর জন্য, কাটওভারের সময় নতুন পরিবেশ বনাম পুরোনো তুলনা করুন।

বিরতি/রোলব্যাক সিদ্ধান্তের জন্য পরিষ্কার থ্রেশহোল্ড নির্ধারণ করুন

শুরু করার আগে নিয়মগুলো ঠিক করুন। উদাহরণ থ্রেশহোল্ড:

• এরর রেট baseline থেকে X% বাড়লে Y মিনিট ধরে\
• p95 ল্যাটেন্সি একটি নির্দিষ্ট সীমা ছাড়িয়ে গেলে (অথবা baseline থেকে X% বাড়লে)\
• একটি ব্যবহারকারী-প্রভাব KPI একটি গ্রহণযোগ্য ন্যূনতম মানের নিচে নেমে গেলে

নির্দিষ্ট সংখ্যাগুলো সার্ভিসের উপর নির্ভর করবে, কিন্তু গুরুত্বপূর্ণ অংশ হল সম্মতি। যদি সবাই রোলব্যাক প্ল্যান ও ট্রিগার জানে, গ্রাহকের ক্ষতি চলার সময় বিতর্ক হওয়া এড়ায়।

রোলআউট উইন্ডোর জন্য আলাদা অ্যালার্ট

রোলআউট চলাকালীন (অথবা সাময়িকভাবে) অ্যালার্টগুলো কষে দিন:

• 5xx/টাইমআউটের অপ্রত্যাশিত স্পাইক\
• গুরুত্বপূর্ণ রুটগুলোর মৃত্যু ল্যাটেন্সি রিগ্রেশন\
• কনেকশন পুল, কিউ দ্রুত বাড়া—স্যাচুরেশন সিগন্যাল

অ্যালার্টগুলো কার্যকরী রাখুন: “কি পরিবর্তিত হয়েছে, কোথায়, এবং পরবর্তী কী।” যদি অ্যালার্টিং গোলমাল হয়, মানুষ রোলআউটের সময় যে একটাই সিগন্যাল দরকার তা মিস করবে।

প্রি-রিলিজ চেকস যা সমস্য ধরা দেয়

অধিকাংশ রোলআউট ব্যর্থতা বড় বাগের কারণে নয়। ছোট অসামঞ্জস্য—ভুল কনফিগ, খারাপ DB মাইগ্রেশন, মেয়াদোত্তীর্ণ সার্টিফিকেট, অথবা ইন্টিগ্রেশন যা নতুন পরিবেশে ভিন্ন আচরণ করে—এসবই সমস্যার মূল। প্রি-রিলিজ চেকগুলো এইসব ধরা দেয় যেখানে ব্লাস্ট রেডিয়াস এখনও ছোট।

হেলথ চেক ও স্মোক টেস্ট দিয়ে শুরু করুন

কোন ট্রাফিক শিফট করার আগে (ব্লু/গ্রীন সুইচ হোক বা ছোট ক্যানারি শতাংশ), নিশ্চিত করুন নতুন সংস্করণ বেসিকভাবে জীবিত এবং অনুরোধ সার্ভ করতে সক্ষম।

• অ্যাপ হেলথ এন্ডপয়েন্টগুলো OK রিপোর্ট করছে কি না (শুধু প্রসেস চলছে কি না নয়)\
• ডিপেন্ডেন্সি যাচাই: DB, ক্যাশ, কিউ, অবজেক্ট স্টোরেজ, ইমেইল/SMS প্রদানকারী\
• সিক্রেট ও এনভায়রনমেন্ট ভ্যারিয়েবল সঠিকভাবে আছে কি না

নতুন পরিবেশে দ্রুত এন্ড-টু-এন্ড টেস্ট চালান

ইউনিট টেস্ট ভালো, কিন্তু ডিপ্লয় করা সিস্টেম কাজ করে কি না প্রমাণ করে না। নতুন পরিবেশে মিনিটে শেষ হওয়া ছোট, স্বয়ংক্রিয় এন্ড-টু-এন্ড স্যুট চালান।

সার্ভিস-বাউন্ডারি অতিক্রম করা ফ্লোতে ফোকাস করুন (ওয়েব → API → DB → থার্ড-পার্টি) এবং প্রতিটি কী ইন্টিগ্রেশনের জন্য কমপক্ষে একটি "রিয়েল" অনুরোধ অন্তর্ভুক্ত করুন।

ক্রিটিক্যাল ইউজার জার্নি যাচাই করুন

স্বয়ংক্রিয় টেস্ট কখনোই সবকিছু ধরতে পারে না। আপনার মূল জার্নির লক্ষ্যভিত্তিক, মানুষের সহজ যাচাইকরণ করুন:

• লগইন ও পাসওয়ার্ড রিসেট\
• চেকআউট বা পেমেন্ট ফ্লো (ফেইল পাথসহ)\
• দৈনন্দিনভাবে ব্যবহারকারীরা যে ক্রিয়াগুলো করে (create/update/delete)

বহু ভূমিকা (অ্যাডমিন বনাম কাস্টমার) থাকলে প্রতিটি ভূমিকার জন্য অন্তত একটি জার্নি নমুনা করুন।

প্রি-রিলিজ রেডিনেস চেকলিস্ট রাখুন

চেকলিস্ট ট্রাইবাল জ্ঞানকে পুনরাবৃত্তিযোগ্য কৌশলে রূপান্তর করে। সংক্ষিপ্ত এবং কার্যকর রাখুন:

• ডাটাবেস মাইগ্রেশন প্রয়োগ এবং উল্টানো যোগ্য (অথবা স্পষ্টভাবে নিরাপদ)\
• অবজারভেবিলিটি প্রস্তুত: লগ, ড্যাশবোর্ড, কী মেট্রিক্সের জন্য অ্যালার্ট\
• রোলব্যাক প্ল্যান রিভিউড (কে, কিভাবে, এবং "স্টপ" কেমন)

চেকগুলো রুটিন হলে ট্রাফিক শিফটিং একটি নিয়ন্ত্রিত ধাপ হয়ে যায়—বিশ্বাসের ঝাঁপ নয়।

ব্লু/গ্রীন রোলআউট: ব্যবহারিক প্লেবুক

ব্লু/গ্রীন রোলআউট চালানো সহজ যখন আপনি এটিকে চেকলিস্ট হিসেবে আচরণ করেন: প্রস্তুত, ডিপ্লয়, যাচাই, সুইচ, পর্যবেক্ষণ, তারপর ক্লিনআপ।

1) Green-এ ডিপ্লয় (ব্যবহারকারীদের ছোঁয় না)

নতুন সংস্করণ Green পরিবেশে পাঠান যখন Blue বাস্তব ট্রাফিক সার্ভ করে। কনফিগ ও সিক্রেট সঙ্গত রাখুন যাতে Green প্রকৃত মিরর হয়।

2) ট্রাফিক সুইচ করার আগে Green যাচাই করুন

দ্রুত, উচ্চ-সংকেত চেক করুন: অ্যাপ ঠিকভাবে শুরু হচ্ছে কি না, মূল পেজ লোড হচ্ছে কি না, পেমেন্ট/লগইন কাজ করছে কি না, লগস স্বাভাবিক দেখাচ্ছে কি না। যদি অটোমেটেড স্মোক টেস্ট থাকে, এখন চালান। Green-এর জন্য মনিটরিং ড্যাশবোর্ড ও অ্যালার্ট সক্রিয় আছে কি তাও যাচাই করুন।

3) ডাটাবেস মাইগ্রেশনের নিরাপদ পরিকল্পনা (এক্সপ্যান্ড/কনট্র্যাক্ট)

ব্লু/গ্রীন ডাটাবেস পরিবর্তনে জটিল হয়। এক্সপ্যান্ড/কনট্র্যাক্ট পন্থা ব্যবহার করুন:

• Expand: নতুন কলাম/টেবিল ব্যাকওয়ার্ড-কম্প্যাটিবলভাবে যোগ করুন।\
• Green-এ ডিপ্লয় করুন যাতে এটি পুরোনো ও নতুন স্কিমা উভয়ের সঙ্গে কাজ করতে পারে।\
• Contract: Blue অবসান করার পরে পুরানো ফিল্ড সরান যখন আপনি নিশ্চিত নতুন কোড স্থিতিশীল।

এটা "Green কাজ করে, Blue নষ্ট" পরিস্থিতি এড়ায়।

4) ক্যাশ ও ব্যাকগ্রাউন্ড জবগুলো পরিচালনা

ট্রাফিক সুইচের আগে গুরুত্বপূর্ণ ক্যাশ গরম করুন (হোম পেজ, কমন কোয়েরি) যাতে ব্যবহারকারীরা "কোল্ড স্টার্ট" খরচ না ভোগ করে।

ব্যাকগ্রাউন্ড জব/ক্রোন ওয়ার্কারদের জন্য সিদ্ধান্ত নিন:

• কাটওভারের সময় একই পরিবেশেই জব চালান যাতে ডাবল-প্রসেসিং না হয়

5) ট্রাফিক সুইচ করুন, তারপর পর্যবেক্ষণ করুন

Blue থেকে Green-এ রাউটিং ফ্লিপ করুন (লোড ব্যালান্সার/DNS/ইনগ্রেস)। একটি সংক্ষিপ্ত উইন্ডোতে এরর রেট, ল্যাটেন্সি, এবং ব্যবসায়িক মেট্রিক্স দেখুন।

6) পোস্ট-সুইচ যাচাই ও ক্লিনআপ

একটি বাস্তব-ব্যবহারকারী স্টাইল স্পট চেক করুন, তারপর Blue-কে সংক্ষিপ্ত সময় ব্যাকআপ হিসেবে রাখুন। স্থিতিশীল হলে Blue জবগুলো ডিসেবল করুন, লগ আর্কাইভ করুন, এবং খরচ ও বিভ্রান্তি কমানোর জন্য Blue ডিপ্রোভিশন করুন।

ক্যানারি রোলআউট: ব্যবহারিক প্লেবুক

ক্যানারি রোলআউট শেখার উপর ভিত্তি করে। সব ব্যবহারকারীর কাছে একসাথে না পাঠিয়ে একটি ছোট ট্র্যাফিক অংশে এক্সপোজ করুন, ঘনিষ্ঠভাবে দেখুন, তারপর বাড়ান। লক্ষ্য ধীরে যাওয়া নয়—প্রতিটি ধাপে প্রমাণ করা যে এটি নিরাপদ।

সহজ র্যাম্প পরিকল্পনা (1–5% → 25% → 50% → 100%)

1. ক্যানারি প্রস্তুত করুন

নতুন সংস্করণ স্থিতিশীল সংস্করণের পাশে ডিপ্লয় করুন। নিশ্চিত করুন নির্ধারিত শতাংশ ট্র্যাফিক প্রতিটি সংস্করণে রুট করা যায় এবং উভয় সংস্করণ মনিটরিং-এ দেখা যায় (ভিন্ন ড্যাশবোর্ড/ট্যাগ সহ সুবিধা করে)।

2. স্টেজ 1: 1–5%

খুব ছোট থেকে শুরু করুন। এখানে দ্রুত ধরা পড়ে: ভাঙা এন্ডপয়েন্ট, অনুপস্থিত কনফিগ, DB মাইগ্রেশন সমস্যা, অথবা অনাকাঙ্ক্ষিত ল্যাটেন্সি।

এই পর্যায়ের জন্য নোট রাখুন:

• রিলিজে কি পরিবর্তিত হয়েছে (ছোট কনফিগ পরিবর্তন সহ)\
• আপনি কী প্রত্যাশা করেছিলেন\
• আপনি কী লক্ষ্য করেছেন (এরর, ল্যাটেন্সি, ব্যবহারকারী-প্রভাব)

3. স্টেজ 2: 25%

প্রথম ধাপ সাফ থাকলে প্রায় এক চতুর্থাংশ ট্র্যাফিকে বাড়ান। এখন আপনি আরো বাস্তব-বিবিধতা দেখবেন: বিভিন্ন ব্যবহারকারী আচরণ, লং-টেইল ডিভাইস, এজ-কেস, বেশি কনকারেন্সি।

4. স্টেজ 3: 50%

অর্ধেক ট্র্যাফিক পারফরম্যান্স ও ক্যাপাসিটি ইস্যুগুলোকে আরও স্পষ্ট করে তোলে। যদি আপনি কোনো স্কেলিং সীমাতে পৌঁছাতে যাচ্ছেন, প্রায়শই এখানেই প্রাথমিক সতর্ক সংকেত দেখা যায়।

5. স্টেজ 4: 100% (প্রোমোশন)

যখন মেট্রিকস স্থিতিশীল এবং ব্যবহারকারী-প্রভাব গ্রহণযোগ্য, সব ট্র্যাফিক নতুন সংস্করণে শিফট করুন এবং এটি প্রোমোটড ঘোষণা করুন।

র্যাম্প ইন্টারভাল কিভাবে বেছে নেবেন

র্যাম্প টাইম নির্ভর করে ঝুঁকি ও ট্র্যাফিক ভলিউম-এর উপর:

• উচ্চ-ঝুঁকির পরিবর্তন বা কম ট্র্যাফিক: প্রতিটি ধাপে বেশি অপেক্ষা করুন যাতে পর্যাপ্ত সিগন্যাল পাওয়া যায় (উদাহরণ: 30–60 মিনিট বা তার বেশি)। কম-ট্র্যাফিক সার্ভিসগুলোতে ঘণ্টা লাগতে পারে অর্থপূর্ণ প্যাটার্ন দেখার জন্য।\
• কম-ঝুঁকি পরিবর্তন ও উচ্চ ট্র্যাফিক: সংক্ষিপ্ত স্টেজ কাজ করবে (উদাহরণ: 5–15 মিনিট), কারণ দ্রুত ডেটা সংগ্রহ হয়।

বিজনেস সাইকেলও বিবেচনা করুন—যদি আপনার প্রোডাক্টে স্পাইক থাকে (লাঞ্চটাইম, উইকএন্ড, বিলিং রান) তাহলে ক্যানারি পর্যাপ্ত সময় চালান যাতে সাধারণত সমস্যার কারণগুলো কভার হয়।

প্রোমোশন ও রোলব্যাক স্বয়ংক্রিয় করুন

ম্যানুয়াল রোলআউট দ্বিধা ও অসামঞ্জস্য তৈরি করে। সম্ভব হলে স্বয়ংক্রিয় করুন:

• কী মেট্রিকস নির্দিষ্ট উইন্ডোতে থ্রেশহোল্ডের মধ্যে থাকলে প্রোমোট করা\
• থ্রেশহোল্ড লঙ্ঘিত হলে রোলব্যাক করা (উদাহরণ: এরর রেট বা ল্যাটেন্সি সীমা ক্রস করলে)

স্বয়ংক্রিয়তা মানুষের বিচার দূর করে না—কিন্তু দেরি সরিয়ে দেয়।

প্রতিটি ধাপকে একটি পরীক্ষা হিসেবে বিবেচনা করুন

প্রতিটি র্যাম্প স্টেপের জন্য লিখে রাখুন:

• পরিবর্তন সারাংশ (ঠিক কী ভিন্ন)\
• সাফল্য মাপকাঠি (কোন মেট্রিক স্থিতিশীল থাকতে হবে)\
• পর্যবেক্ষিত ফলাফল (আপনি কি দেখলেন, এমনকি "কিছু অস্বাভাবিক নেই")\
• ফয়সলা (প্রোমোট, হোল্ড, বা রোলব্যাক) এবং কেন

এই নোটগুলো আপনার রোলআউট ইতিহাসকে পরবর্তী রিলিজের জন্য একটি প্লেবুক বানায়—এবং ভবিষ্যৎ ঘটনার ডায়াগনসিস সহজ করে।

রোলব্যাক পরিকল্পনা ও ব্যর্থতা হ্যান্ডলিং

রোলব্যাক সহজ হয় যখন আপনি আগেই নির্ধারণ করেন "খারাপ" কি এবং কে বোতাম টিপতে পারবে। রোলব্যাক পরিকল্পনা বিরোধিতা নয়—এটি কিভাবে ছোট সমস্যাকে দীর্ঘ প্রতিকূলতায় পরিণত হওয়া থেকে রোধ করা যায়।

পরিষ্কার রোলব্যাক ট্রিগার নির্ধারণ করুন

কিছু সিগন্যাল বেছে নিন এবং নির explicit থ্রেশহোল্ড দিন যাতে ঘটনার সময় বিতর্ক না হয়। সাধারণ ট্রিগার:

• এরর রেট: 5xx স্পাইক, ব্যর্থ চেকআউট, লগইন ব্যর্থতা, API টাইমআউট\
• ল্যাটেন্সি: p95/p99 একটি সম্মত সীমা ছাড়িয়ে যাওয়া একটি টেকসই উইন্ডোর জন্য (উদাহরণ: 5–10 মিনিট)\
• ব্যবসায়িক KPI: কনভার্শন হঠাৎ কমে যাওয়া, পেমেন্ট সাকসেস কমা, সাইন-আপ কমা

ট্রিগার পরিমাপযোগ্য রাখুন ("p95 > 800ms for 10 minutes") এবং একটি মালিক (অন-কলে থাকা, রিলিজ ম্যানেজার) নির্ধারণ করুন যার কাছে তাৎক্ষণিকভাবে কাজ করার অনুমতি আছে।

রোলব্যাক দ্রুত (এবং বিরক্তিকর নয়) রাখুন

গতিতে সৌন্দর্য নয়—দ্রুততা জরুরি। আপনার রোলব্যাক হওয়া উচিত:

• ট্রাফিক শিফট উল্টে দেওয়া (ব্লু/গ্রীন ও ক্যানারির জন্য সাধারণ): ট্রাফিককে পূর্বের, জানা-ভালো সংস্করণে ফেরানো\
• পূর্ববর্তী সংস্করণ পুনরায় ডিপ্লয়: যদি ইনফ্রা বদলায়, শেষ স্থিতিশীল বিল্ড ঠেলে দিন এবং হেলথ চেক পুনরায় চালান

"ম্যানুয়াল ফিক্স করে রোলআউট চালিয়ে যাওয়া" প্রথম পদক্ষেপ বানিয়ে রাখবেন না। আগে স্থিতিশীল করুন, পরে তদন্ত করুন।

আংশিক রোলআউটের পরিকল্পনাও রাখুন

ক্যানারি অবস্থায় কিছু ব্যবহারকারী নতুন সংস্করণে ডেটা সৃষ্টি করতে পারে। আগেই সিদ্ধান্ত নিন:

• "ক্যানারি" ব্যবহারকারীদের কি তাৎক্ষণিকভাবে ফিরিয়ে দেওয়া হবে, না কি পর্যালোচনা চলাকালীন তারা ক্যানারিতে থাকবে?\
• যদি ডেটা ফরম্যাট পরিবর্তিত হয়, ডাটাবেস ব্যাকওয়ার্ড-কম্প্যাটিবল না হলে রোলব্যাক আলাদা ব্যবস্থাপনা প্রয়োজন।

পরবর্তী-কার্য (after-action) রিভিউ

স্থিতিশীল হওয়ার পরে সংক্ষিপ্ত পরবর্তী-কার্য নোট লিখুন: রোলব্যাক কী ট্রিগার করল, কোন সিগন্যাল অনুপস্থিত ছিল, এবং পরবর্তী রিলিজে চেকলিস্টে কী পরিবর্তন করা হবে। এটাকে ব্লেম করার নয়, রিলিজ প্রক্রিয়া উন্নত করার একটি প্রোডাক্ট সাইকেলে পরিণত করুন।

ফিচার ফ্ল্যাগ এবং প্রগ্রেসিভ ডেলিভারি

ফিচার ফ্ল্যাগ আপনাকে ডিপ্লয় (প্রোডাকশনে কোড পাঠানো) এবং রিলিজ (মানুষকে চালু করা) আলাদা করতে দেয়। এটি বড় কারণ একই ডিপ্লয়মেন্ট পাইপলাইন—ব্লু/গ্রীন অথবা ক্যানারি—ব্যবহার করে একেবারে সহজে এক্সপোজার নিয়ন্ত্রণ করা যায়।

চাপ ছাড়া ডিপ্লয়, উদ্দেশ্য সহ রিলিজ

ফ্ল্যাগ দিয়ে আপনি মিশে এবং ডিপ্লয় করতে পারেন এমনকি একটি ফিচার সবাইয়ের জন্য প্রস্তুত না থাকলেও। কোড আছে কিন্তু নিষ্ক্রিয়। আত্মবিশ্বাস হলে ধীরে চালু করুন—অften একটি নতুন বিল্ড পুশ করার চেয়ে দ্রুত—আর সমস্যা হলে ফ্ল্যাগ বন্ধ করলেই হয়।

লক্ষ্যভিত্তিক সক্ষমকরণ (সব-বা-কিছু নয়)

প্রগ্রেসিভ ডেলিভারি মানে ধাপে ধাপে প্রবেশাধিকার বাড়ানো। একটি ফ্ল্যাগ চালু করা যায়:

• নির্দিষ্ট ব্যবহারকারী গ্রুপে (ইন্টার্নাল কর্মী, বিটা ব্যবহারকারী, পেইড টিয়ার)\
• একটি অঞ্চলে (এক দেশ বা ডাটা সেন্টার থেকে শুরু)\
• ব্যবহারকারীর শতাংশ হিসেবে (1% → 10% → 50% → 100%)

যদি ক্যানারি রিলিজ আপনাকে বলে নতুন সংস্করণ সুস্থ, তবুও আপনি ফিচারের ঝুঁকি আলাদাভাবে পরিচালনা করতে চান—তেমন ক্ষেত্রে এটি বিশেষভাবে উপযোগী।

“ফ্ল্যাগ ডেট” এড়ানোর গার্ডরেইল

ফিচার ফ্ল্যাগ শক্তিশালী, কিন্তু শাসিত না হলে খারাপ। কয়েকটি গার্ডরেইল:

• মালিকানা: প্রতিটি ফ্ল্যাগের জন্য একটি দায়ী দল বা ব্যক্তি থাকুক\
• মেয়াদ: একটি অপসারণ বা রিভিউ তারিখ দিন যাতে পুরোনো ফ্ল্যাগ জমে না যায়\
• ডকুমেন্টেশন: ফ্ল্যাগ কি করে, কাকে ছোঁয়, এবং কিভাবে রোলব্যাক করবেন লিখে রাখুন

একটি বাস্তবিক নিয়ম: যদি কেউ "ফ্ল্যাগ বন্ধ করলে কি হবে?" উত্তর দিতে না পারে, ফ্ল্যাগটি প্রস্তুত নয়।

For deeper guidance on using flags as part of a release strategy, see /blog/feature-flags-release-strategy.

কিভাবে কৌশল বেছে নেবেন এবং শুরু করবেন

ব্লু/গ্রীন বনাম ক্যানারি বেছে নেওয়া "কি ভাল" নিয়ে নয়। এটা নির্ভর করে আপনি কোন ঝুঁকি নিয়ন্ত্রণ করতে চান, এবং আপনার দল ও টুলিং-এর সাথে বাস্তবভাবে কি চালানো যায়।

দ্রুত সিদ্ধান্ত নেবার উপায়

আপনি যদি সবচেয়ে প্রাধান্য দেন একটি পরিষ্কার, পূর্বানুমেয় কাটওভার এবং সহজ "পুরোনো সংস্করণে ফিরে যাওয়ার" বোতাম—ব্লু/গ্রীন সাধারণত সহজ ফিট।

আপনি যদি ব্লাস্ট রেডিয়াস কমাতে এবং বাস্তব ট্র্যাফিক থেকে আগে শেখতে চান—ক্যানারি নিরাপদ ফিট, বিশেষ করে যখন পরিবর্তন ঘন বা পরীক্ষায় কঠিন।

ব্যবহারিক নিয়ম: এমন পদ্ধতি বেছে নিন যেটি আপনার দল রাত 2টার সময়ও ধারাবাহিকভাবে চালাতে পারে যখন কিছু ভুল হচ্ছে।

ছোট থেকে শুরু করুন: একটি পাইলট

একটি সার্ভিস (বা এক ইউজার-ফেসিং ওয়ার্কফ্লো) বেছে নিন এবং কয়েকটি রিলিজে একটি পাইলট চালান। এমন কিছু বেছে নিন যা যথেষ্ট গুরুত্বপূর্ণ কিন্তু অতিরিক্ত সমালোচ্য না—লক্ষ্য হল ট্রাফিক শিফটিং, মনিটরিং, এবং রোলব্যাক নিয়ে মন muscle গড়া।

একটি সোজা রানবুক লিখুন (এবং মালিক নির্ধারণ)

সংক্ষিপ্ত রাখুন—এক পৃষ্ঠা চলবে:

• কি “ভালো” দেখায় (কী মেট্রিক্স ও থ্রেশহোল্ড)\
• রোলআউট চলাকালীন কে দায়িত্বে থাকবে\
• কিভাবে থামাবেন, রোলব্যাক করবেন, এবং যোগাযোগ করবেন

মালিকানা নিশ্চিত করুন। মালিক ছাড়া কৌশল কেবল একটি পরামর্শ থাকে।

প্রথমে আপনার যা আছে তাই ব্যবহার করুন

নতুন প্ল্যাটফর্ম যোগ করার আগে আপনার বিদ্যমান টুলগুলো দেখুন: লোড ব্যালান্সার সেটিংস, ডিপ্লয়মেন্ট স্ক্রিপ্ট, বিদ্যমান মনিটরিং, এবং আপনার ইনসিডেন্ট প্রসেস। পাইলটে অনুভব করা বাস্তব কষ্ট না সারানোর ক্ষেত্রে নতুন টুল যোগ করুন।

যদি আপনি দ্রুত নতুন সার্ভিস তৈরি ও শিপ করেন, তাহলে এমন প্ল্যাটফর্ম যা অ্যাপ জেনারেশন ও ডিপ্লয়মেন্ট কন্ট্রোল একত্র করে অপারেশনাল ঘর্ষণ কমাতে পারে। উদাহরণস্বরূপ, Koder.ai একটি ভিব-কোডিং প্ল্যাটফর্ম যা টিমগুলোকে চ্যাট ইন্টারফেস থেকে ওয়েব, ব্যাকএন্ড, মোবাইল অ্যাপ তৈরি করতে দেয়—এবং তারপর ডিপ্লয় ও হোস্ট করার জন্য নিরাপত্তা বৈশিষ্ট্য (স্ন্যাপশট ও রোলব্যাক সহ), কাস্টম ডোমেইন ও সোর্স কোড এক্সপোর্ট সমর্থন করে। এই সক্ষমতাগুলো লেখার মূল লক্ষ্যকে মাপে: রিলিজগুলো পুনরাবৃত্তিযোগ্য, পর্যবেক্ষণযোগ্য, এবং উল্টে ফেলা যায় এমন করে তোলা।

পরামর্শিত পরবর্তী ধাপ

ইমপ্লিমেন্টেশন অপশন ও সমর্থিত ওয়ার্কফ্লো দেখতে /pricing এবং /docs/deployments পর্যালোচনা করুন। তারপর আপনার প্রথম পাইলট রিলিজ নির্ধারণ করুন, কাজগুলো নোট করুন, এবং প্রতিটি রোলআউটের পরে রানবুক ইটারেট করুন।