اگر برنامه لاراول شما در حال استفاده است، نسخه جدید را پیش از انتشار در محیطی جدا بررسی کنید. این محیط که معمولاً «استیجینگ» نامیده می‌شود، برای آزمودن تغییرات پیش از رسیدن آن‌ها به کاربران است. خرید یک هاست دیگر فقط شروع کار است؛ نسخه نرم‌افزارها، داده‌ها و اتصال‌های برنامه نیز باید متناسب تنظیم شوند.
محیط آزمایشی باید چه شباهتی به سایت اصلی داشته باشد؟
نسخه PHP، امکانات مورد نیاز برنامه، نوع پایگاه داده و سرویس‌های وابسته را فهرست کنید. لازم نیست صرفاً به خاطر نام استیجینگ همان پلن گران‌تر را تهیه کنید، اما تفاوت محیط‌ها نباید باعث شود یک قابلیت مهم در آزمون اصلاً اجرا نشود. اگر قرار است ظرفیت برنامه سنجیده شود، تفاوت منابع را هم در تفسیر نتیجه لحاظ کنید.
برای مثال، اگر تولید گزارش در سایت اصلی با صف پردازش انجام می‌شود، محیطی که فقط صفحات را باز می‌کند آزمون کامل همان نسخه نیست. پیش از خرید، نیاز صف، زمان‌بندی و ابزارهای استقرار را از توسعه‌دهنده بگیرید و با مشخصات هاست لاراول ایران یا هاست لاراول اروپا تطبیق دهید.
چه چیزهایی باید جدا باشند؟
پایگاه داده، فایل‌های قابل تغییر و اطلاعات اتصال محیط آزمایشی را مستقل در نظر بگیرید. آدرس متفاوت به‌تنهایی ثابت نمی‌کند این بخش‌ها از تولید جدا شده‌اند. از مسئول فنی بخواهید مقصد اتصال‌ها را بررسی کند؛ آزمون یک نسخه نباید ناخواسته داده سایت اصلی را تغییر دهد.
در لاراول، پیکربندی محیط و مدیریت مقادیر حساس در مستند رسمی Configuration توضیح داده شده است. مقادیر مخصوص پروژه باید توسط تیم فنی تعیین شوند. نمایش خطا و تنظیمات توسعه را نیز بدون بررسی به سایت عمومی منتقل نکنید.
داده آزمایشی را چگونه انتخاب کنیم؟
داده نمونه باید مسیرهای مورد نیاز را پوشش دهد: حساب کاربری، سفارش یا پرونده‌ای که برنامه واقعاً با آن کار می‌کند. کپی کامل داده مشتریان، تنها راه ساخت محیط آزمایشی نیست. اگر استفاده از بخشی از داده اصلی ضروری است، شیوه مجاز دسترسی و حذف اطلاعات حساس را با مسئول مربوط مشخص کنید.
در یک فروشگاه فرضی، چند کالای نمایشی و چند وضعیت سفارش برای آزمون جریان خرید مفیدند. این نمونه‌ها نتیجه واقعی فروش یا پرونده مشتری محسوب نمی‌شوند. آن‌ها را طوری نام‌گذاری کنید که تیم بررسی با اطلاعات واقعی اشتباه نگیرد.
اتصال‌های بیرونی را هم آزمایشی کنید
درگاه، پیامک، ایمیل و سرویس‌های دیگر ممکن است حتی در یک زیردامنه آزمایشی عملیات واقعی انجام دهند. از تیم فنی بخواهید برای هر اتصال، حالت آزمایشی یا روش کنترل‌شده مناسب تعیین کند. فقط تغییر نام سایت، جلوی این عملیات را نمی‌گیرد.
بخش | پرسش پیش از شروع آزمون |
|---|---|
پایگاه داده | آیا مقصد از تولید جداست؟ |
فایل‌ها | آیا تغییر فایل در این محیط روی سایت اصلی اثر دارد؟ |
سرویس بیرونی | آیا عملیات نمایشی است یا واقعی؟ |
دسترسی | چه کسانی باید این نسخه را ببینند؟ |
محدودکردن دسترسی به نسخه آزمایشی را نیز متناسب با پروژه انجام دهید. دستور noindex برای کنترل حضور در جست‌وجو است و جای کنترل دسترسی به داده خصوصی را نمی‌گیرد.
چه چیزی را پیش از انتشار بررسی کنیم؟
فهرست کوتاهی از مسیرهای مهم تهیه کنید: ورود، عملیات اصلی، گزارش و فایل‌های مورد نیاز. نتیجه و خطای هر مسیر را ثبت کنید. اگر محیط شما با تولید تفاوت دارد، این تفاوت کنار نتیجه نوشته شود؛ موفقیت در یک آزمون محدود، تضمین عملکرد در هر بار و شرایطی نیست.
پیش از انتشار، نسخه قابل بازیابی و روش بازگشت از تغییر ناموفق را با تیم فنی هماهنگ کنید. راهنمای بکاپ و بازیابی هاست برای روشن‌کردن پوشش نسخه‌ها مفید است. برای انتخاب محل میزبانی نیز مقایسه هاست لاراول ایران و اروپا را بخوانید؛ محل کاربران و سرویس‌های وابسته هر دو اهمیت دارند.
