Deployment Strategy: rolling, blue-green ও canary

এই পাঠে যা শিখবেন

• Rolling, blue-green ও canary তুলনা করা
• Mixed-version compatibility বোঝা
• Release থামানোর measurable rule লেখা

সমস্যা দিয়ে শুরু

নতুন checkout version deploy করার সময় সব instance একসঙ্গে restart হলো। User-এর cart request মাঝপথে কেটে গেল। আরেক release-এ শুধু কিছু user payment error দেখলেন। Deployment strategy traffic ও version overlap নিয়ন্ত্রণ করে; সঠিক strategy নির্বাচন করলে failure-এর বিস্তার ও rollback সময় কমানো যায়। কিন্তু database change irreversible হলে শুধু traffic পুরোনো version-এ ফেরালেই recovery হয় না।

সহজ করে বুঝি

Rolling deployment ধাপে replica replace করে। Blue-green-এ দুটি environment প্রস্তুত রেখে traffic switch হয়। Canary-তে ছোট traffic slice নতুন version পায়, পর্যবেক্ষণ ভালো হলে বাড়ে। তিন ক্ষেত্রেই readiness, drain এবং compatibility গুরুত্বপূর্ণ। Canary random percentage ছাড়াও tenant বা internal cohort দিয়ে হতে পারে; selection bias থাকলে error signal representative নাও হতে পারে।

পরিচিত একটি উপমা

নতুন রান্নার পদ্ধতি একসঙ্গে সব দোকানে চালু করার বদলে একটি শাখায় আগে পরীক্ষা করার মতো। Blue-green হলো প্রস্তুত দ্বিতীয় রান্নাঘরে order সরানো। পুরোনো ও নতুন kitchen একই stock ব্যবহার করলে হিসাবের format দুইজনকেই বুঝতে হবে।

নকশাটি দেখুন

flowchart TD
 L[Traffic router] -->|Most requests| O[Stable release]
 L -->|Small cohort| N[Canary release]
 O --> D[(Compatible database)]
 N --> D
 N --> M[Error latency and business checks]
 M --> R[Expand or revert]

Router traffic ভাগ করে। দুই release একই compatible schema ব্যবহার করে। Canary error rate, tail latency এবং checkout completion stable-এর সঙ্গে তুলনা হয়। Sample কম হলে অপেক্ষা বা targeted test লাগতে পারে। Unacceptable regression হলে expansion থামে; router stable-এ ফেরে। In-flight request drain ছাড়া instance বন্ধ করলে user-visible interruption থাকে।

PHP ও Laravel-এ প্রয়োগ

routes/web.php-তে authenticated diagnostic fragment; release value config/app.php-তে deployment metadata থেকে আসবে। Public response-এ internal host বা secret নয়। Traffic segmentation router/platform-এর দায়; এই endpoint শুধু কোন artifact request serve করেছে তা lab-এ বুঝতে সাহায্য করে।

use Illuminate\Support\Facades\Route;
Route::get('/internal/release', function () {
    return response()->json([
        'release' => config('app.release', 'unknown'),
    ]);
})->middleware('auth');

সুবিধা, সীমাবদ্ধতা ও trade-off

Rolling কম extra capacity-তে হতে পারে কিন্তু কিছু সময় mixed version থাকে। Blue-green দ্রুত traffic rollback দেয়, তবে দ্বিগুণ environment ও shared state compatibility লাগে। Canary blast radius কমায়, কিন্তু analysis, cohort routing ও যথেষ্ট sample দরকার। সব strategy-তে background job, cached data এবং API contract-এর compatibility user-facing HTTP-এর বাইরেও বিবেচনা করতে হয়।

সাধারণ ভুল

• Canary healthy দেখেই সব user-এর সব path tested ধরা।
• Database column drop একই release-এ করা।
• Long request drain না করে instance kill করা।

আরও একটু গভীরে

Canary comparison-এ same time window এবং traffic mix ব্যবহার করুন। Error budget burn, timeout, payment decline-এর unexpected change rollback gate হতে পারে। New code user-visible side effect করলে old code-এ ফেরা side effect undo করে না। Release artifact rollback ও data compensation আলাদা runbook। Schema expand-contract পদ্ধতি mixed version চলাকালে নিরাপদ boundary তৈরি করে।

মনে রাখুন

Deployment strategy traffic exposure নিয়ন্ত্রণ করে; data compatibility ও measurable abort rule ছাড়া rollback অসম্পূর্ণ।

নিজে চেষ্টা করুন

Checkout release-এর canary plan লিখুন। কোন cohort, কত observation window, কোন metrics এবং কী abort condition থাকবে নির্ধারণ করুন। New worker old payload পড়তে না পারলে HTTP-only canary কেন যথেষ্ট নয় ব্যাখ্যা করুন।

নিজের বোঝা যাচাই করুন

1. Rolling-এ দুই version থাকে?

সাধারণত transition window-এ থাকে। তাই schema, cache ও API backward compatibility দরকার।

2. Blue-green-এর rollback কি সব ফেরায়?

Traffic ফেরায়; ইতিমধ্যে লেখা data বা পাঠানো payment request নিজে undo করে না।

3. Canary কম error মানেই ভালো?

Sample size ও traffic mix দেখুন। কম traffic বা ভিন্ন cohort-এ failure লুকাতে পারে।

4. Readiness কেন দরকার?

নতুন instance initialization শেষ হওয়ার আগে request পেলে false failure হয়। Router-কে readiness signal মানতে হবে।

5. Abort rule কখন লিখব?

Release শুরু করার আগেই। Incident চলাকালে অস্পষ্ট সিদ্ধান্তের বদলে agreed metrics ও owner থাকা দরকার।

আরও পড়ুন

• Kubernetes Deployment strategy
• Google SRE canary releases