নীল-সবুজ বনাম ক্যানারি ডিপ্লয়মেন্ট: API ও DB পরিবর্তন নিরাপদে চালানো

কেন স্কিমা পরিবর্তন এবং ধীর মোবাইল আপডেটে ডিপ্লয়মেন্ট ঝুঁকিপূর্ণ হয়

একটি ডিপ্লয় টেস্টে পুরোপুরি ঠিক থাকলে ও বাস্তবে ট্রাফিকে পৌঁছালে ব্যর্থ হতে পারে। সাধারণ কারণ হল আপনার কোডই একমাত্র পরিবর্তন নয়—আপনার API চুক্তি এবং ডাটাবেস স্কিমাও পরিবর্তিত হচ্ছে, এবং এগুলো প্রায় কখনই একসাথে পরিবর্তিত হয় না।

কিছু ভেঙে যায় যখন সিস্টেমের বিভিন্ন অংশ "সঠিক" সম্পর্কে ভিন্ন ধারণা করে। নতুন ব্যাকএন্ড এমন একটি কলাম আশা করে যা এখনও নেই। পুরনো ব্যাকএন্ড এমনভাবে ডেটা লেখে যা নতুন কোড আর বুঝতে পারে না। ফিল্ডের নাম বদলানো, ভ্যালিডেশন কঠোর করা, বা enum মান বদলানো—এই সবই প্রোডাকশনে ত্রুটি ঘটাতে পারে।

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

"ডাউনটাইম ঝুঁকি" কেবল সাইট ডাউন থাকা নয়। বাস্তব সিস্টেমে এটা প্রায়শই আংশিক ব্যর্থতার মধ্যেই দেখা দেয়:

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

এই কারণেই দলগুলো প্রথমে blue-green বনাম canary ডিপ্লয়মেন্ট তুলনা করে: আপনি চেষ্টা করছেন ব্লাস্ট রেডিয়াস কমাতে যখন পরিবর্তনগুলি পুরোপুরি সামঞ্জস্যপূর্ণ নয়।

সাধারণ ভাষায় blue-green ও canary

মানুষ যখন blue-green বনাম canary সম্পর্কে বলেন, তারা সাধারণত এক প্রশ্নের জবাব দিচ্ছেন: আপনি কি একটি বড়, নিয়ন্ত্রিত সুইচ চান, নাকি একটি ছোট, সতর্ক পরীক্ষা?

Blue-green: দুইটি পূর্ণ সংস্করণ ও একটি ট্রাফিক সুইচ

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

এই পদ্ধতি পূর্বানুমানযোগ্যতার জন্য চমৎকার। আপনি প্রোডাকশন-সদৃশ সেটিংসে নতুন সংস্করণ যাচাই করতে পারেন, তারপর এক পরিষ্কার কাটওভার করতে পারেন।

রোলব্যাকও সরল: সুইচের পরে কিছু ভুল হলে ট্রাফিককে আবার blue এ পাঠিয়ে দিন। এটি প্রায় তৎক্ষণাত ফিরিয়ে আনা যায়, কিন্তু ক্যাশ, ব্যাকগ্রাউন্ড জব, এবং ডেটা পরিবর্তন এখনও পুনরুদ্ধার জটিল করতে পারে।

Canary: প্রথমে ছোট একটি শতাংশ ট্রাফিক পাঠান

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

Canary তখনই শ্রেষ্ঠ যখন আপনি বাস্তব ট্রাফিকের অধীনে অজানা আচরণ নিয়ে চিন্তিত। আপনি সমস্যাগুলো আগে ধরতে পারেন, অধিকাংশ ব্যবহারকারী আক্রান্ত হওয়ার আগেই।

রোলব্যাক কাজ করে canary শতাংশ শূন্যে নামিয়ে (বা নতুন সংস্করণে রুটিং বন্ধ করে)। এটি সাধারণত দ্রুত, কিন্তু সবসময় পরিস্কার নয়, কারণ কিছু ব্যবহারকারী ইতিমধ্যে এমন ডেটা বা স্টেট তৈরি করে ফেলেছে যা উভয় সংস্করণকে হ্যান্ডল করতে হবে।

ট্রেড-অফ মনে রাখার সহজ উপায়:

• Blue-green পরিষ্কার কাটওভার ও দ্রুত সুইচব্যাককে প্রাধান্য দেয়।
• Canary বাস্তব ট্রাফিক থেকে শেখার ওপর জোর দেয় এবং ব্লাস্ট রেডিয়াস সীমিত করে।
• কোনটিই স্বয়ংক্রিয়ভাবে ডাটাবেস ঝুঁকি সমাধান করে না। যদি স্কিমা পরিবর্তন সামঞ্জস্যপূর্ণ না হয়, উভয়ই ব্যর্থ হতে পারে।
• Canary মনিটরিংর ওপর নির্ভর করে কারণ আপনি লাইভ সিগন্যালের ভিত্তিতে সিদ্ধান্ত নেবেন।
• Blue-green প্রায়ই অতিরিক্ত capacity দরকার করে কারণ আপনি দুইটি পূর্ণ স্ট্যাক চালান।

উদাহরণ: যদি আপনি এমন একটি API রিলিজ করেন যা কখনও কখনও একটি নতুন ফিল্ড ফেরত দেয়, তাহলে একটি canary আপনাকে দেখাবে পুরনো ক্লায়েন্টগুলো অপ্রত্যাশিত ডেটায় ক্র্যাশ করছে কি না। যদি পরিবর্তনটি এমন যে একটি কলাম রিনেম করা হয়েছে যা পুরনো কোড হ্যান্ডল করতে পারে না, তাহলে blue-green আপনাকে রক্ষা করবে না যদি না স্কিমা পরিবর্তনটি উভয় সংস্করণকে সমর্থন করার জন্য ডিজাইন করা না হয়।

কেন ডাটাবেস মাইগ্রেশন কোড ডিপ্লয়ের চেয়ে আলাদা

কোড ডিপ্লয় সাধারণত রোলব্যাক করা সহজ। নতুন সংস্করণ খারাপ করলে আপনি পুরনো বিল্ড পুনরায় ডিপ্লয় করে প্রায় আগের অবস্থায় ফিরে আসতে পারেন।

ডাটাবেস পরিবর্তন ভিন্ন কারণ এটি আপনার ডেটার আকার বদলে দেয়। একবার সারি পুনরায় লেখা হলে, কলাম ড্রপ করলে, বা কনস্ট্রেন্ট কঠোর করলে, ফিরে যাওয়া বেশিরভাগ সময় তৎক্ষণাৎ সম্ভব নয়। এমনকি যদি আপনি অ্যাপ কোড রোলব্যাক করেন, এটি নতুন স্কিমাকে বুঝতে নাও পারে।

এই কারণেই স্কিমা মাইগ্রেশন ডাউনটাইম ঝুঁকি প্রায়ই ডিপ্লয় পদ্ধতির চেয়ে মাইগ্রেশনের ডিজাইনের ওপর নির্ভর করে।

অনলাইন মাইগ্রেশনের বেসিক্স

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

একটি সাধারণ expand-then-contract সিরিজ:

• প্রথমে অ্যাডিটিভ পরিবর্তন: একটি nullable কলাম যোগ করা, নতুন টেবিল যোগ করা, এমনভাবে ইনডেক্স যোগ করা যাতে লেখায় লক না পড়ে।
• ডুয়াল আচরণ: পুরনো ও নতুন উভয় স্থানে লিখুন, অথবা নতুন থেকে পড়ে fallback এ ফিরুন।
• আলাদা ব্যাকফিল: বিদ্যমান ডেটা ছোট ব্যাচে মাইগ্রেট করুন।
• সুইচ ওভার: নতুন আচরণে বেশিরভাগ ট্রাফিক সরান।
• ধ্বংসাত্মক পরিবর্তন শেষেই: পুরনো কলাম ড্রপ করা, পুরনো কোড পাথ মোছা, কনস্ট্রেন্ট কঠোর করা।

"বিগ ব্যাং" মাইগ্রেশন সেই ঝুঁকিপূর্ণ ধাপগুলো একটি রিলিজে একত্র করে: দীর্ঘ লক, ভারী ব্যাকফিল, এবং এমন কোড যা ধরে নেয় নতুন স্কিমা সব জায়গায় আছে।

ধীর মোবাইল আপডেট কেন মানদণ্ড বাড়ায়

মোবাইল ক্লায়েন্ট পুরনো ভার্সনে থাকতে পারে সপ্তাহভর। আপনার ব্যাকএন্ডকে পুরনো রিকোয়েস্ট গ্রহণ করতে এবং পুরনো রেসপন্স তৈরি করতে হবে যতক্ষণ স্কিমা বিকশিত হচ্ছে।

যদি একটি পুরনো অ্যাপ নতুন ফিল্ড না পাঠায়, আপনার সার্ভার হঠাৎ করে সেই ফিল্ডকে ডাটাবেসে আবশ্যক করতে পারে না। আপনাকে এমন একটি সময়কাল দরকার যেখানে উভয় আচরণ কাজ করে।

কোন কৌশল স্কিমা মাইগ্রেশনের ডাউনটাইম ঝুঁকি কমায়

সর্বাপেক্ষা নিরাপদ নির্বাচন ডিপ্লয় টুলের উপর কম এবং এক প্রশ্নের উপর বেশি নির্ভর করে: পুরনো ও নতুন অ্যাপ ভার্সন কি একই ডাটাবেস স্কিমায় কিছু সময় ঠিক কাজ করতে পারবে?

যদি উত্তর হ্যাঁ, blue-green প্রায়ই কম ডাউনটাইম অপশন। আপনি ডাটাবেস পরিবর্তন প্রস্তুত করে রাখতে পারেন, ট্র্যাফিক পুরনো স্ট্যাকে রাখুন, তারপর এক কাটওভারে নতুন স্ট্যাক চালু করে দিন। কিছু ভুল দেখলে দ্রুত ফিরে আসা যায়।

তবুও blue-green ব্যর্থ হয় যখন নতুন অ্যাপ তৎক্ষণাৎ নতুন স্কিমা চাইবে। সাধারণ উদাহরণ: একটি কলাম ড্রপ বা রিনেম করা যা পুরনো ভার্সন এখনও পড়ে, অথবা NOT NULL কনস্ট্রেন্ট যোগ করা আগের কোড মান লেখে না। সেক্ষেত্রে রোলব্যাক নিরাপদ নাও হতে পারে কারণ ডাটাবেস ইতিমধ্যেই অনুকূল নয়।

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

একটি ব্যবহারিক সিদ্ধান্ত-কনুন

blue-green বনাম canary বিবেচনা করলে সারাক্ষণ মনে রাখুন:

• যদি আপনি স্কিমা অ্যাডিটিভ ও কম্প্যাটিবল রাখতে পারেন এবং দ্রুত, পরিষ্কার সুইচ চান, blue-green বেছে নিন।
• যদি আপনি নিশ্চিত না কিভাবে পরিবর্তন প্রোডাকশনে আচরণ করবে, বা বিরল ডাটা আকারগুলো গুরুত্বপূর্ণ হবে বলে মনে করেন, canary বেছে নিন।
• যদি মাইগ্রেশন তাত্ক্ষণিক ভাঙন ঘটাচ্ছে, blue-green বা canary নিয়ে নির্বাচন করবেন না—পরিকল্পনা বদলিয়ে expand-then-contract পদ্ধতি নিন।

বাস্তবে "কম্প্যাটিবল" কেমন দেখায়

ধরা যাক আপনি orders টেবিলে একটি নতুন ফিল্ড যোগ করছেন। নিরাপদ পথ: কলামটি nullable হিসেবে যোগ করুন, সেই কোড ডিপ্লয় করুন যা এটি লেখে, পুরনো সারিগুলো ব্যাকফিল করুন, পরে কনস্ট্রেন্ট প্রয়োগ করুন। এই সেটআপে blue-green একটি পরিষ্কার কাটওভার দেয়, আর canary দেয় আগে থেকে সতর্কবার্তা যদি কোনো কোডপাথ এখনও পুরনো শেপ ধরতে পারে।

ধীর মোবাইল আপডেট রোলআউট পছন্দ পরিবর্তন করে কিভাবে

ওয়েব ব্যবহারকারী রিফ্রেশ করে; মোবাইল ব্যবহারকারী করে না।

iOS ও Android-এ মানুষ পুরনো ভার্সনে সপ্তাহ বা মাস ধরে থাকতে পারে। কেউ কেউ কখনও আপডেট করে না যতক্ষণ না অ্যাপ জোর করে করে। এর মানে আপনার "পুরনো" ক্লায়েন্ট আপনার ব্যাকএন্ডকে অনেক পরে পর্যন্ত কল করে। পুরনো মোবাইল ক্লায়েন্টগুলি আপনার ব্যাকএন্ডের জন্য স্থায়ী ব্যাকওয়ার্ড-কম্প্যাটিবিলিটি পরীক্ষা হয়ে দাঁড়ায়।

এটি লক্ষ্য পরিবর্তন করে: "বিনা ডাউনটাইমে ডিপ্লয়" থেকে "একাধিক ক্লায়েন্ট জেনারেশন একই সাথে কাজ করুক"। বাস্তবে মোবাইল প্রায়ই API-র ক্ষেত্রে canary-ধাঁচের চিন্তা চাপিয়ে দেয়, এমনকি আপনি ইনফ্রাস্ট্রাকচারের জন্য blue-green ব্যবহার করলেও।

ব্যাকওয়ার্ড-কম্প্যাটিবল পরিবর্তন বনাম API ভার্সনিং

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

কম্প্যাটিবল উদাহরণ: নতুন ফিল্ড যোগ করা, পুরনো ও নতুন পে-লোড উভয় গ্রহণ করা, বিদ্যমান রেসপন্স ফিল্ড রাখা, এবং অর্থ না বদলানো।

যখন আচরণই পরিবর্তন করতে হবে (শুধু ডেটা যোগ নয়), বা ফিল্ড মুছতে বা রিনেম করতে হবে, তখন API ভার্সনিং দরকার হতে পারে।

উদাহরণ: একটি ঐচ্ছিক ফিল্ড marketing_opt_in যোগ করা সাধারণত নিরাপদ। price কিভাবে হিসাব করা হয় বদলানো সাধারণত নিরাপদ নয়।

একটি ডিপ্রেচেশন উইন্ডো পরিকল্পনা করা

যদি আপনাকে ভাঙনশীল পরিবর্তন করতে হয়, সমর্থন শেষ করার সময়টি একটি প্রোডাক্ট সিদ্ধান্ত হিসেবে বিবেচনা করুন। একটি কার্যকর ডিপ্রেচেশন উইন্ডো মাপা হয় "কত সক্রিয় ব্যবহারকারী এখনও পুরনো ভার্সনে আছে" - দিয়ে, ক্যালেন্ডার দিন দিয়ে নয়।

একটি ব্যবহারিক ক্রম:

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

ধাপ-পরে-ধাপ: API + ডাটাবেস পরিবর্তনের নিরাপদ রোলআউট প্যাটার্ন

API ও ডাটাবেস একসাথে পরিবর্তন করলে, নিরাপদ পরিকল্পনা সাধারণত দুই বা তিন ধাপের রোলআউট। প্রতিটি ধাপ নিজেদের মধ্যে নিরাপদভাবে Deployable হওয়া উচিত, এমনকি ব্যবহারকারীরা পুরনো মোবাইল অ্যাপ রাখতেই থাকুক।

পুরনো ক্লায়েন্ট ভেঙে না ফেলার জন্য একটি রোলআউট প্যাটার্ন

প্রথমেই একটি অ্যাডিটিভ ডাটাবেস পরিবর্তন করুন। নতুন কলাম বা টেবিল যোগ করুন, রিনেম বা মুছুন না, প্রয়োজন হলে null অনুমোদন করুন, এবং ডিফল্ট ব্যবহার করুন যাতে পুরনো কোড হঠাৎ কনস্ট্রেন্টে না পড়ে়।

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

একটি সাদামাটা ক্রম:

• নতুন স্কিমা অংশ (কলাম, টেবিল, ইনডেক্স) যোগ করুন পুরনোগুলো না মুছেই।
• এমন কোড Deploy করুন যা পুরনো বা নতুন থেকেই পড়তে পারে এবং null-এ ক্র্যাশ না করে।
• বিদ্যমান সারিগ ছোট ব্যাচে ব্যাকফিল করুন, পরে কাউন্ট, null-রেটে, এবং কুয়েরি পারফরম্যান্স যাচাই করুন।
• রাইট পাথ নতুন ফিল্ডে স্যুইচ করুন, কিন্তু fallback রেখেই।
• পুরনো মোবাইল ভার্সনগুলো যন্ত্রপাতি কমে এলে পুরনো ফিল্ড ও ক্লিনআপ মুছে ফেলুন।

ব্যাকফিল ও যাচাইকরণ: যেখানে আউটেজ লুকায়

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

উদাহরণ: আপনি phone_country_code যোগ করছেন। প্রথমে কলাম যোগ করুন (nullable), API আপডেট করুন যাতে গ্রহণ করে কিন্তু অনুপস্থিত হলে কাজ করে, বিদ্যমান ফোন নম্বর থেকে ব্যাকফিল করুন, তারপর নতুন সাইনআপের সময় লেখতে শুরু করুন। কিছু সপ্তাহ পরে পুরনো পার্সিং পাথ সরানো যায়।

যেসব টুল দুটোই কৌশলকে নিরাপদ করে (সরল উপায়ে)

জটিল সেটআপের দরকার নেই blue-green বা canary কে নিরাপদ করতে। কিছু অভ্যাস বিস্ময়ের দিকে ঠেকায় যখন API এবং ডাটাবেস স্কিমা আলাদা গতিতে চলে।

ডুয়াল-রিড ও ডুয়াল-রাইট (অস্থায়ী রাখুন)

ডুয়াল-রাইট মানে ট্রানজিশনের সময় অ্যাপ ডেটা পুরনো ও নতুন উভয় জায়গায় লিখে (উদাহরণস্বরূপ, users.full_name এবং নতুন users.display_name)। ডুয়াল-রিড মানে এটি উভয় জায়গা থেকে পড়তে পারে, সাধারণত নতুনকে প্রাধান্য দেয় কিন্তু না পারলে পুরনোতে fallback করে।

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

ফিচার ফ্ল্যাগ আচরণ পরিবর্তনের জন্য

Feature flags দিয়ে আপনি ঝুঁকিপূর্ণ আচরণ বন্ধ রেখে কোড Deploy করতে পারেন। এটি blue-green ও canary উভয়ের জন্যই কাজে লাগে কারণ আপনি "Deploy" এবং "Turn on" আলাদা করতে পারবেন।

উদাহরণ: একটি নতুন রেসপন্স ফিল্ডের সমর্থন Deploy করুন, কিন্তু সার্ভার পুরনো শেপই রিটার্ন রাখুন যতক্ষণ না প্রস্তুত। তারপর নতুন আচরণ ছোট গ্রুপে চালু করুন, ত্রুটি দেখলে ফ্ল্যাগ বন্ধ করুন।

চুক্তি-পরীক্ষার মানসিকতা (API একটি প্রতিশ্রুতি)

অনেক মাইগ্ৰেশন_incident আসলে "ডাটাবেস সমস্যা" নয়; তারা ক্লায়েন্ট প্রত্যাশার সমস্যা।

API-কে একটি চুক্তির মতো বিবেচনা করুন। ফিল্ড মুছা বা অর্থ বদলানো এড়ান। অজানা ফিল্ডগুলো optional রাখুন। অ্যাডিটিভ পরিবর্তন সাধারণত নিরাপদ; ভাঙনশীল পরিবর্তন নতুন API ভার্সনের জন্য অপেক্ষা করুন।

বিশ্বাসযোগ্য ডাটা মাইগ্রেশন জব

স্কিমা মাইগ্রেশনগুলোর জন্য প্রায়ই ব্যাকফিল জব দরকার হয়। এই জবগুলো সহজ ও পুনরাবৃত্তিযোগ্য হওয়া উচিত: দুইবার চালালেও নিরাপদ, retry-যোগ্য, ট্র্যাক করা সহজ, এবং থ্রটল করা যাতে লোড স্পাইক না করে।

মাইগ্রেশনের সময় আউটেজ ঘটায় এমন সাধারণ ভুলগুলো

বেশিরভাগ আউটেজ ঘটে যখন কোনো রিলিজ ধরে নেয় সবকিছু একসাথে চলে: সব সার্ভিস একসাথে Deploy হবে, সব ডেটা পরিষ্কার থাকবে, এবং সব ক্লায়েন্ট সময়মতো আপডেট করবে। বাস্তব সিস্টেম এমন নয়, বিশেষত মোবাইলের ক্ষেত্রে।

সাধারণ ব্যর্থতা প্যাটার্ন:

• খুব তাড়াতাড়ি একটি কলাম ড্রপ বা রিনেম করা। পুরনো API কোড, ব্যাকগ্রাউন্ড জব, বা পুরনো মোবাইল অ্যাপগুলো এটি এখনও ব্যবহার করতে পারে।
• ক্লায়েন্ট দ্রুত আপডেট করবে ধরে নেওয়া। মোবাইল রিলিজ পৌঁছতে সময় নেয়।
• পিক আওয়ারে লকিং মাইগ্রেশন চালানো। একটি সহজ মনে হওয়া ইনডেক্স পরিবর্তনও লেখাকে ব্লক করতে পারে।
• কেবল পরিষ্কার স্যাম্পল ডেটা টেস্ট করা। প্রোডাকশন ডেটায় null, অদ্ভুত ফরম্যাট, ডুপ্লিকেট, এবং লেগ্যাসি মান থাকে।
• কোড ও ডেটা উভয়ের জন্য স্পষ্ট রোলব্যাক প্ল্যান না থাকা। "আমরা পূর্বের সংস্করণ পুনরায় ডিপ্লয় করতে পারি" যথেষ্ট নয় যদি স্কিমা পরিবর্তিত হয়ে গিয়েছে।

উদাহরণ: আপনি status কে order_status নামে রিনেম করে নতুন API Deploy করেন। ওয়েব অ্যাপ কাজ করে। পুরনো মোবাইল ক্লায়েন্ট এখনও status পাঠায়, এবং এখন API সেই অনুরোধগুলো রিজেক্ট করে, ফলে চেকআউট ব্যর্থ হয়। যদি আপনি কলাম ড্রপ করে দিয়ে থাকেন, আচরণ পুনরুদ্ধার দ্রুত করা যাবে না।

ভালো ডিফল্ট হচ্ছে: ছোট, উল্টনো যোগ্য ধাপে পরিবর্তন করুন, পুরনো ও নতুন পাথকে একসাথে কাজ করার যোগ্য রাখুন, এবং metric spike হলে আপনি কী করবেন তা লিখে রাখুন (কিভাবে ট্রাফিক রাউটিং ফিরানো, কোন ফিচার ফ্ল্যাগ নতুন আচরণ বন্ধ করে, এবং ব্যাকফিল খারাপ হলে কিভাবে ডেটা ভ্যালিডেট ও রেপেয়ার করবেন)।

Deploy-এর ঠিক আগের দ্রুত চেকলিস্ট

রিলিজের ঠিক আগে একটি ছোট চেকলিস্ট বেশিরভাগ সমস্য আটকায়। এটা বেশি গুরুত্বপূর্ণ যখন আপনি একই সাথে API ও ডাটাবেস পরিবর্তন করছেন, বিশেষত ধীর মোবাইল আপডেটে।

আউটেজ রোধ করার পাঁচটি চেক

• Compatibility: নিশ্চিত করুন পুরনো ও নতুন অ্যাপ ভার্সন একই ডাটাবেস স্কিমায় কাজ করে। একটি ব্যবহারিক পরীক্ষা হল বর্তমান প্রোডাকশন বিল্ডকে স্টেজিং ডাটাবেসে চালানো যেখানে নতুন মাইগ্রেশন প্রয়োগ করা আছে।
• Migration order: প্রথম মাইগ্রেশনটি অ্যাডিটিভ রাখুন, ধ্বংসাত্মক পরিবর্তনগুলো পরে শিডিউল করুন।
• Rollback: দ্রুততম উল্টাপাল্টা কী হবে তা সংজ্ঞায়িত করুন। blue-green এ এটি ট্রাফিক ফিরে দেওয়া। canary তে এটি স্থিতিশীল ভার্সনে 100% ট্রাফিক পাঠানো। যদি রোলব্যাক আরেকটি মাইগ্রেশন দাবি করে, তাহলে সেটা সহজ নয়।
• Performance: কেবল সঠিকতা নয়, স্কিমা পরিবর্তনের পরে কুয়েরি লেটেন্সি মাপুন। একটি অনুপস্থিত ইনডেক্স এক এন্ডপয়েন্টকে আউটেজের মতো লাগতে পারে।
• Client reality: নির্ধারণ করুন সবচেয়ে পুরনো সক্রিয় মোবাইল অ্যাপ ভার্সন কোনটি যা এখনও আপনার API কল করছে। যদি তাৎপর্যপূর্ণ শতাংশ ওই ভার্সনে থাকে, তাহলে দীর্ঘ কম্প্যাটিবিলিটি উইন্ডো পরিকল্পনা করুন।

দ্রুত স্যানিটি সিনারিও

যদি আপনি একটি নতুন ফিল্ড preferred_language যোগ করছেন, প্রথমে ডাটাবেস পরিবর্তন nullable হিসেবে Deploy করুন। তারপর সার্ভার কোড শিপ করুন যাতে এটি উপস্থিত হলে পড়ে, কিন্তু বাধ্যতামূলক না করে। কেবল তখনই required করুন বা পুরনো আচরণ সরান যখন বেশিরভাগ ট্রাফিক আপডেট হওয়া অ্যাপে চলে গিয়েছে।

উদাহরণ: কিভাবে একটি নতুন ফিল্ড যোগ করবেন পুরনো মোবাইল অ্যাপ ভেঙে না ফেলে

ধরা যাক একটি প্রোফাইল ফিল্ড country যোগ করতে চান এবং ব্যবসা এটিকে required করতে চাইছে। এটি দুই জায়গায় ভাঙতে পারে: পুরনো ক্লায়েন্ট ফিল্ড পাঠাবে না, এবং ডাটাবেস যদি তত্ক্ষণাৎ NOT NULL এ নির্ধারণ করে তাহলে লেখাগুলো বাতিল করে দিতে পারে।

নিরাপদ পদ্ধতি হলো আলাদা দুই পরিবর্তন: প্রথমে ফিল্ডটি ব্যাকওয়ার্ড-কম্প্যাটিবলভাবে যোগ করুন, পরে required করা—ক্লায়েন্ট গ্রহণের পরে।

Blue-green এ কেমন দেখায়

Blue-green এ আপনার নতুন সংস্করণ পুরনো সংস্করণের পাশে Deploy হবে। তবুও ডাটাবেস পরিবর্তন উভয় সংস্করণকেই সাপোর্ট করতে হবে।

নিরাপদ প্রবাহ:

• মাইগ্রেশন Deploy করুন (country nullable হিসেবে যোগ)
• গ্রিন সংস্করণ Deploy করুন যা অনুপস্থিত country গ্রহণ করে এবং fallback ব্যবহার করে
• গুরুত্বপূর্ণ ফ্লোগুলো গ্রিনে টেস্ট করুন (সাইনআপ, প্রোফাইল এডিট, চেকআউট)
• ট্রাফিক সুইচ করুন

কিছু ভুল হলে ফিরে যান। কীগুলো হলো: ফিরে যাওয়া কাজ করবে যদি স্কিমা এখনও পুরনো সংস্করণকে সাপোর্ট করে।

Canary এ কেমন দেখায়

Canary এ নতুন API আচরণটি প্রথমে ছোট একটি অংশে উন্মুক্ত করা হয় (সাধারণত 1% থেকে 5%) এবং অনুপস্থিত-ফিল্ড ভ্যালিডেশন এরর, ল্যাটেন্সি পরিবর্তন, ও অপ্রত্যাশিত ডাটাবেস ত্রুটি খুঁজে দেখা হয়।

সাধারণ চমক হল পুরনো মোবাইল ক্লায়েন্ট প্রোফাইল আপডেট পাঠায় কিন্তু country নেই। যদি API তা তৎক্ষণাৎ required মনে করে, আপনি 400 দেখবেন। যদি ডাটাবেস NOT NULL প্রয়োগ করে, আপনি 500 পেতে পারেন।

নিরাপদ ক্রম:

• country nullable হিসেবে যোগ করুন (ইচ্ছা করলে নিরাপদ ডিফল্ট যেমন "unknown")
• পুরনো ক্লায়েন্ট থেকে অনুপস্থিত country গ্রহণ করুন
• ব্যাকফিল চালান বিদ্যমান ইউজারদের জন্য ব্যাকগ্রাউন্ড জবে
• পরে required প্রয়োগ করুন (প্রথমে API-তে, তারপর ডাটাবেসে)

রিলিজের পরে লিখে রাখুন পুরনো ক্লায়েন্ট কি পাঠাতে পারে এবং সার্ভার কী গ্যারান্টি দিচ্ছে। সেই লিখিত চুক্তি পরবর্তী মাইগ্রেশনে একই ধরনের ভাঙন আটকায়।

যদি আপনি AppMaster (appmaster.io) দিয়ে নির্মাণ করেন, একই রোলআউট শৃঙ্খল প্রযোজ্য—যদিও আপনি এক মডেল থেকে ব্যাকএন্ড, ওয়েব, এবং নেটিভ মোবাইল অ্যাপ জেনারেট করতে পারেন। প্ল্যাটফর্ম ব্যবহার করে অ্যাডিটিভ স্কিমা পরিবর্তন ও সহনশীল API লজিক প্রথমে শিপ করুন, এবং গ্রহণযোগ্যতা বাড়লে কনস্ট্রেইন্ট কড়া করুন।