Optistream তাদের এক হাজার পাবলিক পেজের কোনোটির SEO না হারিয়েই বারোটি কাস্টম WordPress plugin-কে একটি একক codebase-এ একত্রিত করেছে।
কেন এই মার্জটি গুরুত্বপূর্ণ ছিল
একটি সাধারণ WordPress সাইটে হাতেগোনা কয়েকটি plugin থাকে; কিন্তু বড় সাইটগুলো দেখতে তারের জট পাকানো কোনো ওয়ার্কশপের মতো মনে হয়, যেখানে প্রতিটি তার কাজ করছে ঠিকই কিন্তু কোনোটিই সহজে খুলে ফেলা যায় না। Optistream-এর সাইটে বারোটি কাস্টম (bespoke) plugin চলত যা স্ট্রীমার প্রোফাইল, ইস্পোর্টস টিম এবং গেম ডেটা পরিচালনা করত। এই pluginগুলো থেকে এক হাজারটি ইনডেক্সযোগ্য (indexable) পেজ তৈরি হতো। সেই URL-গুলো অক্ষত রাখা ছিল অপরিহার্য—যেকোনো পরিবর্তন এই মাইগ্রেশন প্রক্রিয়াটিকে ব্যর্থ করে দিতে পারত।
পুরনো সেটআপটি কেমন ছিল
বারোটি plugin-এর প্রতিটি নিজস্ব ফোল্ডারে ছিল, নিজস্ব custom post type রেজিস্টার করত এবং WordPress-এর বিভিন্ন পয়েন্টে হুক (hook) করত। সমস্যাগুলো স্তূপাকারে জমতে শুরু করল:
- Hooks এবং assets গুলো ছড়িয়ে ছিটিয়ে ছিল, যার ফলে কখন কোন কোড রান করছে তা বোঝা কঠিন ছিল।
- Routing logic অনেকগুলো আলাদা ফাইলে ছিল, তাই একটি মাত্র URL একাধিক plugin দ্বারা প্রভাবিত হতে পারত।
- CSS ফাইলগুলো একটি অনির্দেশ্য ক্রমে লোড হতো, যার ফলে স্টাইল নিয়ে সংঘর্ষ (clashes) তৈরি হতো।
- Debugging করার জন্য বারোটি আলাদা ডিরেক্টরি খুলতে হতো, যা যেকোনো ডেভেলপারের জন্য প্রচুর সময়ের অপচয়।
লক্ষ্য ফাইল সংখ্যা কমানো ছিল না; বরং লক্ষ্য ছিল পুরো সিস্টেমটিকে একটি একক লাইফসাইকেল (lifecycle) প্রদান করা এবং ডিপেন্ডেন্সি (dependencies) ম্যানেজ করার জন্য একটি নির্দিষ্ট জায়গা তৈরি করা।
মাইগ্রেশনটি কীভাবে পরিকল্পনা করা হয়েছিল
টিমটি পাবলিক ইন্টারফেস—URL, টেমপ্লেট এবং মেটা ডেটাকে একটি চুক্তির (contract) মতো বিবেচনা করেছিল যা ভাঙা সম্ভব নয়। ফ্রন্ট-এন্ডে যেকোনো পরিবর্তন মানেই ছিল ব্যর্থতা। এই নিয়মটি মাথায় রেখে তারা প্রতিটি ধাপের পর অনুসরণ করার জন্য একটি চেকলিস্ট তৈরি করেছিল।
১. পাবলিক কন্ট্রাক্টগুলোর তালিকা তৈরি করা
প্রতিটি URL পাথ তার post type, rewrite slug, template file এবং এর ওপর নির্ভরশীল meta key-সহ লিখে রাখা হয়েছিল। এই স্প্রেডশিটটি একটি নিয়মপুস্তিকা (rulebook) হিসেবে কাজ করত: যদি কোনো মডিউল সরানোর পর কোনো URL পরিবর্তিত হতো, তবে মাইগ্রেশনটি রোলব্যাক (rollback) করা হতো।
২. একটি সহজ লোডার তৈরি করা
একটি ছোট bootstrap ফাইল তৈরি করা হয়েছিল। প্রতিটি প্রাক্তন plugin এখন একটি অনুমানযোগ্য ফাংশন নামের মাধ্যমে একটি একক “content domain” রেজিস্টার করে। লোডারটি খুব জটিল কিছু করে না—প্রয়োজন অনুযায়ী WordPress-এ সঠিক মডিউলটি টেনে আনার জন্য এটি যথেষ্ট। সরলতা ব্যর্থতাগুলোকে স্পষ্ট করে তোলে।
৩. ডেটা সুরক্ষিত রাখা
Meta key-গুলোর নাম পরিবর্তন করলে কোড পরিবর্তনটি একটি ডেটা মাইগ্রেশনে পরিণত হতো, যা অপ্রয়োজনীয় ঝুঁকি বাড়াত। পুরনো কী (keys) গুলো অপরিবর্তিত রাখা হয়েছিল; নতুন হেল্পার ফাংশনগুলো সেগুলোকে র্যাপ (wrap) করে রাখে, যা ডেটাবেস স্কিমাকে স্থিতিশীল রাখে।
৪. CSS মালিকানা ঠিক করা
তিনটি পদক্ষেপের মাধ্যমে স্টাইলিং সংক্রান্ত সংঘর্ষ সমাধান করা হয়েছিল:
- মডিউল CSS ফাইলগুলোকে উচ্চ অগ্রাধিকার (high priority) দিয়ে enqueue করা হয় যাতে সেগুলো সবার শেষে লোড হয়।
- প্রতিটি মডিউলের জন্য সমস্ত selector একটি অনন্য wrapper class-এর মধ্যে সীমাবদ্ধ (scoped) রাখা হয়।
- স্টাইলশিট পরিবর্তন হলে ব্রাউজার ক্যাশ (cache) ক্লিয়ার করার জন্য enqueue করার সময়
filemtime()ব্যবহার করা হয়।
৫. একটি নিরাপদ লুপ ব্যবহার করা
মাইগ্রেশনটি একবারে একটি করে মডিউল নিয়ে এগিয়েছে। একটি মডিউল সরানোর পর, পরবর্তী মডিউলে হাত দেওয়ার আগে টিমটি post-type registration, routing এবং মোবাইল লেআউট যাচাই করে নিত। মূল plugin-গুলো ইনস্টল করা থাকলেও নিষ্ক্রিয় (inactive) অবস্থায় রাখা হয়েছিল, যা তাৎক্ষণিক রোলব্যাক করার সুযোগ তৈরি করে দিয়েছিল।
প্রোডাকশন চেকলিস্ট
প্রতিটি মডিউল পরিবর্তনের পর টিমটি যাচাই করত:
- প্রতিটি content-type URL একটি 200 HTTP স্ট্যাটাস প্রদান করছে কি না।
- Canonical URL হেডারটি মূল URL-এর সাথে মিলছে কি না।
- পেজ টাইটেল এবং মেটা ডেসক্রিপশন অপরিবর্তিত আছে কি না।
- সমস্ত ইমেজ কোনো ব্রোকেন লিঙ্ক ছাড়াই লোড হচ্ছে কি না।
- মোবাইল স্ক্রিনে কোনো হরিজন্টাল ওভারফ্লো (horizontal overflow) দেখা যাচ্ছে কি না।
- ব্রাউজার কনসোলে কোনো JavaScript বা CSS এরর দেখাচ্ছে কি না।
চেকলিস্ট সফলভাবে সম্পন্ন হওয়ার পরেই টিমটি পুরনো plugin-টি স্থায়ীভাবে ডিঅ্যাক্টিভেট (deactivate) করেছিল।
নতুন pluginটি কী প্রদান করে
এর ফলে তৈরি হওয়া একক plugin-টি codebase-এর আকার ছোট করেনি; এটি কেবল সীমানাগুলোকে দৃশ্যমান করেছে। বারোটি কার্যকরী ক্ষেত্র এখন একটি একক লাইফসাইকেল, এক সেট হুক এবং ডিপেন্ডেন্সি ম্যানেজ করার জন্য একটি নির্দিষ্ট জায়গা শেয়ার করে। নতুন plugin-টি সিস্টেমকে ছোট করেনি, বরং এর সীমানাগুলোকে স্পষ্ট করেছে। এটি কম সংখ্যক plugin থাকার চেয়েও বেশি কার্যকর প্রমাণিত হয়েছে।
ঝুঁকি এবং পাল্টা যুক্তি
Optistream-এর ঘটনাটি দেখায় যে একটি সুশৃঙ্খল 'contract-first' পদ্ধতি এবং ধাপে ধাপে রোলআউট ঝুঁকি নিয়ন্ত্রণে রাখতে পারে।
পরবর্তীতে যা খেয়াল রাখতে হবে
আপনি যদি অনুরূপ কোনো একত্রীকরণের (consolidation) কথা ভাবেন, তবে এই দুটি স্তম্ভ দিয়ে শুরু করুন:
- URL স্থিতিশীলতা – কোডের একটি লাইন লেখার আগেই প্রতিটি পাবলিক পাথ ম্যাপ করে নিন।
- ডেটা স্থিতিশীলতা – ডেটাবেস ফিল্ডের নাম পরিবর্তন করা এড়িয়ে চলুন, যদি না আপনি একটি পূর্ণাঙ্গ মাইগ্রেশনের জন্য প্রস্তুত থাকেন।
এরপর, একটি ছোট লোডার তৈরি করুন, CSS স্কোপড (scoped) রাখুন, এবং একটি কঠোর প্রোডাকশন চেকলিস্ট অনুসরণ করে একবারে একটি করে মডিউল স্থানান্তর করুন।