পাঠ্যক্রম খুলুন

অগ্রসর পর্যায়

Feature Flag ও Rollback: নিরাপদে আগের অবস্থায় ফেরা

Feature Flags, Rollbacks, and Migration Safety

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনDeployment Strategy: rolling, blue-green ও canary ↗Database Migration: পুরোনো code সচল রেখে schema বদল ↗

এই পাঠের সূচিপত্র

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

Feature flag ও code rollback আলাদা করা
Expand-contract migration করা
Flag ownership ও cleanup পরিকল্পনা

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

নতুন discount engine error করছে। Code rollback সহজ, কিন্তু নতুন release পুরোনো price column মুছে দিয়েছে। আগের binary চালু হয়েও query fail করছে। অন্যদিকে feature flag off করলে নতুন code path বন্ধ করা যেত, কিন্তু flag lookup ব্যর্থ হলে কী হবে লেখা ছিল না। ফেরার পথ release-এর আগে design করতে হয়; emergency-তে বানানো যায় না।

সহজ করে বুঝি

Feature flag deployed code-এর behavior বেছে দেয়। Rollback artifact বা routing পুরোনো অবস্থায় ফেরায়। Schema safety-তে প্রথমে নতুন field যোগ, compatible code deploy, data backfill ও verification, শেষে পুরোনো field বাদ দেওয়া হয়। Flag database migration undo করে না। Flag evaluation-এর context, default behavior এবং cache invalidation স্পষ্ট থাকতে হবে, বিশেষত tenant বা user-based rollout-এ।

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

নতুন সেতু তৈরির সময় পুরোনো সেতু আগে ভেঙে দিলে ফিরে যাওয়া যায় না। কিছু দিন দুই পথ খোলা রেখে নতুন পথ পরীক্ষা করা expand-contract-এর মতো। Traffic sign হলো feature flag; sign বদলালে ভাঙা সেতু ফেরত আসে না।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

ফেরার পথের জন্য compatible data, tested old behavior এবং controlled flag lifecycle আগে থেকে রাখতে হয়।

Diagram-এর text flow দেখুন

flowchart LR
 E[Expand schema] --> C[Compatible code]
 C --> B[Backfill and verify]
 B --> F[Enable flag gradually]
 F --> S[Observe stable behavior]
 S --> X[Contract old fields later]

Schema আগে বাড়ে, তারপর old এবং new data বুঝতে পারে এমন code আসে। Backfill retryable ও measurable হতে হবে। Flag সীমিত cohort-এ চালু হয়। Observation শেষে পুরোনো reader/worker আর নেই নিশ্চিত করে contract করা হয়। কোনো ধাপে সমস্যা হলে old path চালু রাখার সুযোগ থাকে; destructive contract-এর পরে আগের rollback plan বদলায়।

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

config/features.php-তে নতুন discount toggle সংজ্ঞায়িত এবং checkout service-এ fragment। Environment value শুধু config file-এ পড়ুন; config cache থাকলে runtime code-এ env() নির্ভর করবেন না। বাস্তব cohort rollout-এ Laravel Pennant বা reviewed flag store নেওয়া যায়।

// config/features.php
return ['new_discount' => env('NEW_DISCOUNT', false)];

// Checkout service fragment
if (config('features.new_discount')) {
    $total = $this->newDiscounts->calculate($cart);
} else {
    $total = $this->legacyDiscounts->calculate($cart);
}

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

Flag incident response দ্রুত করতে পারে এবং deploy থেকে release আলাদা করে। বিনিময়ে branching, test combinations ও stale flag debt বাড়ে। Financial calculation-এ request-এর মাঝখানে flag বদলে গেলে inconsistent result হতে পারে; operation-এর শুরুতে decision স্থির রাখুন। Runtime dynamic flag বেশি flexible, কিন্তু availability এবং latency dependency যোগ করে।

সাধারণ ভুল

Destructive migration-এর পরে old code guaranteed কাজ করবে ভাবা।
Permanent flag owner ও expiry না রাখা।
Flag off করলে ইতিমধ্যে তৈরি ভুল order নিজে ঠিক হবে ধরা।

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

Backfill chunk ধরে চালান, progress checkpoint ও consistency check রাখুন। Dual-write করলে দুটি destination-এর partial failure নতুন সমস্যা আনে; authoritative source ঠিক করুন। Flag emergency default fail-open না fail-closed হবে business risk অনুযায়ী নির্ধারণ করুন। Audit trail-এ কে কখন flag বদলেছেন রাখুন। Sensitive authorization কখনো অনির্ভরযোগ্য client flag-এর উপর ছেড়ে দেবেন না।

মনে রাখুন

ফেরার পথের জন্য compatible data, tested old behavior এবং controlled flag lifecycle আগে থেকে রাখতে হয়।

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

Orders.total থেকে amount_minor migration-এর expand-contract plan লিখুন। পুরোনো worker queue-তে থাকলে কখন column drop নিরাপদ তা নির্ধারণ করুন। Flag off করার পর ভুল invoice কীভাবে reconcile করবেন তার আলাদা ধাপ দিন।

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

1. Flag ও rollback একই?

Flag behavior নির্বাচন করে; rollback artifact বা routing ফেরায়। দুটো data change নিজে undo করে না।

2. Column কখন drop করব?

সব reader, writer, worker ও rollback window নতুন schema-তে নিরাপদ নিশ্চিত করার পরে। Contract আলাদা release-এ করা সুবিধাজনক।

3. Backfill retryable কেন?

দীর্ঘ operation মাঝপথে থামতে পারে। Checkpoint ও idempotent update থাকলে শুরু থেকে ঝুঁকিপূর্ণ কাজ না করেও এগোনো যায়।

4. Config flag সঙ্গে সঙ্গে বদলায়?

Cached config বা long-running process থাকলে নয়। Deployment/reload strategy এবং cache behavior বুঝতে হবে।

5. Flag cleanup দরকার?

হ্যাঁ। স্থায়ী branching tests ও reasoning কঠিন করে। Owner, expiry ও removal criteria রাখুন।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।