API কনট্র্যাক্ট টেস্টিং: দ্রুতগতির দলের জন্য ভাঙন প্রতিরোধ

কেন ভাঙনশীল API পরিবর্তনগুলো রিলিজে ঢুকে পড়ে\n\nঅধিকাংশ টিমে একটিই API অনেক ক্লায়েন্ট সার্ভ করে: একটি ওয়েব অ্যাপ, একটি iOS অ্যাপ, একটি Android অ্যাপ, এবং কখনও কখনও অভ্যন্তরীণ টুলস। সবাই যতই একই এন্ডপয়েন্ট ব্যবহার করার বিষয়ে একমত থাকুক, প্রতিটি ক্লায়েন্ট API-কে আলাদা ভাবে ব্যবহার করে। এক স্ক্রিন কোনো ফিল্ড সবসময় আছে ধরে নিতে পারে, আবার অন্যটি সেটি ব্যবহার করে না unless একটা ফিল্টার চালু থাকে।\n\nসমস্যা সত্যিই উঠবে যখন এই অংশগুলো বিভিন্ন সময়সূচিতে শিপ হয়। ব্যাকএন্ড পরিবর্তন দিনে একাধিক বার লাইভ হতে পারে, ওয়েব দ্রুত ডেপ্লয় করে, আর মোবাইল রিলিজ ধীর হয় রিভিউ সাইকেল আর স্টেজড রোলআউটের কারণে। সেই ব্যবধানই হঠাৎ ব্রেকেজ তৈরি করে: API নতুন ক্লায়েন্টের জন্য আপডেট করা হলো, কিন্তু গতকালের মোবাইল বিল্ড এখনও ব্যবহারকারীর কাছে আছে এবং এখন এমন রেসপন্স পায় যা সামলাতে পারে না।\n\nএগুলো সাধারণত সুক্ষ্ম লক্ষণ নয়:\n\n- একটি স্ক্রিন হঠাৎ খালি হয়ে যায় কারণ একটি ফিল্ড রিনেম বা সরিয়ে দেওয়া হয়েছে\n- অপ্রত্যাশিত null বা অনুপস্থিত অবজেক্টের কারণে অ্যাপ ক্র্যাশ করে\n- "কিছু ভাঙেছে" ধরনের সাপোর্ট টিকিটগুলো যা রেপ্রডিউস করা কঠিন\n- ব্যাকএন্ড ডেপ্লয়ের পর ইরর লগে হঠাৎ স্পাইক\n- মূল সমস্যার পরিবর্তে ডিফেন্সিভ কোড যোগ করে হটফিক্স রিলিজ\n\nম্যানুয়াল টেস্টিং এবং QA এইগুলো প্রায়ই মিস করে কারণ ঝুঁকিপূর্ণ কেসগুলো সাধারণ পথ নয়। একজন টেস্টার হয়ত যাচাই করবে "Create order" কাজ করে, কিন্তু পুরোনো অ্যাপ ভার্সন, আংশিক পূর্ণ প্রোফাইল, বিরল ইউজার রোল, বা তালিকা খালি থাকলে কি হয়—এসব না করবে। ক্যাশিং, ফিচার ফ্ল্যাগ, ধাপে ধাপে রোলআউট যোগ করলে টেস্ট প্ল্যান কভার করতে পারার চেয়েও বেশি কম্বিনেশন হয়ে যায়।\n\nএকটি সাধারণ উদাহরণ: ব্যাকএন্ড status: "approved" কে status: { code: "approved" } এ প্রতিস্থাপন করে লোকালাইজেশন সাপোর্ট করার জন্য। ওয়েব অ্যাপ একই দিনে আপডেট হয় এবং ঠিকমত চলে। কিন্তু কারেন্ট iOS রিলিজটি এখনও স্ট্রিং আশা করে, রেসপন্স পার্স করতে পারে না, এবং ব্যবহারকারীরা লগইন করার পর ব্ল্যাঙ্ক পেজ দেখেন।\n\nএ কারণেই API কনট্র্যাক্ট টেস্টিং আছে: QA-এর বিকল্প নয়, বরং এমন পরিবর্তনগুলো প্রোডাকশনে পৌঁছানোর আগে ধরতে সাহায্য করে যেগুলো "আমার লেটেস্ট ক্লায়েন্টের জন্য কাজ করে" মনে হয়।\n\n## কনট্র্যাক্ট টেস্টিং কী (এবং কী নয়)\n\nকনট্র্যাক্ট টেস্টিং হলো একটি এপিআই কনজিউমার (ওয়েব অ্যাপ, মোবাইল অ্যাপ, বা আরেকটি সার্ভিস) এবং একটি এপিআই প্রোভাইডারের (আপনার ব্যাকএন্ড) মধ্যে কীভাবে তারা একে অপরের সাথে কথা বলবে সে বিষয়ে সম্মত হওয়ার একটি উপায়। সেই সম্মতি হল কনট্র্যাক্ট। একটি কনট্র্যাক্ট টেস্ট একটি সহজ জিনিস পরীক্ষা করে: প্রোভাইডার কি এখনও সেইভাবে আচরণ করে যেভাবে কনজিউমার নির্ভর করে, পরিবর্তনের পরেও?\n\nপ্রакটিসে, API কনট্র্যাক্ট টেস্টিং ইউনিট টেস্ট এবং end-to-end টেস্টের মাঝে অবস্থান করে। ইউনিট টেস্ট দ্রুত এবং লোকাল, কিন্তু টিমগুলোর মধ্যে মিসম্যাচ ধরতে পারে না কারণ তারা অভ্যন্তরীণ কোড টেস্ট করে, শেয়ার হওয়া বাউন্ডারি নয়। E2E টেস্ট অনেক সিস্টেম জুড়ে বাস্তব ফ্লো এক্সারসাইজ করে, কিন্তু সেগুলো ধীরে চলে, রক্ষণাবেক্ষণ কঠিন এবং প্রায়ই এমন কারণে ফেইল করে যা API পরিবর্তনের সাথে সম্পর্ক নেই (টেস্ট ডেটা, UI টাইমিং, ফ্লাকি এনভায়রনমেন্ট)।\n\nকনট্র্যাক্ট কোনো বৃহৎ ডকুমেন্ট নয়। এটি সেই অনুরোধগুলো এবং রেসপন্সগুলোর একটি ফোকাসড বিবরণ যা একটি কনজিউমার পাঠায় এবং যা তাকে ফিরে পেতে হবে। ভালো কনট্র্যাক্ট সাধারণত নিম্নলিখিতগুলো কভার করে:\n\n- Endpoints এবং methods (উদাহরণ: POST /orders)\n- রিকোয়ার্ড ও অপশনাল ফিল্ড, টাইপ এবং বেসিক বিধি\n- স্ট্যাটাস কোড ও এরর রেসপন্সের শেপ (যেমন 400 বনাম 404 কেমন দেখায়)\n- হেডার এবং অথ এক্সপেকটেশন (টোকেন থাকা, কনটেন্ট-টাইপ)\n- গুরুত্বপূর্ণ ডিফল্ট এবং কম্প্যাটিবিলিটি রুল (যদি একটি ফিল্ড অনুপস্থিত থাকে কি হয়)\n\nনিচে কনট্র্যাক্ট টেস্ট আগে থেকেই ধরবে এমন একটি সাধারণ ব্রেকের উদাহরণ: ব্যাকএন্ড total_price কে totalPrice এ রিনেম করে। ইউনিট টেস্ট এখনও পাস করতে পারে। E2E টেস্ট হয়ত সেই স্ক্রিন কভার করে না বা পরে কনফিউজিংভাবে ফেইল করে। কনট্র্যাক্ট টেস্ট সঙ্গে সঙ্গে ফেইল করে এবং সঠিক মিসম্যাচ দেখায়।\n\nস্পষ্ট হওয়া ভালো যে কনট্র্যাক্ট টেস্টিং কী নয়। এটি পারফরম্যান্স টেস্টিং, সিকিউরিটি টেস্টিং বা পূর্ণ ইউজার জার্নি টেস্টিং প্রতিস্থাপন করে না। এটি প্রতিটি লজিক বাগ ধরবে না। যা করে তা হলো দ্রুতগতির টিমগুলোর সবচেয়ে সাধারণ রিলিজ ঝুঁকি কমানো: একটি "ছোট" API পরিবর্তন যা ক্লায়েন্টকে নির্বিঘ্নে ভাঙিয়ে দেয়।\n\nআপনার ব্যাকএন্ড যদি জেনারেটেড হয় বা ঘন ঘন বদলে (উদাহরণ: AppMaster-এর মতো প্ল্যাটফর্মে API পুনরায় তৈরি করা), কনট্র্যাক্ট টেস্টগুলো একটি প্রায়োগিক সেফটি নেট কারণ তারা নিশ্চিত করে যে প্রতিটি পরিবর্তনের পরে ক্লায়েন্ট এক্সপেকটেশন এখনও ধরে আছে।\n\n## ওয়েব ও মোবাইল টিমের জন্য কনট্র্যাক্ট পন্থা বেছে নিন\n\nওয়েব এবং মোবাইল দ্রুত শিপ করলে, কঠিন অংশটি হলো "API টেস্ট করা" নয়—এটা নির্ধারণ করা কোন পরিবর্তনটি প্রতিটি ক্লায়েন্টের জন্য অপরিবর্তিত থাকতে হবে। এটাই কনট্র্যাক্ট টেস্টিং সাহায্য করে, কিন্তু আপনাকে কিভাবে কনট্র্যাক্ট মালিকানা হবে সেটাও বেছে নিতে হবে।\n\n### অপশন 1: কনজিউমার-চালিত কনট্র্যাক্ট (CDC)\n\nকনজিউমার-চালিত কনট্র্যাক্টে, প্রতিটি ক্লায়েন্ট (ওয়েব, iOS, Android, পার্টনার ইন্টিগ্রেশন) তারা যা চায় তা নির্ধারণ করে। প্রোভাইডার তারপর প্রমাণ করে সে সেই প্রত্যাশা মেটাতে পারে।\n\nএটি ভাল কাজ করে যখন ক্লায়েন্টরা স্বাধীনভাবে চলবে, কারণ কনট্র্যাক্ট বাস্তব ব্যবহারকে প্রতিফলিত করে, সেইBackend টিম কি মনে করে তা নয়। এটা মাল্টি-ক্লায়েন্ট বাস্তবতার সাথেও খায়: iOS হয়ত এমন একটি ফিল্ড নির্ভর করে যা ওয়েব ব্যবহার করে না, এবং ওয়েব হয়ত সোর্টিং বা পেজিং নিয়ম গুরুত্ব দেয় যা মোবাইল উপেক্ষা করে।\n\nসরল উদাহরণ: মোবাইল অ্যাপ price_cents কে একটি ইন্টেজার হিসেবে নির্ভর করে। ওয়েব কেবল ফরম্যাটেড দাম দেখায়, তাই যদি ব্যাকএন্ডটি এটি স্ট্রিং-এ বদলে দেয় ওয়েব তা নোটিসই করবে না। মোবাইলের CDC এটা চেক করে রিলিজের আগে।\n\n### অপশন 2: প্রোভাইডার-অধিকারী স্কিমা\n\nপ্রোভাইডার-অধিকারী স্কিমায়, ব্যাকএন্ড দল একটি একক কনট্র্যাক্ট (সাধারণত একটি স্কিমা বা স্পেস) প্রকাশ করে এবং সেটি বলবৎ করে। কনজিউমাররা সেই একক সোর্স অব ট্রুথের বিরুদ্ধে টেস্ট করে।\n\nএটি ভাল ফিট যখন API পাবলিক বা অনেক অনিয়ন্ত্রিত কনজিউমারের জন্য শেয়ার করা হয়, বা যখন দলগুলোর মধ্যে কঠোর কনসিস্টেন্সি দরকার। শুরু করতেও এটি সহজ: একটি কনট্র্যাক্ট, এক জায়গায় পরিবর্তন রিভিউ, এক অনুমোদন পথ।\n\nনির্বাচন করার সহজ নিয়মটা: \n\n- ক্লায়েন্টগুলো যখন ঘন ঘন শিপ করে এবং API-র বিভিন্ন অংশ ব্যবহার করে তখন CDC বেছে নিন।\n- সবাইকে নিয়ে একটি স্থিতিশীল "অফিশিয়াল" কনট্র্যাক্ট দরকার হলে প্রোভাইডার-অধিকারী স্কিমা বেছে নিন।\n- যখন সম্ভব, হাইব্রিড ব্যবহার করুন: বেসলাইনের জন্য প্রোভাইডার স্কিমা এবং উচ্চ-ঝুঁকির এন্ডপয়েন্টগুলোর জন্য CDC।\n\nAppMaster-এর মতো প্ল্যাটফর্ম দিয়ে তৈরি করলে একই ধারণা প্রযোজ্য: ওয়েব এবং নেটিভ মোবাইলকে আলাদা কনজিউমার হিসেবে বিবেচনা করুন। যদিও তারা একই ব্যাকএন্ড শেয়ার করে, তারা বেশ বিরলভাবে একেকটি ফিল্ড ও নিয়ম একদম একইভাবে নির্ভর করে।\n\n## API কনট্র্যাক্টে কী রাখবেন (যাতে এটি বাস্তব ব্রেক ধরবে)\n\nএকটি API কনট্র্যাক্ট তখনই সাহায্য করে যখন এটি আপনার ওয়েব ও মোবাইল ক্লায়েন্টরা সত্যিই কি নির্ভর করে তা প্রতিফলিত করে। যদি স্পেসটি সুন্দর হয় কিন্তু কেউ ব্যবহার না করে তাহলে তা প্রোডাকশনের ব্রেক ধরবে না।\n\nবাস্তব ব্যবহারের উপর শুরু করুন, অনুমান নয়। সবচেয়ে সাধারণ ক্লায়েন্ট কলগুলো (আপনার অ্যাপ কোড, API গেটওয়ে লগ, অথবা টিমদের শর্ট লিস্ট থেকে) নিন এবং সেগুলোকে কনট্র্যাক্ট কেসে পরিণত করুন: সঠিক পাথ, মেথড, হেডার, কোয়েরি প্যারাম, এবং টিপিক্যাল রিকোয়েস্ট বডি শেইপ। এতে কনট্র্যাক্ট ছোট, প্রাসঙ্গিক এবং বিতর্কহীন হয়।\n\nসাকসেস এবং ফেল দুই ধরনের রেসপন্সই অন্তর্ভুক্ত করুন। টিমগুলো প্রায়ই হ্যাপি পাথ কনট্র্যাক্ট-টেস্ট করে এবং ভুলগুলো ভুলে যায়: অথরিটি কোড, এরর শেইপ, এমনকি স্থির এরর কোড/মেসেজও ক্লায়েন্ট নির্ভর করে। যদি মোবাইল অ্যাপ একটি নির্দিষ্ট "email already used" মেসেজ দেখায়, একটি কনট্র্যাক্ট সেই 409 রেসপন্স শেইপ লক ইন করা উচিত যাতে তা হঠাৎ 400 হয় এবং ভিন্ন বডি না হয়ে যায়।\n\nবেশি ব্রেক পড়ে এমন এলাকাগুলোর দিকে বাড়তি মনোযোগ দিন:\n\n- অপশনাল বনাম রিকোয়ার্ড ফিল্ড: কোনো ফিল্ড সরানো সাধারণত নিরাপদ, কিন্তু একটি অপশনাল ফিল্ডকে রিকোয়ার্ড করা বিপজ্জনক।\n- Nulls: কিছু ক্লায়েন্ট null-কে অনুপস্থিতিগুলি থেকে আলাদা ভাবে ট্রিট করে। কি অনুমোদন করা হবে তা সিদ্ধান্ত নিন এবং ধারাবাহিক রাখুন।\n\n- Enums: নতুন মান যোগ করলে পুরনো ক্লায়েন্ট ভেঙে যেতে পারে যদি তারা ক্লোজড লিস্ট ধরে নেয়।\n- Pagination: প্যারাম ও রেসপন্স ফিল্ড (যেমন cursor বা nextPageToken) নিয়ে একমত হোন এবং সেগুলো স্থিতিশীল রাখুন।\n- তারিখ ও সংখ্যার ফরম্যাট: স্পষ্ট করে দিন (ISO স্ট্রিং, integer cents, ইত্যাদি)।\n\n### কনট্র্যাক্ট কিভাবে উপস্থাপন করবেন\n\nএমন একটি ফরম্যাট বেছে নিন যা টিম পড়তে পারে এবং টুলিং ভ্যালিডেট করতে পারে। সাধারণ অপশনগুলো হল JSON Schema, উদাহরণ-ভিত্তিক কনট্র্যাক্ট, বা OpenAPI স্পেক থেকে জেনারেটেড টাইপেড মডেল। বাস্তবে, উদাহরণগুলো প্লাস একটি স্কিমা চেক ভাল কাজ করে: উদাহরণগুলো বাস্তব পে-লোড দেখায়, আর স্কিমা নিয়মগুলো field renamed বা type changed ধরা দেয়।\n\nএকটি সাধারণ নিয়ম: যদি কোনো বদল ক্লায়েন্ট আপডেট বাধ্য করে, তাহলে সেটা কনট্র্যাক্ট টেস্টে ফেইল করা উচিত। এই মানসিকতা কনট্র্যাক্টগুলোকে বাস্তব ব্রেকের উপর ফোকাস রাখতে সাহায্য করে, তাত্ত্বিক পারফেকশনের উপর নয়।\n\n## ধাপে ধাপে: CI পাইপলাইনে কনট্র্যাক্ট টেস্ট যোগ করুন\n\nAPI কনট্র্যাক্ট টেস্টিংয়ের লক্ষ্য সহজ: কেউ যখন API পরিবর্তন করে, আপনার CI-কে বলবে যে কোন ওয়েব বা মোবাইল ক্লায়েন্ট যদি ব্রেক হয় তা রিলিজের আগে জানিয়ে দেবে।\n\n### 1) ক্লায়েন্টরা আসলে কী নির্ভর করে সেটা ধরুন\n\nএকটি এন্ডপয়েন্ট নিয়ে শুরু করুন এবং বাস্তবে গুরুত্বপূর্ণ এক্সপেকটেশনগুলো লিখে নিন: রিকোয়ার্ড ফিল্ড, ফিল্ড টাইপ, অনুমোদিত মান, স্ট্যাটাস কোড, এবং সাধারণ এরর রেসপন্স। পুরো API একসাথে বর্ণনা করার চেষ্টা করবেন না। মোবাইল অ্যাপগুলোর জন্য পুরানো অ্যাপ ভার্সনসমূহের এক্সপেকটেশনও অন্তর্ভুক্ত করুন, কারণ ব্যবহারকারীরা তাত্ক্ষণিক আপডেট করে না।\n\nএটি করার একটি ব্যবহারিক উপায় হল কয়েকটি বাস্তব রিকোয়েস্ট তুলে নেয়া (লগ বা টেস্ট ফিক্সচারের থেকে) এবং সেগুলোকে রিপিটেবল উদাহরণে পরিণত করা।\n\n### 2) কনট্র্যাক্টগুলো সেই জায়গায় রাখুন যেখানে টিমগুলো রক্ষণাবেক্ষণ করবে\n\nকনট্র্যাক্টগুলো ভাসমান ফোল্ডারে থাকলে সেগুলো ফেইল হয়। কোড যে জায়গায় বদল হবে, সেখানে রাখুন:\n\n- যদি একই দল দুই পাশে দুটোই মেইনটেইন করে, তাহলে কনট্র্যাক্ট API রেপোসহিত রাখুন।\n- যদি আলাদা টিম ওয়েব, মোবাইল এবং API-তে থাকে, একটি শেয়ার্ড রেপো ব্যবহার করুন যা টিমগুলো মালিকানায় রাখে, এক ব্যক্তির নয়।\n- কনট্র্যাক্ট আপডেটকে কোডের মতো বিবেচনা করুন: রিভিউড, ভার্শনড, এবং আলোচনা সাপেক্ষ।\n\n### 3) CI-তে উভয় পাশে চেক যোগ করুন\n\nআপনি দুটি সিগন্যাল চান:\n\n- প্রতি API বিল্ডে প্রোভাইডার ভেরিফিকেশন: "API কি এখনও সকল পরিচিত কনট্র্যাক্ট পূরণ করে?"\n- প্রতি ক্লায়েন্ট বিল্ডে কনজিউমার চেক: "এই ক্লায়েন্ট কি এখনও সর্বশেষ প্রকাশিত কনট্র্যাক্টের সাথে কম্প্যাটিবল?"\n\nএটি উভয় দিক থেকে সমস্যা ধরবে। যদি API কোনো রেসপন্স ফিল্ড বদলে দেয়, API পাইপলাইন ফেল করবে। যদি কোনো ক্লায়েন্ট নতুন ফিল্ড আশা করা শুরু করে, ক্লায়েন্ট পাইপলাইন ফেল করবে যতক্ষণ না API সেটি সাপোর্ট করে।\n\n### 4) ফেল নিয়ম নির্ধারণ করুন এবং এনফোর্স করুন\n\nকোনটা মার্জ বা রিলিজ ব্লক করবে তা স্পষ্টভাবে লিখে রাখুন। একটি প্রচলিত নিয়ম: কোনো কনট্র্যাক্ট-ব্রেকিং চেঞ্জ CI-তে ফেল করে মেইন ব্র্যাঞ্চে মার্জ ব্লক করে। যদি ব্যতিক্রম দরকার হয়, লিখিত সিদ্ধান্ত (উদাহরণ: সমন্বিত রিলিজ তারিখ) প্রয়োজন।\n\nকংক্রিট উদাহরণ: ব্যাকএন্ড totalPrice কে total_amount রিনেম করে। প্রোভাইডার ভেরিফিকেশন সঙ্গে সঙ্গেই ফেল করে, তাই ব্যাকএন্ড টিম নতুন ফিল্ড যোগ করে পুরনোটি অস্থায়ীভাবে রাখে, এবং উভয় ওয়েব ও মোবাইল নিরাপদে চালিয়ে যায়।\n\n## সংস্করণ নিয়ন্ত্রণ ও ব্যাকওয়ার্ড কম্প্যাটিবিলিটি টিম ধীর না করে কিভাবে বজায় রাখবেন\n\nদ্রুতগতির টিমগুলো সাধারণত তখনই API ভাঙে যখন তারা বর্তমান ক্লায়েন্টদের নির্ভরতার উপরে পরিবর্তন করে। একটা "ব্রেকিং চেঞ্জ" হলো কিছু যা আগের কাজ করা অনুরোধকে ব্যর্থ করে বা রেসপন্সকে এমনভাবে পরিবর্তন করে যে ক্লায়েন্ট সেটি সামলাতে পারে না।\n\nএগুলো সাধারণ ব্রেকিং পরিবর্তনসমূহ (এন্ডপয়েন্ট থাকলেও):\n\n- রেসপন্স ফিল্ড সরানো যা ক্লায়েন্ট পড়ে\n- ফিল্ড টাইপ পরিবর্তন করা (যেমন "total": "12" থেকে "total": 12)\n- একটি অপশনাল ফিল্ডকে রিকোয়ার্ড করা (অথবা নতুন একটি রিকোয়ার্ড রিকোয়েস্ট ফিল্ড যোগ করা)\n- অথ নিয়ম বদলানো (একটি পাবলিক এন্ডপয়েন্ট এখন টোকেন চায়)\n- স্ট্যাটাস কোড বা এরর শেইপ পরিবর্তন করা (200 থেকে 204, বা নতুন এরর ফরম্যাট)\n\nঅধিকাংশ টিম ভিন্ন, নিরাপদ বিকল্প বেছে নিয়ে ভার্শন বাড়ানো এড়াতে পারে। যদি বেশি ডেটা লাগবে, নতুন ফিল্ড যোগ করুন রিনেম করার বদলে। যদি একটি ভাল এন্ডপয়েন্ট দরকার হয়, একটি নতুন রুট যোগ করুন এবং পুরনো রুট চালু রাখুন। ভ্যালিডেশন শক্ত করতে চাইলে পুরনো ও নতুন ইনপুট দুইটাই কিছু সময় ধরে গ্রহণ করুন, তারপর ধীরে ধীরে নতুন নিয়ম চালু করুন। কনট্র্যাক্ট টেস্ট এখানে কাজে লাগে কারণ এটি আপনাকে প্রমাণ করতে বাধ্য করে যে এক্সিস্টিং কনজিউমাররা তাদের প্রত্যাশিত রেসপন্স পাচ্ছে।\n\nডিপ্রিকেশন হচ্ছে সেই অংশ যা ইউজারকে ক্ষতিগ্রস্ত না করে গতিকে রাখে। ওয়েব ক্লায়েন্ট প্রতিদিন আপডেট করতে পারে, কিন্তু মোবাইল অ্যাপগুলি অ্যাপ স্টোর রিভিউ ও ধীরে-ধীরে গ্রহণের কারণে সপ্তাহগুলো পিছুটান করতে পারে। ডিপ্রিকেশন প্ল্যান বাস্তব ক্লায়েন্ট আচরণের উপর নির্ধারিত করুন, আশা নয়।\n\nএকটি ব্যবহারিক ডিপ্রিকেশন পলিসি দেখতে এমন হতে পারে:\n\n- আগে থেকে পরিবর্তন ঘোষণা করুন (রিলিজ নোট, ইন্টারনাল চ্যানেল, টিকিট)\n- পুরনো আচরণ সেইতখন পর্যন্ত রাখুন যতক্ষণ না ব্যবহার কমে একটি সম্মত থ্রেশহোল্ডের নিচে\n- ডিপ্রিকেট করা পাথ ব্যবহৃত হলে হেডারে/লগে ওয়ার্নিং রিটার্ন করুন\n- অপসারণের তারিখ সেভাবে সেট করুন যে বেশিরভাগ ক্লায়েন্ট আপগ্রেড করেছে কিনা নিশ্চিত হয়ে নিন\n- শুধুমাত্র তখন পুরনো আচরণ মুছুন যখন কনট্র্যাক্ট টেস্ট দেখায় আর কোনো সমর্থিত কনজিউমার সেটি ব্যবহার করে না\n\nস্পষ্ট ভার্শনিং ব্যবহার করুন যখন আপনি ব্যাকওয়ার্ড কম্প্যাটিবল না করে পরিবর্তন করতে পারবেন না (উদাহরণ: রিসোর্স শেপ বা সিকিউরিটি মডেলে মৌলিক পরিবর্তন)। ভার্শনিং দীর্ঘমেয়াদি খরচ যোগ করে: আপনাকে এখন দুই আচরণ, দুই ডকসেট, ও আরো এজ কেস মেইনটেইন করতে হবে। ভার্শনগুলো বিরল ও সচেতনভাবে রাখুন, এবং কনট্র্যাক্ট ব্যবহার করে নিশ্চিত করুন দুই ভার্শনও সঠিক যতক্ষণ না পুরনোটা মুছে ফেলা যায়।\n\n## সাধারণ কনট্র্যাক্ট টেস্টিং ভুলগুলো (এবং কীভাবে এড়াবেন)\n\nকনট্র্যাক্ট টেস্টিং সবচেয়ে ভাল কাজ করে যখন এটি বাস্তব প্রত্যাশাগুলো চেক করে, খেলনা সিস্টেম নয়। বেশিরভাগ ব্যর্থতা কয়েকটি পূর্বাভাসযোগ্য প্যাটার্ন থেকে আসে যেগুলো টিমগুলোকে নিরাপদ মনে করায় অথচ বাগ প্রোডাকশনে ঢুকিয়ে দেয়।\n\n### ভুল 1: কনট্র্যাক্টকে "ফ্যান্সি মক" হিসেবে দেখা\n\nওভার-মকিং ক্লাসিক ফাঁদ: কনট্র্যাক্ট টেস্ট পাস করে কারণ প্রোভাইডার আচরণ কনট্র্যাক্টের সাথে মেলানো মক করা হয়েছিল, বাস্তব সার্ভিস সেটা করতে পারে না। ডেপ্লয়ের সময় বাস্তব কলেই প্রথমবার ব্যর্থতা আসে।\n\nনিরাপদ নিয়ম: কনট্র্যাক্টগুলো রানিং প্রোভাইডারের বিরুদ্ধে ভেরিফাই করুন (অথবা এমন একটি বিল্ড আর্টিফ্যাক্টের বিরুদ্ধে যা একইভাবে আচরণ করে), স্টাবbed সার্ভিস নয়—রিয়াল সিরিয়ালাইজেশন, রিয়াল ভ্যালিডেশন, এবং রিয়াল অথ রুলস নিয়ে।\n\nসর্বাধিক দেখা ভুল এবং স্থায়ী ফিক্সগুলো:\n\n- প্রোভাইডার আচরণ অতিমাত্রায় মক করা: কনট্র্যাক্টগুলো রিয়াল প্রোভাইডার বিল্ডের বিরুদ্ধে ভেরিফাই করুন, স্টাবের নয়।\n- কনট্র্যাক্ট খুব কঠোর করা: IDs, টাইমস্ট্যাম্প, ও অ্যারের মত বিষয়গুলোর জন্য ফ্লেক্সিবল ম্যাচিং ব্যবহার করুন; প্রতিটি ফিল্ড আসলে ক্লায়েন্ট নির্ভর করে কি না তা যাচাই করুন।\n- এরর রেসপন্স ইগনোর করা: টপ এরর কেসগুলো (401, 403, 404, 409, 422, 500) অন্তত কনট্র্যাক্ট-টেস্ট করুন এবং ক্লায়েন্ট যে এরর বডি পার্স করে তা অন্তর্ভুক্ত করুন।\n- স্পষ্ট মালিকানা না থাকা: যখন চাহিদা বদলে যায় তখন কে কনট্র্যাক্ট আপডেট করবে তা নির্ধারণ করুন; API পরিবর্তনের “definition of done”-এর অংশ বানান।\n- মোবাইল বাস্তবতা ভুলে যাওয়া: ধীর নেটওয়ার্ক এবং পুরোনো অ্যাপ ভার্সনের কথা মাথায় রেখে টেস্ট করুন, শুধু নতুন বিল্ড ও দ্রুত Wi‑Fi নয়।\n\n### ভুল 2: ভঙ্গু কনট্র্যাক্ট যা হ্যার্মলেস পরিবর্তনও ব্লক করে\n\nযদি কনট্র্যাক্ট প্রতিটি নতুন অপশনাল ফিল্ড যোগ করতেই ফেল করে বা JSON কি-র অর্ডারিং বদলালেই ব্লক করে, ডেভেলপাররা লাল বিল্ড ইগনোর করতে শুরু করবে। তা করলে উদ্দেশ্য ব্যর্থ হয়।\n\nপ্রয়োজন যেখানে কঠোর সেখানে কঠোর থাকুন। প্রয়োজনীয় ফিল্ড, টাইপ, এনাম মান ও ভ্যালিডেশন রুলে কড়া থাকুন। অতিরিক্ত ফিল্ড, অর্ডারিং, এবং প্রাকৃতিকভাবে পরিবর্তিত মান নিয়ে নমনীয় থাকুন।\n\nএকটি ছোট উদাহরণ: আপনার ব্যাকএন্ড status কে "active" | "paused" থেকে "active" | "paused" | "trial"-এ বাড়ায়। যদি মোবাইল অ্যাপ অননন-চেন মান পেলে ক্র্যাশ করে, এটা ব্রেকিং চেঞ্জ। কনট্র্যাক্ট সেট করা উচিত ক্লায়েন্ট কিভাবে অননন-চেন এনাম মান হ্যান্ডেল করে তা চেক করতে, অথবা প্রোভাইডারকে নতুন মান রিটার্ন না করতে বলবে যতক্ষণ না সব ক্লায়েন্ট হ্যান্ডেল করতে পারে।\n\nমোবাইল ক্লায়েন্টদের একটু বেশি মনোযোগ দিন কারণ তারা বেশি দিন জীবিত থাকে। কোনো API পরিবর্তনকে "নিরাপদ" বলার আগে প্রশ্ন করুন:\n\n- পুরোনো অ্যাপ ভার্সনগুলো কি এখনও রেসপন্স পার্স করতে পারবে?\n- টাইমআউটের পরে রিকোয়েস্ট রিট্রাই করলে কি হবে?\n- ক্যাশড ডেটা নতুন ফরম্যাটের সঙ্গে সংঘর্ষ করবে কি?\n- ফিল্ড অনুপস্থিত হলে আমাদের ফ্যালব্যাক আছে কি?\n\nআপনার APIs দ্রুত জেনারেট বা আপডেট হলে (AppMaster সহ), কনট্র্যাক্টগুলো একটি প্রায়োগিক গার্ডরেইল: এগুলো দ্রুতগতিতে কাজ করতে দেয় এবং প্রত্যেক পরিবর্তনের পরে প্রমাণ দেয় যে ওয়েব এবং মোবাইল ক্লায়েন্টগুলো এখনও কাজ করে।\n\n## শিপের আগে দ্রুত চেকলিস্ট\n\nAPI চেঞ্জ মার্জ বা রিলিজ করার ঠিক আগে এইটা ব্যবহার করুন। এটা সেই ছোট-ছোট এডিটগুলো ধরতে ডিজাইন করা হয়েছে যা দ্রুত ওয়েব ও মোবাইল শিপিংয়ের সময় বড় আগুন লাগায়। যদি আপনি ইতিমধ্যেই কনট্র্যাক্ট টেস্টিং করেন, এই তালিকাটা আপনাকে ফোকাস করতে সাহায্য করবে যে কোন ব্রেকগুলো কনট্র্যাক্টগুলো ব্লক করা উচিত।\n\n### প্রতিবার জিজ্ঞেস করার ৫টি প্রশ্ন\n\n- আমরা কি কোনো রেসপন্স ফিল্ড যোগ, সরানো বা রিনেম করেছি যা ক্লায়েন্ট পড়ে (নেস্টেড ফিল্ডসহ)?\n- কোনো স্ট্যাটাস কোড বদলেছে (200 বনাম 201, 400 বনাম 422, 404 বনাম 410), বা এরর বডি ফরম্যাট বদলেছে?\n- কোনো ফিল্ড রিকোয়ার্ড থেকে অপশনাল বা উল্টোভাবে বদলেছে ("null হতে পারে" বনাম "অবশ্যই উপস্থিত থাকতে হবে")?\n- সোর্টিং, পেজিনেশন, বা ডিফল্ট ফিল্টার কি বদলেছে (পেজ সাইজ, অর্ডারিং, কার্সর টোকেন, ডিফল্ট)?\n- প্রোভাইডার এবং সকল অ্যাকটিভ কনজিউমারের (ওয়েব, iOS, Android, এবং অভ্যন্তরীণ টুলস) জন্য কনট্র্যাক্ট টেস্ট চলেছে কি?\n\nএকটি সহজ উদাহরণ: আপনার API আগে totalCount রিটার্ন করত, এবং একটি ক্লায়েন্ট সেটি ব্যবহার করে "24 ফলাফল" দেখায়। আপনি এটা মুছে ফেললেন কারণ "লিস্টে আইটেমগুলোই আছে"। ব্যাকএন্ডে কিছু ক্র্যাশ হয়নি, কিন্তু UI কিছু ব্যবহারকারীর জন্য খালি বা "0 ফলাফল" দেখাতে শুরু করে। এটা রিয়েল ব্রেকিং চেঞ্জ, যদিও এন্ডপয়েন্ট 200 রিটার্ন করছে।\n\n### যদি কোনো প্রশ্নে "হ্যাঁ" উত্তর হয়ে যায়\n\nশিপ করার আগে এই দ্রুত ফলো-আপগুলো করুন:\n\n- পুরোনো ক্লায়েন্টগুলো আপডেট ছাড়া কাজ করবে কি না নিশ্চিত করুন। যদি না হয়, একটি ব্যাকওয়ার্ড-কম্প্যাটিবল পথ যোগ করুন (পুরনো ফিল্ড রাখুন, অথবা কিছু সময় দুটো ফরম্যাট সাপোর্ট করুন)।\n- ক্লায়েন্টে এরর হ্যান্ডলিং চেক করুন। অনেক অ্যাপ অপরিচিত এরর শেইপকে "কিছু ভুল হয়েছে" হিসেবে ট্রিট করে এবং দরকারী মেসেজ লুকিয়ে দেয়।\n\nআপনি যদি অভ্যন্তরীণ টুল দ্রুত তৈরি করেন (উদাহরণ: একটি অ্যাডমিন প্যানেল বা সাপোর্ট ড্যাশবোর্ড), সেসব কনজিউমারকেও অন্তর্ভুক্ত করুন। AppMaster-এ টিমগুলো প্রায়শই একই ব্যাকএন্ড মডেল থেকে ওয়েব ও মোবাইল জেনারেট করে, যা ভুলবশত মনে করায় সব ক্লায়েন্ট একইভাবে নির্ভর করে—কিন্তু ছোট স্কিমা টুইকও শিপ করা ক্লায়েন্ট ভাঙাতে পারে যদি CI-তে কনট্র্যাক্ট চেক না থাকে।\n\n## উদাহরণ: ওয়েব ও মোবাইল শিপের আগে একটি ব্রেক ধরার কাহিনী\n\nএকটি সাধারণ সেটআপ কল্পনা করুন: API টিম দিনে একাধিক বার ডেপ্লয় করে, ওয়েব অ্যাপ প্রতিদিন শিপ করে, এবং মোবাইল অ্যাপ সপ্তাহে একবার শিপ করে (অ্যাপ স্টোর রিভিউ ও স্টেজড রোলআউটের কারণে)। সবাই দ্রুত চলছে, তাই প্রকৃত ঝুঁকি মন্দ উদ্দেশ্য নয়—ছোট বদলগুলোই যা নিরীহ মনে হয় কিন্তু ব্রেক করে দেয়।\n\nএকটি সাপোর্ট টিকিট ইউজার প্রোফাইল রেসপন্সে ক্লিয়ার নামের অনুরোধ করে। API টিম GET /users/{id}-এ একটি ফিল্ড রিনেম করে phone থেকে mobileNumber।\n\nএ রিনেমিংটা টুকিটুকি মনে হলেও এটা ব্রেকিং। ওয়েব ক্লায়েন্ট প্রোফাইল পেজে ফাঁকা ফোন নম্বর দেখাতে পারে। মোবাইল ক্লায়েন্ট যদি phone-কে রিকোয়ার্ড ধরে এবং সেটি নেই বলে ভ্যালিডেশন ফেইল করে, ক্র্যাশ হতে পারে।\n\nকনট্র্যাক্ট টেস্ট থাকলে এটা ব্যবহারকারীর কাছে পৌঁছানোর আগে ধরা পড়ে। কীভাবে ফেইল হয় তা রানিং কনফিগারেশনের ওপর নির্ভর করে:\n\n- প্রোভাইডার বিল্ড ফেল করে (API সাইড): API CI জবটি ওয়েব ও মোবাইল থেকে সংরক্ষিত কনজিউমার কনট্র্যাক্টগুলোর বিরুদ্ধে প্রোভাইডার ভেরিফাই করে। এটি দেখে ক্লায়েন্টরা এখনও phone আশা করছে, কিন্তু প্রোভাইডার এখন mobileNumber ফেরত দিচ্ছে, তাই ভেরিফিকেশন ফেল করে এবং ডেপ্লয় ব্লক করে।\n- কনজিউমার বিল্ড ফেল করে (ক্লায়েন্ট সাইড): ওয়েব টিম তাদের কনট্র্যাক্ট আপডেট করে mobileNumber প্রয়োজনীয় হিসেবে API শিপ করার আগে। তাদের কনট্র্যাক্ট টেস্ট ফেল করে কারণ প্রোভাইডার এখনও সেই ফিল্ড সরবরাহ করে না।\n\nকোনভাবেই, ফেলটি আগেই, উচ্চশব্দে এবং স্পেসিফিক—ঠিক কোন এন্ডপয়েন্ট এবং কোন ফিল্ডে মিসম্যাচ আছে বলে দেয়—গতকালের মত "প্রোফাইল পেজ ভাঙা" হিসেবে নয়।\n\nসাধারণত ফিক্স সোজা: পরিবর্তনটা অ্যাডিটিভ রাখুন, ধ্বংসাত্মক নয়। API সাময়িকভাবে দুটি ফিল্ডই রিটার্ন করে:\n\n- mobileNumber যোগ করুন।\n- phone কে অ্যালিয়াস হিসেবে রাখুন (একই ভ্যালু)।\n- কনট্র্যাক্ট নোটে phone ডিপ্রিকেটেড হিসাবে চিহ্নিত করুন।\n- ওয়েব ও মোবাইল mobileNumber পড়তে আপডেট করুন।\n- তখনই phone মুছুন যখন প্রমাণ করেন সব সাপোর্টকৃত ক্লায়েন্ট আপগ্রেড করেছে।\n\nএকটি বাস্তবসম্মত টাইমলাইন চাপের মধ্যেও এমন হতে পারে:\n\n- সোম 10:00: API টিম mobileNumber যোগ করে এবং phone রাখে। প্রোভাইডার কনট্র্যাক্ট টেস্ট পাস করে।\n- সোম 16:00: ওয়েব mobileNumber-এ সুইচ করে এবং শিপ করে।\n- বৃহঃ: মোবাইল mobileNumber-এ সুইচ করে এবং রিলিজ সাবমিট করে।\n- পরবর্তী মঙ্গল: মোবাইল রিলিজ বেশিরভাগ ব্যবহারকারীর কাছে পৌঁছায়।\n- পরবর্তী স্প্রিন্ট: API phone মুছে ফেলে, এবং কনট্র্যাক্ট টেস্ট নিশ্চিত করে আর কোনো সমর্থিত কনজিউমার প্রয়োজন নেই।\n\nএটাই মূল মূল্য: কনট্র্যাক্ট টেস্টগুলো "ব্রেকিং পরিবর্তন রুলেট"কে একটি নিয়ন্ত্রিত, সময়ভিত্তিক ট্রানজিশনে পরিণত করে।\n\n## দ্রুতগতিতে কাজ করা টিমগুলোর পরবর্তী ধাপ (কীভাবে নো-কোড অপশন সহ)\n\nআপনি যদি চান কনট্র্যাক্ট টেস্টগুলো সত্যিই ব্রেকেজ প্রতিরোধ করুক (শুধু আরো চেক যোগ না করে), রোলআউট ছোট রাখুন এবং মালিকানা স্পষ্ট করুন। লক্ষ্য সহজ: রিলিজের আগে ভাঙন ধরুন যাতে ওয়েব ও মোবাইল শিপ করলে ব্যবহারকারীরা ভেঙে না যায়।\n\nহালকা ওজনের রোলআউট প্ল্যান দিয়ে শুরু করুন। প্রথমে সেরা ৩টি এন্ডপয়েন্ট নিন যেগুলো বদলে গেলে সবচেয়ে বেশি ব্যথা দেয়—সাধারণত অথ, ইউজার প্রোফাইল এবং একটি কোর "লিস্ট বা সার্চ" এন্ডপয়েন্ট। ঐগুলো প্রথমে কনট্র্যাক্টেড করুন, তারপর টিম যখন ওয়ার্কফ্লো-এ বিশ্বাস করবে ধীরে ধীরে বাড়ান।\n\nএকটি ব্যবহারিক রোলআউট যাতে ব্যবস্থাপনা থাকে:\n\n- সপ্তাহ 1: শীর্ষ 3 এন্ডপয়েন্টের কনট্র্যাক্ট টেস্ট, প্রতিটি পুল রিকোয়েস্টে চালানো।\n- সপ্তাহ 2: পরবর্তী 5 এন্ডপয়েন্ট যোগ করুন যেগুলো মোবাইলে বেশি ব্যবহৃত।\n- সপ্তাহ 3: এরর রেসপন্স ও এজ কেস (খালি স্টেট, ভ্যালিডেশন এরর) কভার করুন।\n- সপ্তাহ 4: ব্যাকএন্ড পরিবর্তনের জন্য "কনট্র্যাক্ট গ্রীন" রিলিজ গেট হিসেবে ব্যবহার করুন।\n\nএরপর, কাদের কী করবেন তা নির্ধারণ করুন। যখন স্পষ্ট হবে কে ভুলটির মালিক এবং কে পরিবর্তন অনুমোদন করবে, টিমগুলো দ্রুত এগোবে।\n\nসহজ ভূমিকা রাখুন:\n\n- কনট্র্যাক্ট মালিক: সাধারণত ব্যাকএন্ড টিম, পরিবর্তন হলে কনট্র্যাক্ট আপডেটের দায়িত্বে।\n- কনজিউমার রিভিউয়ার: ওয়েব ও মোবাইল লিডরা, যারা নিশ্চিত করে পরিবর্তন তাদের ক্লায়েন্টের জন্য নিরাপদ।\n- বিল্ড শেরিফ: দৈনিক বা সাপ্তাহিকভাবে ঘোরানো ব্যক্তি, CI-র কনট্র্যাক্ট ফেল ট্রায়াজ করে।\n- রিলিজ মালিক: সিদ্ধান্ত নেয় রিলিজ ব্লক করবে কি না যদি কনট্র্যাক্ট ভাঙে।\n\nএকটি সফল মেট্রিক ট্র্যাক করুন যার সবাই যত্নশীল। অনেক টিমের জন্য সেরা সিগন্যাল হলো রিলিজের পরে হটফিক্সের সংখ্যা কমে যাওয়া এবং "ক্লায়েন্ট রিগ্রেশন" যেমন অ্যাপ ক্র্যাশ, খালি স্ক্রিন, বা ভাঙা চেকআউট ফ্লো যা API পরিবর্তনের সাথে সম্পর্কিত—এসব কমে গেলে বোঝা যায় পদ্ধতি কাজ করছে।\n\nযদি আপনি আরও দ্রুত ফিডব্যাক চান, নো-কোড প্ল্যাটফর্মগুলো পুনরুৎপাদন কমিয়ে দেয় এবং ড্রিফট কমায়। যখন লজিক বা ডেটা মডেল বদলে, পুনর্জেনারেশন সাহায্য করে সেই ধীর গতির প্যাচগুলোর সঞ্চয়ের ফলে আচরণ বদলে যাওয়া এড়াতে।\n\nআপনি যদি AppMaster দিয়ে API ও ক্লায়েন্ট তৈরি করেন, একটি ব্যবহারিক পরবর্তী ধাপ হবে এখন চেষ্টা করা: একটি অ্যাপ্লিকেশন তৈরি করুন, Data Designer-এ আপনার ডেটা মডেল করুন (PostgreSQL), Business Process Editor-এ ওয়ার্কফ্লো আপডেট করুন, তারপর ক্লাউডে পুনর্জেনারেট ও ডেপ্লয় করুন (অথবা সোর্স কোড এক্সপোর্ট করুন)। এটাকে CI-তে কনট্র্যাক্ট চেকের সাথে জোড়া দিন যাতে প্রতিটি পুনর্জেনারেটেড বিল্ড প্রমাণ করে যে এটি ওয়েব ও মোবাইল যা আশা করে তা মেলে।