আপনার অ্যাপের জন্য স্টেজিং এনভায়রনমেন্ট কীভাবে সেট আপ করবেন

একটি স্টেজিং এনভায়রনমেন্ট সেট আপ করতে আপনার অ্যাপের একটি দ্বিতীয় কপি একটি আলাদা প্রাইভেট URL-এ ডিপ্লয় করুন, এর নিজস্ব ডাটাবেস ও টেস্ট API কী দিন, এবং এর সেটআপ যতটা সম্ভব প্রোডাকশনের মতো রাখুন। এরপর প্রতিটি গুরুত্বপূর্ণ পরিবর্তন আগে স্টেজিংয়ে রিলিজ করুন, মূল ফ্লোগুলো চালিয়ে দেখুন, এবং স্টেজিং ঠিক দেখালে তবেই প্রোডাকশনে প্রকাশ করুন।

ধারণাটি নতুন হলে স্টেজিং এনভায়রনমেন্ট কী ব্যাখ্যা করে। এই গাইডটি ব্যবহারিক সেটআপের জন্য, যারা DevOps টিম চালান না বরং এআই টুল দিয়ে বানাচ্ছেন তাদের উদ্দেশে লেখা।

ডেভ, স্টেজিং ও প্রোডাকশন

বেশিরভাগ ছোট অ্যাপের তিনটি জায়গা দরকার, যদিও প্রথমটি শুধু আপনার বিল্ডারের প্রিভিউ হতে পারে:

স্টেজিংয়ের উদ্দেশ্য হলো এটি প্রোডাকশনের মতো আচরণ করে — একই কোড, একই স্ট্যাক, একই ধরনের সেটিংস — কিন্তু সেখানে ভুল হলে কারও ক্ষতি হয় না।

ধাপ ১: স্টেজিংকে কিসের সঙ্গে মিলতে হবে তা ঠিক করুন

স্টেজিং তখনই কাজের যখন প্রোডাকশনে সমস্যা দেখা দেওয়ার আগে সেখানে সেগুলো ধরা পড়ে। মেলান:

• একই কোড, একই পদ্ধতিতে রিলিজ হওয়া।
• একই স্ট্যাক ও ভার্সন — ফ্রেমওয়ার্ক, রানটাইম, ডাটাবেসের ধরন।
• একই ধরনের কনফিগারেশন — একই এনভায়রনমেন্ট ভেরিয়েবলের নাম, টেস্ট মানসহ।
• একই সার্ভিসগুলো — প্রোডাকশনে ওয়েব অ্যাপ ও API থাকলে স্টেজিংয়েও দুটোই থাকবে।

আকারে (ছোট মেশিন চলবে) ও ডেটায় এটি আলাদা হতে পারে।

ধাপ ২: কপিটি তৈরি করুন

সবচেয়ে সরল পদ্ধতি: একই প্রজেক্টের একটি দ্বিতীয় ডিপ্লয়মেন্ট, যেমন staging.yourapp.com বা yourapp-staging.example.com-এর মতো ভিন্ন URL-এ।

কীভাবে করবেন তা আপনার হোস্টের ওপর নির্ভর করে:

• বিল্ট-ইন প্রিভিউ বা স্টেজিং ডিপ্লয়মেন্টসহ হোস্ট একটি Git ব্রাঞ্চের জন্য স্বয়ংক্রিয়ভাবে একটি তৈরি করতে পারে।
• যেসব হোস্টে এটি নেই: একই কোড থেকে একটি দ্বিতীয় অ্যাপ বা প্রজেক্ট তৈরি করুন এবং আলাদাভাবে ডিপ্লয় করুন।
• Git-এ থাকা কোড: একটি staging বা main ব্রাঞ্চ রাখুন যা স্টেজিংয়ে ডিপ্লয় হয়, এবং একটি রিলিজ থেকে প্রোডাকশনে ডিপ্লয় করুন। দেখুন এআই দিয়ে বানানো অ্যাপে Git কীভাবে ব্যবহার করবেন।

ধাপ ৩: স্টেজিংকে নিজস্ব ডাটাবেস দিন

এই ধাপটিই আপনাকে রক্ষা করে। স্টেজিং ও প্রোডাকশন যদি একই ডাটাবেস শেয়ার করে, তাহলে একটি টেস্ট যে রেকর্ড মুছবে, তা আসল রেকর্ডই মুছবে।

• স্টেজিংয়ের জন্য একটি আলাদা ডাটাবেস তৈরি করুন।
• এটি সিড ডেটা দিয়ে ভরুন — বাস্তবসম্মত নকল রেকর্ড যা এআই আপনার জন্য তৈরি করতে পারে।
• প্রোডাকশনের ডেটার কপি লাগলে আগে নাম, ইমেইল ও ব্যক্তিগত সব কিছু সরান বা এলোমেলো করে দিন।

সেটআপে ভরসা করার আগে নিশ্চিত হন প্রতিটি কপি কোন ডাটাবেসের সঙ্গে সংযুক্ত। সরাসরি জিজ্ঞেস করুন:

এই অ্যাপটি কোন ডাটাবেসের সঙ্গে সংযুক্ত, এবং এই সেটিংটি কোথা থেকে আসে? পাসওয়ার্ড নয়, ভেরিয়েবলের নামটি দেখাও।

ধাপ ৪: টেস্ট কী ও আলাদা সেটিংস ব্যবহার করুন

বাইরের কোনো সার্ভিসের সঙ্গে কথা বলে এমন সবকিছুতে স্টেজিংয়ে টেস্ট ক্রেডেনশিয়াল ব্যবহার করুন:

• পেমেন্ট টেস্ট মোডে (যেমন Stripe-এর টেস্ট কী), যাতে কোনো আসল কার্ড চার্জ না হয়।
• ইমেইল একটি স্যান্ডবক্সে বা শুধু আপনার নিজের ঠিকানায় পাঠানো, যাতে গ্রাহকরা কখনো টেস্ট বার্তা না পান।
• এআই ও অন্য পেইড API একটি আলাদা কী ও কম খরচের সীমাসহ।
• ওয়েবহুক স্টেজিং URL-এর দিকে নির্দেশিত, প্রোডাকশনের দিকে নয়।

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

ধাপ ৫: স্টেজিং ব্যক্তিগত রাখুন

স্টেজিং পাবলিক থাকা উচিত নয়:

• এটিকে একটি লগইন, পাসওয়ার্ড, বা টিম ইমেইলের অনুমতি-তালিকার পেছনে রাখুন।
• একটি noindex মেটা ট্যাগ বা X-Robots-Tag হেডার দিয়ে সার্চ ইঞ্জিনকে এটি ইনডেক্স করতে দেবেন না।
• আপনার পাবলিক সাইট থেকে এর লিংক দেবেন না।
• এটি আলাদা দেখতে বানান — একটি রঙিন "STAGING" ব্যানার ভুল ট্যাবে পরীক্ষা চালানো আটকায়।

APP_ENV এনভায়রনমেন্ট ভেরিয়েবল "staging" হলে প্রতিটি পেজের শীর্ষে একটি উজ্জ্বল হলুদ ব্যানার যোগ করো যেখানে লেখা থাকবে "STAGING — শুধু টেস্ট ডেটা"। সেই ক্ষেত্রে একটি noindex মেটা ট্যাগও যোগ করো।

ধাপ ৬: একটি রিলিজ রুটিন তৈরি করুন

প্রতিবার ব্যবহার করলেই স্টেজিং কাজে লাগে। একটি সরল রুটিন:

1. ডেভেলপমেন্টে পরিবর্তন করুন এবং প্রিভিউতে যাচাই করুন।
2. স্টেজিংয়ে রিলিজ দিন।
3. আপনার মূল ফ্লোগুলো চালান: সাইন-আপ, লগইন, মূল ফিচার, পেমেন্ট, পরিবর্তনের সঙ্গে সংশ্লিষ্ট যেকোনো কিছু।
4. কিছু ভাঙলে ঠিক করে আবার স্টেজিংয়ে রিলিজ দিন।
5. একই ভার্সন প্রোডাকশনে প্রকাশ করুন।
6. প্রোডাকশন দ্রুত দেখুন — একই ফ্লোগুলো, সংক্ষেপে।

মূল ফ্লোগুলো একটি ছোট টেস্ট স্ক্রিপ্ট হিসেবে লিখে রাখুন। কী অন্তর্ভুক্ত করবেন তা জানতে দেখুন লঞ্চের আগে অ্যাপ কীভাবে টেস্ট করবেন।

ধাপ ৭: ডাটাবেস পরিবর্তন সতর্কতার সঙ্গে সামলান

ডাটাবেসের কাঠামোর পরিবর্তন — একটি কলাম যোগ করা, একটি টেবিলের নাম বদলানো — এমন জায়গা যেখানে স্টেজিং নিজের মূল্য প্রমাণ করে।

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

উদাহরণ প্রম্পট

এই ডাটাবেস পরিবর্তনটি প্রোডাকশনে চালালে বিদ্যমান ডেটার কী হবে ব্যাখ্যা করো। কিছু কি মুছে বা নাম বদলে যাবে?

সব এনভায়রনমেন্ট-নির্দিষ্ট সেটিংস — API URL, কী, ইমেইল প্রেরক, সাইটের নিজস্ব URL — এনভায়রনমেন্ট ভেরিয়েবল থেকে আসুক, স্টেজিং ও প্রোডাকশনে একই নামে। সেগুলোর তালিকা দাও।

এই অ্যাপটি কী করে তার ভিত্তিতে, প্রতিটি রিলিজের আগে স্টেজিংয়ে আমার কোন ফ্লোগুলো টেস্ট করা উচিত তার একটি সংক্ষিপ্ত চেকলিস্ট লেখো।

সাধারণ ভুল

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

চেকলিস্ট

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

Mythex-এ স্টেজিং

Mythex-এর Publish প্রতিটি অ্যাপের জন্য একটি লাইভ URL দেয়; আলাদা কোনো স্টেজিং টগল নেই। বাস্তবে আপনার দুটি বিকল্প আছে:

• রিলিজের আগের যাচাই হিসেবে প্রিভিউ। প্রতিটি প্রজেক্ট একটি ব্যক্তিগত ক্লাউড ওয়ার্কস্পেসে একটি লাইভ Preview-সহ চলে। /test এজেন্টকে একজন ব্যবহারকারীর মতো এটিতে ক্লিক করে ঘুরে দেখতে দেয়, এবং একটি Share লিংক ক্লায়েন্ট বা সহকর্মীকে প্রকাশ না করেই প্রিভিউ রিভিউ করতে দেয়। দেখুন Preview and Code। অনেক একক প্রজেক্টের জন্য এটিই যথেষ্ট।
• স্টেজিং হিসেবে একটি দ্বিতীয় প্রজেক্ট। Pro-তে প্রজেক্টটি এক্সপোর্ট করে একটি নতুন প্রজেক্টে ইমপোর্ট করুন, সেই প্রজেক্টে নিজস্ব ডাটাবেস ও টেস্ট-কী সিক্রেট দিন, এবং এর নিজস্ব স্লাগে প্রকাশ করুন। প্রোডাকশন প্রজেক্ট প্রকাশের আগে এতে রিলিজ দিন।

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

প্রশ্নোত্তর