অপেক্ষা না করিয়ে বড় ওয়ার্কস্পেসে যাওয়া

প্রতিটি Mythex প্রজেক্ট পায় নিজস্ব একটি ওয়ার্কস্পেস: একটি ছোট ক্লাউড কম্পিউটার, যেখানে এজেন্ট কোড লেখে এবং আপনার অ্যাপের প্রিভিউ চলে। আমরা নতুন ওয়ার্কস্পেসের মেমোরি ১ GB থেকে ২ GB করেছিলাম, কিন্তু পুরনোগুলো ১ GB-তেই ছিল — যেদিন আমরা দেখি, প্রায় এক-চতুর্থাংশ। আমাদের প্রথম সমাধান ছিল, প্রজেক্ট পরের বার খোলার সময় সেটিকে একটি বড় ওয়ার্কস্পেসে সরিয়ে নেওয়া। প্রোডাকশনে প্রথম দিনেই এতে একজন ব্যবহারকারীকে সাত মিনিট অপেক্ষা করতে হয়। তাই আমরা সরানোর জন্য একটি কঠোর সময়সীমা বসাই, এবং শেষ পর্যন্ত প্রজেক্ট খোলার কাজ থেকেই সরানোটি সরিয়ে দিই।

পুরনো ওয়ার্কস্পেস কেন ছোট রয়ে গেল

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

এটি গুরুত্বপূর্ণ ছিল। একটি ছোট ওয়ার্কস্পেসে git push চলাকালীন, যখন এর প্রিভিউ শুরু হচ্ছিল, মেমোরি ফুরিয়ে যায়, এবং ১১ মিনিট সাড়া দেয়নি। এর কারণে একটি পাবলিশ ব্যর্থ হয়েছিল।

প্রথম চেষ্টা: জেগে ওঠার সময় প্রজেক্ট সরানো

ব্যবহার না থাকলে ওয়ার্কস্পেস পজ হয়, আর প্রজেক্ট খুললে জেগে ওঠে। জেগে ওঠার সময়টিকেই সরানোর ঠিক মুহূর্ত মনে হয়েছিল, কারণ তখনও কেউ প্রজেক্টে কাজ শুরু করেনি।

সরানোর ধাপগুলো ছিল এরকম:

1. আকার যাচাই। ওয়ার্কস্পেস ২ GB-র কম হলে সরান। আকার অজানা হলে কিছু করা হবে না।
2. পাবলিশে ব্যাঘাত না ঘটানো। পাবলিশ ওয়ার্কস্পেসের ফাইল পড়ে, তাই কোনো পাবলিশ চললে সরানো বাদ দেওয়া হয়।
3. প্রজেক্ট প্যাক করা। প্রজেক্টের সবকিছু আর্কাইভ করা হয় — এর git ইতিহাস সহ, অর্থাৎ প্রজেক্টের প্রতিটি চেকপয়েন্ট, এবং অ্যাপের .env ফাইল, যা মালিকের — তবে ইনস্টল করা ডিপেন্ডেন্সি (node_modules) বাদ দেওয়া হয়, কারণ সেগুলো আবার ইনস্টল করা যায়।
4. সরাসরি কপি। পুরনো ওয়ার্কস্পেস থেকে নতুন ২ GB ওয়ার্কস্পেসে আর্কাইভটি স্ট্রিম করা হয়, যাতে এটি আমাদের নিজের সার্ভারের মেমোরিতে ধরতে না হয়।
5. পরিবর্তনের আগে তুলনা। দুই জায়গায় ফাইল গণনা করা হয়, সর্বশেষ চেকপয়েন্ট পড়া হয়, এবং চেকপয়েন্টের সংখ্যা গোনা হয়। তিনটি মিললে তবেই পরিবর্তন করা হয়।
6. কোনো ব্যর্থতায় পুরনোটি রাখা। যেকোনো ত্রুটি বা অমিল হলে নতুন ওয়ার্কস্পেস বাতিল হয় এবং প্রজেক্ট আগের মতোই পুরনোটিতে খোলে।

তুলনার একটি বিষয় মনে হওয়ার চেয়ে বেশি গুরুত্বপূর্ণ ছিল। এই যাচাই অ্যাডমিন অ্যাকাউন্ট হিসেবে চলে, আর git এমন একটি রিপোজিটরি পড়তে অস্বীকার করে যার মালিক অন্য ব্যবহারকারী। ফলে দুই দিকেই এটি কিছু প্রিন্ট করেনি — আর "কিছু না" এবং "কিছু না" মিলে যাওয়ায় যাচাই কোনো ইতিহাসের তুলনা না করেই পাস করছিল। আমরা git-কে ডিরেক্টরিটিকে বিশ্বাস করতে বলি, এবং যাতে এটি আর ফিরে না আসে সেজন্য একটি টেস্ট যোগ করি।

প্রথম দিনে কী ভুল হলো

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

যে স্থানান্তর কাউকে নিজের প্রজেক্ট খোলার সময় অপেক্ষা করায়, সেটি খারাপ বিনিময়। জেগে ওঠার সময় এটি করার পুরো উদ্দেশ্যই ছিল যেন কেউ টেরই না পায়।

দ্বিতীয় চেষ্টা: একটি কঠোর বাজেট

সেদিনই আমরা চারটি জিনিস বদলাই:

• পুরো সরানোর জন্য এক মিনিট। প্রতিটি ধাপ — আকার যাচাই, প্যাক করা, নতুন ওয়ার্কস্পেস তৈরি, কপি, আনপ্যাক এবং তুলনা — একটিমাত্র ৬০-সেকেন্ডের বাজেট ভাগ করে নেয়। বাজেট শেষ হলে প্রজেক্ট পুরনো ওয়ার্কস্পেসে খোলে।
• শুধু অপেক্ষা নয়, কাজও থামানো। আমাদের দিক থেকে হাল ছেড়ে দিলেই যথেষ্ট নয়, যদি মালিক যে ওয়ার্কস্পেসটি ব্যবহার করতে যাচ্ছেন সেখানে আর্কাইভ করা তখনও চলতে থাকে। এখন প্রতিটি আর্কাইভ কমান্ড সময়সীমা শেষ হওয়ার কিছুক্ষণ আগে ওয়ার্কস্পেসের ভেতরেই বন্ধ করা হয়। আমরা হাল ছাড়ার পরে নতুন ওয়ার্কস্পেস এলে সেটি বাতিল করা হয়।
• মালিককে পরিষ্কারের জন্য অপেক্ষা না করানো। অস্থায়ী আর্কাইভ মুছে ফেলা এখন ব্যাকগ্রাউন্ডে হয়।
• প্রতিবার খোলার সময় আবার চেষ্টা না করা। যে প্রজেক্ট সরানো যায়নি, সেটিকে ২৪ ঘণ্টা আর ছোঁয়া হয় না, তাই একটি ব্যর্থতার খরচ দিনে বড়জোর একটি বিলম্ব, প্রতিবার খোলার জন্য একটি নয়।

তৃতীয় চেষ্টা: জেগে ওঠা থেকে সরিয়ে ফেলা

এতে সবচেয়ে খারাপ ক্ষেত্রেও সময় হলো এক মিনিট। কিন্তু এক মিনিটও এক মিনিট, আর আমরা বুঝলাম যে স্থানান্তরটি কারও পথে থাকার কোনো দরকার নেই।

এখন আর ১ GB-তে কোনো ওয়ার্কস্পেস তৈরি হয় না। তাই এটি চলমান কোনো প্রক্রিয়া নয়; এটি নির্দিষ্ট ওয়ার্কস্পেসের তালিকা ধরে একবারের কাজ। জেগে ওঠার ভেতরে একে রাখার অর্থ ছিল প্রতিটি ধীর স্থানান্তরের মূল্য একজন বাস্তব মানুষ দিচ্ছেন, আর কোনো ওয়ার্কস্পেস সরবে না তা জানার একমাত্র উপায় ছিল কারও অপেক্ষা করা।

তাই আমরা স্থানান্তরটি জেগে ওঠা থেকে পুরোপুরি সরিয়ে দিই। প্রজেক্ট খোলা আগের মতোই কাজ করে। বাকি ছোট ওয়ার্কস্পেসগুলো একটি তদারকি করা ব্যাচ হিসেবে পরিচালিত হয়: কেউ এর জন্য অপেক্ষা করছে না, আর যে ওয়ার্কস্পেস সরবে না, সেটি ব্যাচের রিপোর্টে দেখা যায়, যেখানে আমরা সেটি খতিয়ে দেখতে পারি — মালিকের সামনে নয়।

আমরা যা শিখলাম

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

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