একটি সাম্প্রতিক ডেপ্লয়মেন্ট তিনটি মাইক্রোসার্ভিসকে ভেঙে ফেলেছে, যদিও প্রতিটি ইউনিট টেস্ট, ইন্টিগ্রেশন টেস্ট এবং মক-সার্ভার চেক সফল হয়েছিল। দলটি তাদের এপিআই মকের পরিবর্তে কন্ট্রাক্ট টেস্টিং ব্যবহার শুরু করে। ছয় মাসে কন্ট্রাক্টের সংখ্যা ৩ থেকে বেড়ে ৪৭ হয়েছে এবং মাসিক ইন্টিগ্রেশন-ব্যর্থতার হার দুটি ঘটনা থেকে শূন্যে নেমে এসেছে।
কেন মক আপনাকে রক্ষা করতে পারে না
একটি মক সার্ভার কেবল কনজিউমার যা আশা করে তার একটি আকৃতি বা ফরম্যাট অনুকরণ করে; এটি কখনোই পরীক্ষা করে না যে প্রোভাইডার আসলে সেই ফরম্যাটটি প্রদান করছে কিনা। যদি একজন প্রোভাইডার একটি ফিল্ডের নাম পরিবর্তন করে—ধরা যাক name থেকে display_name—তবে মকটি তখনও পুরনো পেলোডটিই রিটার্ন করবে, কনজিউমারের টেস্টগুলো সবুজ (pass) দেখাবে, কিন্তু লাইভ সিস্টেম ক্র্যাশ করবে। মঙ্গলবার দুপুর ২টায় প্রোডাকশনে যে ব্যর্থতা ঘটেছিল তা ছিল ঠিক এটাই: মকটি আসল কন্ট্রাক্ট সম্পর্কে "মিথ্যা" বলেছিল।
কন্ট্রাক্ট টেস্টিং শূন্যতা পূরণ করে
কন্ট্রাক্ট টেস্টিং এপিআই-এর উভয় পক্ষকে কোনো কোড প্রোডাকশনে যাওয়ার আগেই একটি সাধারণ সংজ্ঞায় একমত হতে বাধ্য করে। এখানে দুটি সাধারণ পদ্ধতি রয়েছে:
- কনজিউমার-ড্রিভেন কন্ট্রাক্ট (Consumer-driven contracts) – কনজিউমিং সার্ভিসটি তার প্রত্যাশাগুলো লিখে রাখে; প্রোভাইডিং সার্ভিসটি সেগুলো যাচাই করে। এটি এমন অভ্যন্তরীণ মাইক্রোসার্ভিসের জন্য ভালো কাজ করে যা একসাথে বিবর্তিত হয়।
- প্রোভাইডার-ড্রিভেন কন্ট্রাক্ট (Provider-driven contracts) – প্রোভাইডার একটি স্পেসিফিকেশন প্রকাশ করে; কনজিউমাররা তাদের কোড তার বিপরীতে পরীক্ষা করে। পাবলিক এপিআই-এর ক্ষেত্রে এটিই সাধারণ প্যাটার্ন।
প্রথম পদ্ধতিটি সাধারণত একটি মাইক্রোসার্ভিস আর্কিটেকচারের ভেতরে ইন্টিগ্রেশন ভেঙে যাওয়া রোধ করে।
একটি কনজিউমার-ড্রিভেন কন্ট্রাক্ট কীভাবে কাজ করে
- কনজিউমার একটি টেস্ট লেখে যা প্রোভাইডারের কাছ থেকে তার ঠিক কী প্রয়োজন তা বর্ণনা করে।
- টেস্টটি চালালে একটি pact file তৈরি হয় – এটি একটি JSON ডকুমেন্ট যা সেই প্রত্যাশাগুলো রেকর্ড করে।
- প্রোভাইডার তার CI পাইপলাইনে pact file-এর বিপরীতে তার আসল সার্ভিসটি চালায়।
- যদি প্রোভাইডার কোনো ফিল্ড পরিবর্তন করে, তবে ভেরিফিকেশন ব্যর্থ হয় এবং বিল্ডটি আটকে যায়।
যেহেতু ভেরিফিকেশনটি আসল প্রোভাইডার কোডের ওপর চালানো হয়, তাই যেকোনো ব্রেকিং চেঞ্জ ডেপ্লয়মেন্টের আগেই ধরা পড়ে।
আপনার টেস্ট পিরামিডে কন্ট্রাক্ট টেস্টের অবস্থান কোথায়
- ইউনিট টেস্ট (Unit tests) – দ্রুত, আইসোলেটেড লজিক পরীক্ষা করে।
- কন্ট্রাক্ট টেস্ট (Contract tests) – মাঝারি গতি, এপিআই চুক্তিগুলো বজায় আছে কিনা তা নিশ্চিত করে।
- এন্ড-টু-এন্ড টেস্ট (End-to-end tests) – ধীরগতিসম্পন্ন, সম্পূর্ণ বিজনেস ফ্লো পরীক্ষা করে।
কন্ট্রাক্ট টেস্টগুলোকে ইউনিট টেস্টের দ্রুত ফিডব্যাক এবং এন্ড-টু-এন্ড সুইটের ব্যাপক কভারেজের মধ্যে একটি সেতু হিসেবে বিবেচনা করুন। যে ইন্টিগ্রেশন পয়েন্টগুলো সবচেয়ে বেশি ভেঙে যায় সেগুলোকে লক্ষ্য করুন এবং দুই বা তিনটি গুরুত্বপূর্ণ এন্ডপয়েন্ট দিয়ে শুরু করুন।
বাস্তব জগতের প্রয়োগের গল্প
এই নিবন্ধটির অনুপ্রেরণা যে দলটি, তারা তাদের সবচেয়ে ভঙ্গুর কলগুলো কভার করার জন্য মাত্র তিনটি কন্ট্রাক্ট দিয়ে শুরু করেছিল। ছয় মাস পরে তাদের কাছে ৪৭টি কন্ট্রাক্ট ছিল যা বেশিরভাগ ইন্টার-সার্ভিস ট্রাফিক কভার করেছিল। সেই সময়ে এপিআই ব্রেকিং ইনসিডেন্ট প্রতি মাসে দুটি থেকে কমে শূন্যে নেমে আসে।
কখন কন্ট্রাক্ট টেস্টিং করা সার্থক নাও হতে পারে
- আপনি একজন একক ডেভেলপার যিনি সমস্ত সার্ভিস একটি সিঙ্গেল রিপোজিটরিতে রাখছেন।
- এপিআই অত্যন্ত স্থিতিশীল এবং বছরের পর বছর ধরে পরিবর্তিত হয়নি।
- আপনি এমন একটি থ্রো-অ্যাওয়ে প্রোটোটাইপ তৈরি করছেন যা শীঘ্রই ফেলে দেওয়া হবে।
এই ধরনের পরিস্থিতিতে কন্ট্রাক্ট রক্ষণাবেক্ষণের অতিরিক্ত পরিশ্রম এর সুবিধার চেয়ে বেশি হতে পারে।
সম্ভাব্য অসুবিধা এবং সেগুলো কীভাবে প্রশমিত করা যায়
- কন্ট্রাক্টগুলোকে সেগুলোর বর্ণনামূলক কোডের সাথে ভার্সন অনুযায়ী রাখুন।
- পুরনো বা স্টেল (stale) কন্ট্রাক্ট এড়াতে প্রতিটি CI রানে ভেরিফিকেশন অটোমেট করুন।
- আকস্মিক কোনো সমস্যা ধরার জন্য পুল রিকোয়েস্টে কন্ট্রাক্ট পরিবর্তনগুলো রিভিউ করুন।
মূল কথা
আপনি যদি এখনও আপনার সার্ভিসগুলো একে অপরের সাথে কথা বলতে পারে কিনা তা নিশ্চিত করতে হাতে তৈরি মকের ওপর নির্ভর করেন, তবে আপনি একটি মিথ্যা প্রতিশ্রুতির ওপর বাজি ধরছেন। কন্ট্রাক্ট টেস্টিং সেই বাজিটিকে একটি যাচাইযোগ্য চুক্তিতে রূপান্তরিত করে, যা প্রোডাকশনে পৌঁছানোর আগেই ব্রেকিং চেঞ্জগুলো ধরে ফেলে এবং ওই দলের পরিসংখ্যান যেমন দেখায়, এটি ইন্টিগ্রেশন ব্যর্থতা সম্পূর্ণরূপে নির্মূল করতে পারে।