১৬ ফেব্রুয়ারী, সোমবার, ২০১৫
(আমাজন ওয়েব সার্ভিস -এ যাবার পর হওয়া) 'যা শিখলাম' - মিটিং এর নোট.
Notes from the 'Lessons learned' meeting after we moved to Amazon Web Service.
"পুরো প্রজেক্টে কী শিক্ষনীয় ছিল, কী আরো ভালো ভাবে করা যেতো, তার উপরে একটা Lessons learned মিটিং হয়েছে। ওই মিটিং-র সারমর্ম নিয়ে কোনো এক লেখায় লিখব আশা করি। "
প্রথমে কিছু টার্ম আপনাদের বলে নেই। পুরো সিস্টেম ডেভেলপমেন্ট মূলত ৩ টি স্তরে হয়। ডেভেলপার-রা তাদের মেশিন-এ যা তৈরী করেন প্রথমে সেটা Release Candidate বা RC1 - নামের একটা ছোট সিস্টেমে ডেপ্লয় হয়। এটা মূল প্রোডাকশন সিস্টেমের ছোটখাটো রেপ্লিকা। এর উদ্দেশ্যই হচ্ছে আগেভাগেই বাগ (bug) বের করা। টেস্টার বা কোয়ালিটি এসুরান্স টীম (QA team) -এর টার্গেট হচ্ছে এই RC1 সিস্টেম। QA Team এখানেই তাদের সব ধরনের টেস্ট করে। এর পরের ধাপ হচ্ছে Staging - এটা মূলত সব কনফিগারেশন ঠিকঠাক আছে কীনা দেখার জন্য ব্যবহার হয়। Staging প্রোডাকশন -এর খুবই কাছাকাছি একটা সিস্টেম। কিন্তু এতে RC1-এর মতই পুরো ডাটাবেস-র কপি থাকে না। RC1 এবং Staging সার্ভারে সব টেস্ট পাস করলেই কেবল প্রোডাকশন -এ কোড ডেপ্লয় করে লাইভ করা হয়। সব শেষে, DNS সার্ভার আপডেট করে কাস্টমারদের জন্য খুলে দেয়া হয় (এরা মজা করে একে 'flood gate opening' বলে)। পোস্ট প্রোডাকশন অর্থাৎ প্রোডাকশন -এ যাবার পর QA টীম রিগ্রেশন টেস্ট, স্মোক টেস্ট ইত্যাদি করে থাকে।
এবার আসি মিটিং -এ কী আলাপ হলো সে ব্যাপারে।
তিন গ্রুপের অর্থাৎ, সিস্টেম-, এপ্লিকেশন- এবং কোয়ালিটি এস্যুরান্স গ্রুপের দৃষ্টিকোণ থেকে "কী ভালো হয়েছে" আর "কী আরো ভালোভাবে করা যেত" - এই নিয়ে সবার খোলামেলা আলোচনা হয়েছে। আমি শুধু সবার মতে "কী আরো ভালোভাবে করা যেত" এই অংশ নিয়েই লিখছি।
- আরো বেশি ডেভেলপার এই প্রজেক্টে নেয়া যেত। সবাই শুরু থেকেই কাজ না করলেও, সবার একটা পরিষ্কার ধারণা থাকা দরকার ছিল। ডেডলাইন যখন কাছাকাছি, তখন নতুন করে ডেভেলপার (অন্য প্রজেক্ট থেকে সরিয়ে) এই প্রজেক্ট-এ নেয়ায় নতুন প্রত্যেকেরই প্রজেক্ট সম্পর্কে শিখতে অনেক সময় লেগেছে। যারা শিখিয়েছে, তাদেরও অনেক সময় নষ্ট হয়েছে।
- কোনো ভাবে কাজে একটা শিফট বা রোটেশন-এর ব্যবস্থা থাকা দরকার ছিল। সবাই একসাথে কাজে ঝাপিয়ে পড়ায়, পরে সবাই একসাথেই ক্লান্ত হয়ে পড়েছিল। ভবিষ্যতে এ ব্যপারে একটা বুদ্ধি বের করতে হবে।
- RC1 আর Staging সার্ভার একই কনফিগারেশন আর ডেটা নিয়ে সেটআপ করা দরকার ছিল। এদের ভিন্নতায় পরে অনেক কনফিগারেশন ইস্স্যু তৈরী হয়েছে, যা ঠিক করতে অযথাই অনেক সময় নষ্ট হয়েছে।
- পুরো প্রজেক্টের আর্কিটেকচার ডিটেল সবার সাথেই আলোচনা করা দরকার ছিল। কেউ বুঝুক আর নাই বুঝুক, সবাইকেই আর্কিটেকচার সম্পর্কে জানানোর দরকার ছিল। পরবর্তীতে, আর্কিটেকচার ডিটেল না জানার কারণে অনেক টেস্ট কেস QA টীম অনিচ্ছাকৃত ভাবে বাদ দিয়েছে। সেইগুলো পরে বুঝিয়ে নতুন করে টেস্ট কেস তৈরী করাতে প্রচুর সময় নষ্ট হয়েছে।
- অনেক সময়ই ডেভেলপাররা নিজেদের মধ্যে অনেক টার্ম বা সংক্ষিপ্ত শব্দ ব্যবহার করে। এইগুলো সবার সাথেই শেয়ার করা দরকার ছিল।
- আর্কিটেকচার-এর বিভিন্ন অংশের জন্য ভিন্ন ভিন্ন এক্সপার্ট বা কন্টাক্ট পারসন থাকা বা ঠিক করা দরকার ছিল। একে SME বা Subject Matter Expert বলে। ওরকম কেউ না থাকায়, সব প্রশ্নের জন্যই সবাই এক জনের কাছেই গেছে (সব কোম্পানিতে -ই বোধহয় এইরকম একজন 'বস' লোক থাকে যার কাছে কিনা সবাই সাহায্যের জন্য যায়, আর সেও হাসিমুখে সাহায্য করে যেতেই থাকে!)। এতে করে সেই লোকের কাজে বার বার ব্যঘাত ঘটেছে।
- সব ধরনের ওয়েব ব্রাউসার-এর জন্য সিস্টেম টেস্ট করা উচিত ছিল। বিশেষ করে ইন্টারনেট এক্সপ্লোরার -এর আগের ভার্সন (৭, ৮ এমন কি ১০) গুলোর জন্য।
- ইস্যু ট্র্যাকিং এর জন্য Google Spreadsheet ব্যবহার করা হয়েছিল। ড্যাশবোর্ড -এর মত করে তা ব্যবহার করায় খুব জলদি কোনো ইস্যু বা বাগ লগ করা, ডেভেলপাররা ঠিক বা ফিক্স করার পরে, টেস্ট করে তা 'Hide' বা লুকিয়ে ফেলা হয়েছিল। দ্রুত কাজের জন্য তা ভালো ছিল, কিন্তু সিস্টেম স্ট্যাবল হয়ে যাবার পর অবশ্যই JIRA জাতীয় কোনো ভালো ইস্যু ট্র্যাকিং সিস্টেম ব্যবহার করা উচিত ছিল।
QA ম্যানেজার -র জন্য আরো দুটি গ্রাফ এই স্প্রেডশীট থেকেই তৈরী করা হয়েছিল: প্রথমটি মূলত দিনে QA টীম কয়টা বাগ রিপোর্ট করলো, আর দ্বিতীয়টি এখন পর্যন্ত কতটি বাগ পাওয়া গেলো- তার হিসাব রাখার কাজে ব্যবহার হতো। নিচে তার নমূনা দিলাম:
যেকোনো প্রজেক্টেই প্রজেক্ট ম্যানেজার বা PM নামের একটা পোস্ট থাকে। এদের কাজ মূলত সবার সাথে লিয়াজো ঠিক রাখা। আমাদের এই Lessons Learned মিটিংও এই PM -ই পরিচালনা করেছিল। তার কাছ থেকে ইমেইল পাওয়া মিটিং নোটস থেকেই আজকের লেখা লিখলাম।
ধন্যবাদ।
--ইশতিয়াক
No comments:
Post a Comment