سایت تست یا Staging، نسخهٔ همزاد سایت شماست که خراب کردنش هیچ هزینهای ندارد: هر بهروزرسانی، تغییر قالب و افزونهٔ جدید، اول آنجا آزمایش میشود و فقط تغییرِ سالم به سایت اصلی میرسد. در راهنماهای قبلی (نگهداری، بکاپ، سایزینگ سرور) بارها گفتیم «اول روی نسخهٔ تست»؛ این مقاله همان قطعهٔ وعدهدادهشده است: چرا لازم است، سه سطح ساختنش، آموزش قدمبهقدم نسخهٔ وردپرسی، و قواعدی که staging را از یک ریسک تازه به یک بیمهٔ واقعی تبدیل میکند.
چرا سایت تست، ارزانترین بیمهٔ سایت شماست؟
الگوی آشنای تیکتهای اضطراری را قبلاً در راهنمای نگهداری گفتهایم: بهروزرسانی انباشته، ناسازگاری دو افزونه، صفحهٔ سفید، و فروشگاهی که وسط روز کاری پایین است. نقطهٔ مشترک همهٔ این حادثهها یک چیز است: اولین اجرای تغییر، روی سایت زنده بوده. staging دقیقاً همین یک متغیر را عوض میکند؛ اولین اجرا همیشه جایی اتفاق میافتد که مشتری نمیبیند.
سود دومش کمتر گفته میشود: staging جای تمرین است. تمرین بازیابی بکاپ که در استراتژی بکاپ ماهانه توصیه کردیم، طبیعیترین محل اجرایش همینجاست؛ بازطراحی و تغییرات بزرگ (بدون از دست دادن رتبه) هم بدون محیط تست، عملاً بندبازی بیتور است.
سه سطح staging؛ از رایگان تا همزاد کامل
| سطح | هزینه | شباهت به سایت اصلی | مناسب چه کسی |
|---|---|---|---|
| لوکال (روی سیستم خودتان) | رایگان | کم؛ PHP و سرور متفاوت | توسعهٔ قالب و کد، یادگیری |
| سابدامین روی همان هاست | تقریباً رایگان | زیاد؛ همان محیط واقعی | اکثر سایتها؛ انتخاب پیشفرض |
| سرور جداگانه | هزینهٔ یک VPS کوچک | کامل و ایزوله | فروشگاه بزرگ و اپلیکیشن؛ تیمدار |
برای بیشتر سایتهای وردپرسی، سابدامین روی همان هاست نقطهٔ تعادل است: محیط (نسخهٔ PHP، دیتابیس، تنظیمات سرور) همان محیط واقعی است و هزینهاش فقط کمی فضای دیسک است. سرور جدا وقتی معنا پیدا میکند که تستهای سنگین، خودشان سایت اصلی را کند کنند یا تیم توسعه همزمان چند کار باز داشته باشد؛ سایز مناسبش را با راهنمای انتخاب منابع سرور بردارید، معمولاً کوچکترین پلن کافی است.
ساخت staging وردپرسی روی سابدامین؛ قدمبهقدم
چهار قدم اصلی دارد. اول، سابدامین بسازید (مثلاً staging روی دامنهٔ اصلی) و در پوشهٔ جدا مستقر کنید. دوم، یک بستهٔ کامل از سایت اصلی بردارید، فایلها و دیتابیس با هم، درست همانطور که در راهنمای بکاپ گفتهایم، و در مقصد باز کنید: دیتابیس در یک دیتابیس جدید ایمپورت شود و فایلها در پوشهٔ سابدامین. سوم، آدرسها را در دیتابیس جایگزین کنید؛ ابزار استاندارد این کار فرمان search-replace در WP-CLI است:
wp search-replace 'https://www.your-site.ir' 'https://staging.your-site.ir' --all-tables --dry-run
wp search-replace 'https://www.your-site.ir' 'https://staging.your-site.ir' --all-tablesاول با dry-run ببینید چه چیزی عوض میشود، بعد اجرای واقعی. اگر WP-CLI در دسترس ندارید، ابزارهای جایگزین جایگزینی امن در دیتابیس هم همین کار را میکنند؛ چیزی که مجاز نیستید انجام بدهید، جایگزینی مستقیم متن در فایل خروجی SQL با ویرایشگر است، چون دادههای سریالیشدهٔ وردپرس را میشکند و خرابیاش گاهی هفتهها بعد ظاهر میشود.
قدم چهارم، راستیآزمایی دوقلو بودن است: نسخهٔ PHP و تنظیمات کلیدی دو محیط را کنار هم بگذارید، ورود به پیشخوان staging را تست کنید و مطمئن شوید آدرسهای داخلی همه به سابدامین تست اشاره میکنند، نه به سایت اصلی؛ لینکی که به سایت زنده برگردد، یعنی جایگزینی ناقص بوده. و قدم پنجم که همه فراموش میکنند، در بخش بعد آمده: قفل کردن درها.
سه دری که باید همان روز اول قفل شود
- درِ گوگل: staging نباید ایندکس شود، وگرنه محتوای تکراری میسازد و گاهی بهجای سایت اصلی در نتایج مینشیند. تنظیم «مرئی نبودن برای موتورهای جستجو» بهعلاوهٔ رمز HTTP روی کل سابدامین؛ روشهای کامل را در راهنمای جلوگیری از ایندکس وردپرس نوشتهایم. رمز، مطمئنترین لایه است چون خطای پیکربندی را هم میپوشاند.
- درِ ایمیل: نسخهٔ تستِ فروشگاه، همان تنظیمات ایمیل سایت اصلی را با خودش آورده؛ یعنی هر تست سفارش، برای مشتری واقعی ایمیل میفرستد. ارسال ایمیل staging را با افزونهٔ قطع ارسال یا SMTP ساختگی ببندید، همان روز اول.
- درِ درگاه و سرویسهای بیرونی: کلیدهای درگاه پرداخت، پیامک و هر وبهوک متصل به سیستمهای واقعی، در staging باید حذف یا با نسخهٔ تستی جایگزین شود؛ وگرنه «تست» شما تراکنش و پیامک واقعی تولید میکند.
گردش کار درست؛ دو خیابان یکطرفه
ذهنیترین و مهمترین قاعدهٔ staging این است: کد به بالا میرود، محتوا به پایین میآید. تغییرات کد (قالب، افزونه، تنظیمات) مسیرشان از staging به production است، بعد از تست. محتوا و داده (سفارشها، مطالب جدید، کاربران) مسیرشان برعکس است: هر چند وقت یکبار از production به staging کپی میشوند تا محیط تست تازه بماند. فاجعهٔ کلاسیک staging دقیقاً از شکستن همین قاعده میآید: کسی دیتابیس staging را روی سایت زنده برمیگرداند و سفارشها و مطالب امروز، با نسخهٔ کهنهٔ دیروز جایگزین میشود. اگر فقط یک قاعده از این مقاله یادتان بماند، همین باشد.
برای کدِ اختصاصی، این گردش کار با گیت رسمیتر و امنتر میشود: تغییرات در شاخهٔ جدا، استقرار روی staging، تست، و بعد ادغام و استقرار روی production؛ کتاب رایگان Pro Git مرجع کامل این مسیر است. برای سایت وردپرسی معمولی هم بدون گیت، همان نظمِ «اول staging، بعد اصلی» با یک چکلیست ساده قابل اجراست؛ مهم نظم است، نه ابزار.
داستان تکراری؛ بهروزرسانی بزرگ در ظهر پنجشنبه
دو نسخه از یک روز را کنار هم بگذاریم؛ الگویی که در تیکتهای پشتیبانی بارها دیدهایم. نسخهٔ اول، بدون staging: فروشگاه ووکامرسی، اعلان بهروزرسانی بزرگ را میبیند و مدیر سایت، وسط روز کاری، روی سایت زنده کلیک میکند. قالبِ چندساله با نسخهٔ جدید ناسازگار است؛ صفحهٔ پرداخت خطا میدهد، و چون خطا فقط در مرحلهٔ آخر خرید ظاهر میشود، تا کسی گزارش بدهد چند ساعت گذشته. باقی روز، صرف برگرداندن بکاپ و جواب دادن به مشتریان عصبانی میشود و بهروزرسانی هم برای ماهها به «بعداً» تبعید میشود؛ یعنی سایت، هم امروز را باخت هم امنیتِ فردا را.
نسخهٔ دوم، همان روز با staging: همان کلیک، این بار روی نسخهٔ تست. همان ناسازگاری، همان خطای پرداخت، ولی اینبار در محیطی که هیچ مشتریای در آن نیست. مدیر سایت با خیال راحت گزارش خطا را برای توسعهدهندهٔ قالب میفرستد، نسخهٔ اصلاحشده چند روز بعد میرسد، دوباره در staging تست میشود و در ساعت کمترافیک به سایت اصلی میرود. مجموع خسارت: صفر. تفاوت این دو روز، نه ابزار خاصی بود نه تخصص بیشتر؛ فقط جای «اولین اجرا» عوض شده بود.
چکلیست تست دهدقیقهای؛ نمونهٔ آماده
بعد از هر تغییر در staging، این فهرست را به ترتیب اجرا کنید؛ برای سایت خودتان یکبار تنظیمش کنید و همیشه همان را بروید تا هیچ مسیری از قلم نیفتد:
- صفحهها: صفحهٔ اصلی، دو صفحهٔ داخلی مهم و یک مطلب وبلاگ باز شود؛ ظاهر، منو و تصاویر سالم باشد. یک آدرس ناموجود هم بزنید تا صفحهٔ ۴۰۴ درست کار کند.
- فرمها: فرم تماس را واقعاً ارسال کنید و برسیدن پیام به مقصدِ تستی مطمئن شوید؛ فرمی که بیخطا «ارسال شد» میگوید ولی به جایی نمیرسد، فریبندهترین خرابی است.
- حساب کاربری: ورود، خروج و بازیابی رمز؛ اگر ثبتنام باز است، یک ثبتنام آزمایشی.
- مسیر خرید (برای فروشگاه): جستجوی محصول، افزودن به سبد، و پیشروی تا مرحلهٔ پرداخت با درگاه تستی؛ خطاهای ناسازگاری معمولاً همین آخر مسیر پنهان شدهاند.
- کنسول و سرعت: کنسول مرورگر بدون خطای جدید باشد و سرعت نسبی صفحات، محسوس بدتر نشده باشد؛ مقایسهٔ دقیق را با همان ابزارهای پایش انجام بدهید.
همین ده دقیقه، اکثر خرابیهایی را میگیرد که در حالت بیstaging، مشتریها پیدایشان میکردند.
اشتباهات رایج staging
- staging کهنه: نسخهٔ تستی که شش ماه از سایت اصلی عقب است، دیگر همزاد به حساب نمیآید و تستش دربارهٔ سایت واقعی چیزی نمیگوید. زمانبندی تازهسازی ماهانه (یا قبل از هر تغییر بزرگ) را در همان تقویم نگهداری بگذارید که در راهنمای هزینه نگهداری ساختیم.
- دادهٔ واقعی مشتری، بیحفاظ: کپی کامل دیتابیس یعنی نام و شماره و آدرس مشتریان حالا در محیطی است که رمزش سادهتر و مراقبتش کمتر است. یا staging را مثل production حفاظت کنید یا دادهٔ حساس را هنگام کپی ناشناس کنید.
- تست فقط صفحهٔ اصلی: خطاها معمولاً در مسیرهای عمیقاند: پرداخت، فرمها، جستجو، صفحهٔ حساب کاربری. یک چکلیست تست دهدقیقهای بنویسید و همان را هر بار اجرا کنید؛ الهامش را از چکلیست کامل سایت وردپرسی بگیرید.
- اعتماد به «افزونهٔ staging یککلیکی» بدون فهم: این ابزارها کار را راحت میکنند ولی سه درِ بخش قبل را همیشه نمیبندند؛ بعد از هر ساخت خودکار، ایندکسپذیری و ایمیل و کلیدها را خودتان چک کنید.
سوالات متداول دربارهٔ سایت تست
ساخت staging چقدر زمان میبرد؟
بار اول، برای سایت وردپرسی متوسط، حدود نیم روز با احتساب قفل کردن درها و راستیآزمایی؛ دفعههای بعد که فقط تازهسازی است، در حد یک ساعت و با اسکریپت، چند دقیقه. این سرمایهگذاری یکباره را با هزینهٔ یک بعدازظهرِ فروشگاهِ پایین مقایسه کنید تا اولویتش روشن شود.
روی هاست اشتراکی هم میشود staging ساخت؟
بله؛ همان الگوی سابدامین در بیشتر پنلهای اشتراکی قابل اجراست و فقط فضای دیسک کافی میخواهد، چون staging تقریباً همحجم سایت اصلی است. اگر فضای پلن تنگ است، نسخهٔ تست را بدون پوشهٔ آپلودهای قدیمی بسازید یا پلن را یک پله بالا ببرید؛ صفحهٔ هاست گزینهها را دارد.
برای فروشگاهِ در حال فروش، staging چه فرقی دارد؟
دو سختگیری اضافه: تازهسازی داده باید بیشتر باشد (فروشگاهِ پرتغییر، همزادِ کهنه را زود بیمعنا میکند) و قفل ایمیل و درگاه، حیاتیتر است چون اشتباهش مستقیم به مشتری واقعی میرسد. برای فروشگاههای بزرگ، سرور تست جدا و روال استقرار منظم را جدی بگیرید؛ همخانوادهٔ همان توصیههایی که در ووکامرس در مقیاس بالا آمده.
برای نسخهٔ لوکال چه ابزاری مناسب است؟
برای وردپرس، ابزارهای اختصاصی مثل LocalWP راهاندازی را به چند کلیک میرسانند و برای مسیر عمومیتر، همان پشتهٔ کلاسیک روی سیستم خودتان کار میکند؛ مفهوم و راهاندازیاش را در راهنمای لوکال هاست نوشتهایم. فقط یادتان بماند لوکال، محیطِ توسعه است و جای تستِ نهایی را نمیگیرد؛ تفاوت نسخهٔ PHP و پیکربندی سرور، همان جایی است که «روی سیستم من کار میکرد» ساخته میشود.
هر چند وقت یکبار staging را تازه کنیم؟
پیشفرض منطقی، ماهانه بهعلاوهٔ قبل از هر تغییر بزرگ. علامت نیاز به تازهسازی زودتر: وقتی تفاوت رفتاری بین تست و اصلی میبینید که با خود تغییر توضیح داده نمیشود؛ یعنی دو محیط از هم فاصله گرفتهاند.
دادهٔ مشتری را در staging چطور ناشناس کنیم؟
هنگام کپی دیتابیس، فیلدهای شناسایی (ایمیل، شماره، آدرس) را با مقادیر ساختگی جایگزین کنید؛ برای ووکامرس و وردپرس، همین search-replace با الگوهای هدفمند یا اسکریپت کوچک SQL کفایت میکند. مهم این است که ایمیلها به دامنهٔ تستی بروند تا اگر قفل ایمیل هم شکست، پیامی به آدم واقعی نرسد.
staging به سئوی سایت اصلی ضرر نمیزند؟
اگر درِ گوگل را درست بسته باشید، خیر؛ ریسک فقط از staging رهاشده و ایندکسشده میآید که محتوای تکراری میسازد. چک سادهاش این است: آدرس سابدامین تست را در گوگل جستجو کنید و اگر نتیجهای دیدید، همان روز رمز HTTP و حذف از نتایج را انجام بدهید. با رمزگذاری از روز اول، این سوال عملاً موضوعیتش را از دست میدهد؛ خزندهای که وارد نشود، چیزی هم ایندکس نمیکند.
staging و بکاپ چه نسبتی دارند؟
مکمل هماند و جای هم را نمیگیرند: بکاپ برای برگشتن از حادثه است و staging برای جلوگیری از حادثه. اتفاقاً بهترین تمرین ماهانهٔ بازیابی که در راهنمای بکاپ خواستیم، همین است: بستهٔ بکاپ را روی staging باز کنید؛ با یک کار، هم بکاپ را ثابت کردهاید هم نسخهٔ تست را تازه.
با تیم چند نفره، یک staging کافی است؟
تا وقتی کارها نوبتی است، بله؛ مشکل از همزمانی شروع میشود، وقتی دو تغییرِ همزمان روی یک محیط تست، خطاهای همدیگر را میپوشانند. آن نقطه، زمان رفتن به سرور تست جدا و گردش کار گیتی است که بالاتر گفتیم؛ نشانهٔ خوبی هم هست، یعنی سایت شما به بلوغ تیمی رسیده.
