Staging বনাম Production

এই বিভাগের এখন পর্যন্ত সবকিছু একটি সাইটের একটি কপি live করা বর্ণনা করেছে। একবার সেই সাইট আসল ব্যবহারকারীদের কাছে গুরুত্বপূর্ণ হয়ে গেলে, সেই live কপি সরাসরি সম্পাদনা করা কাজ করার একটি নিরাপদ উপায় থাকা বন্ধ করে দেয় — এই পাঠ কভার করে কেন, আর এটির জায়গায় কী আসে।

Production শুধু সেই term যা বর্ণনা করে সাইটের যে কপি আসল ভিজিটররা বর্তমানে ব্যবহার করছে। যা কিছু production ভাঙে তা তাৎক্ষণিকভাবে দৃশ্যমান, সবার কাছে, কোনো সতর্কতা ছাড়াই — একটি দামে একটি বানান ভুল, একটি ভাঙা checkout button, একটি পাতা যা লোড হতে ব্যর্থ হয়।

একটি staging পরিবেশ হলো সাইটের একটি আলাদা, প্রায়-অভিন্ন কপি — একই কোড, একই হোস্টিং সেটআপ, সাধারণত বাস্তবসম্মত-কিন্তু-নকল ডেটাসহ একটি আলাদা database — শুধুমাত্র একটি ব্যক্তিগত বা তালিকাভুক্ত-নয় ঠিকানায় পৌঁছানো যায়, যেখানে পরিবর্তনগুলো production-এ পৌঁছানোর আগে পরীক্ষা করা হয়। staging-এ একটি ভুল আসল ভিজিটরদের কাছে অদৃশ্য, ডিজাইন অনুসারে।

Git-based deployment পাঠ উল্লেখ করেছিল প্রতিটি pull request স্বয়ংক্রিয়ভাবে নিজস্ব সাময়িক URL পাওয়া। সেটিই staging তার যৌক্তিক শেষ পর্যন্ত নেওয়া — একটি নির্দিষ্ট staging কপি একটি সম্পূর্ণ দল দ্বারা ভাগ করা আর সম্ভবত ঝগড়া করা নয়, বরং প্রতিটি একক প্রস্তাবিত পরিবর্তনের জন্য একটি নতুন নিষ্পত্তিযোগ্য পরিবেশ, merge বা close হওয়ার পর মুছে ফেলা। এই বিভাগে আগে কভার করা বেশিরভাগ আধুনিক cloud আর managed প্ল্যাটফর্ম কোনো অতিরিক্ত খরচ ছাড়াই default হিসেবে এটি অন্তর্ভুক্ত করে।

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