محیط استیجینگ چیست؟ قبل از انتشار آزمایش کنید
محیط استیجینگ نسخه خصوصی اپ شماست، تا حد امکان نزدیک به نسخه زنده، که در آن تغییرات را پیش از دیدن کاربران واقعی آزمایش می‌کنید. از پایگاه داده، داده‌های آزمایشی و کلیدهای API آزمایشی خودش استفاده می‌کند، پس یک ویژگی خراب یا تغییر بد داده در آن هیچ‌کس بیرون از تیم شما را تحت تأثیر نمی‌گذارد. وقتی تغییری در استیجینگ درست به نظر برسد، آن را به پروداکشن منتشر می‌کنید — اپ زنده‌ای که مشتریانتان استفاده می‌کنند.
چرا استیجینگ هنگام ساخت با هوش مصنوعی مهم است
ساختن با هوش مصنوعی تغییر را سریع می‌کند. می‌توانید یک ویژگی اضافه کنید، یک صفحه را بازنویسی کنید یا ساختار داده را در چند دقیقه عوض کنید. این سرعت تا وقتی که تغییری که درست به نظر می‌رسید، بی‌سروصدا فرایند پرداخت را خراب کند، یا یک «پاکسازی کوچک» ستونی از داده‌های مشتری را پاک کند، عالی است.
جایی برای بررسی تغییرات پیش از زنده شدن به شما کمک می‌کند:
- پیش از مشتریان، خرابی را پیدا کنید. بعد از هر تغییر مهم، جریان‌های ثبت‌نام، پرداخت و کلیدی را امتحان کنید.
- با تنظیمات دنیای واقعی آزمایش کنید. استیجینگ باید مثل پروداکشن رفتار کند — همان پشته و تنظیمات مشابه — تا مشکلات همان‌جا ظاهر شوند، نه بعداً.
- از داده‌های واقعی محافظت کنید. تغییرات پایگاه داده، ایمپورت‌ها و ویرایش‌های گسترده را ابتدا روی داده‌های آزمایشی تمرین کنید.
- کار در حال انجام را نشان دهید. یک مشتری یا همکار می‌تواند بدون عمومی شدن تغییر آن را بررسی کند.
یک تشبیه روزمره
به تمرین لباس یک تئاتر فکر کنید.
- توسعه اتاق تمرین است: بازیگران خطوط را امتحان می‌کنند، می‌ایستند، دوباره شروع می‌کنند و آزمایش می‌کنند.
- استیجینگ تمرین generale است: لباس کامل، صحنه واقعی، نورهای واقعی — همه‌چیز مثل شب اجرا، با این تفاوت که تماشاگر پولی وجود ندارد.
- پروداکشن شب اجراست. اشتباهات جلوی همه رخ می‌دهد.
بیشتر مشکلاتی که ترجیح می‌دهید شب اجرا پیش نیایند، در تمرین generale ظاهر می‌شوند: تغییر لباسی که خیلی طول می‌کشد، یا نشانه نوری که اشتباه است. دقیقاً همین کار استیجینگ است.
سه محیط رایج
| توسعه | استیجینگ | پروداکشن | |
|---|---|---|---|
| هدف | ساختن و آزمایش | بررسی نهایی پیش از انتشار | اپ زنده |
| چه کسی استفاده می‌کند | شما یا توسعه‌دهندگان | تیم شما، آزمایشگرها، مشتریان | کاربران واقعی |
| داده | داده نمونه یا ساختگی | داده آزمایشی یا نسخه پاک‌سازی‌شده | داده واقعی مشتریان |
| کلیدهای API | کلیدهای آزمایشی | کلیدهای آزمایشی (مثلاً حالت تست درگاه پرداخت) | کلیدهای زنده |
| پایداری | اغلب می‌شکند، و این مشکلی نیست | باید پایدار باشد | باید پایدار باشد |
| نشانی وب | محلی یا پیش‌نمایش خصوصی | نشانی خصوصی یا محافظت‌شده با رمز | دامنه عمومی شما |
هر محیط عمدتاً در پیکربندی خود با دیگری تفاوت دارد: به کدام پایگاه داده وصل می‌شود، از کدام کلیدها استفاده می‌کند، و در کدام نشانی اجرا می‌شود. به همین دلیل اپ‌های خوب این تنظیمات را از متغیرهای محیطی و رازها می‌خوانند، نه اینکه آن‌ها را در کد ثابت کنند. همان کد می‌تواند در هر محیطی با تنظیمات متفاوت اجرا شود.
یک مثال کامل: تغییر قوانین لغو رزرو یک اپ سالن زیبایی
شما یک اپ رزرو برای یک سالن زیبایی با مشتریان پرداخت‌کننده دارید. می‌خواهید قانون را تغییر دهید تا مشتریان بتوانند تا ۲۴ ساعت پیش از نوبت لغو کنند، نه ۴۸ ساعت، و بازپرداخت خودکار باشد.
۱. در توسعه بسازید. از سازنده هوش مصنوعی‌تان تغییر را بخواهید. منطق لغو و تماس بازپرداخت با درگاه پرداختتان به‌روز می‌شود.
۲. به استیجینگ ببرید. استیجینگ همان کد را اجرا می‌کند، اما به یک پایگاه داده استیجینگ با رزروهای آزمایشی و کلیدهای حالت تست درگاه پرداختتان وصل است.
۳. جریان‌های واقعی را آزمایش کنید. شما و یک همکار:
- یک نوبت آزمایشی برای فردا رزرو کنید و ۳۰ ساعت پیش لغوش کنید — باید بازپرداخت شود؛
- ۱۰ ساعت پیش لغو را امتحان کنید — باید با یک پیام روشن رد شود؛
- بررسی کنید بازپرداخت در داشبورد آزمایشی درگاه پرداخت ظاهر می‌شود؛
- بررسی کنید ایمیل تأیید می‌گوید ۲۴ ساعت، نه ۴۸ ساعت.
۴. باگ را پیدا کنید. در استیجینگ متوجه می‌شوید قانون از منطقه زمانی سرور استفاده می‌کند، نه منطقه زمانی سالن، پس زمان مهلت یک ساعت اشتباه است. آن را اصلاح می‌کنید و دوباره آزمایش می‌کنید.
۵. به پروداکشن منتشر کنید. فقط حالا تغییر به مشتریان واقعی می‌رسد — با باگ منطقه زمانی که از قبل پیدا شده است.
اگر استیجینگ نبود، مرحله ۴ روی بازپرداخت یک مشتری واقعی رخ می‌داد.
اصطلاحات کلیدی
| اصطلاح | معنی |
|---|---|
| Environment (محیط) | یک نسخه در حال اجرای اپ با تنظیمات، داده و نشانی خودش. |
| Production (پروداکشن) | محیط زنده‌ای که کاربران واقعی به آن تکیه دارند. |
| Staging (استیجینگ) | نسخه‌ای شبیه پروداکشن برای آزمایش نهایی. |
| Development (توسعه) | جایی که تغییرات ابتدا ساخته و امتحان می‌شوند. |
| Preview environment (محیط پیش‌نمایش) | نسخه‌ای کوتاه‌عمر از اپ برای یک تغییر، که اغلب خودکار ساخته می‌شود. |
| Deploy / release (استقرار / انتشار) | قرار دادن یک نسخه از کد در یک محیط. |
| Rollback (بازگشت) | برگشت به نسخه کارای قبلی پس از یک انتشار بد. |
| Environment parity (هم‌ترازی محیط‌ها) | میزان شباهت استیجینگ به پروداکشن. هرچه بیشتر باشد، مفیدتر است. |
| Seed data (داده اولیه) | داده نمونه‌ای که در یک پایگاه داده غیرپروداکشن برای آزمایش بارگذاری می‌شود. |
باورهای غلط رایج
- «استیجینگ می‌تواند پایگاه داده پروداکشن را به اشتراک بگذارد.» این خطرناک‌ترین میان‌بر است. یک آزمایش که رکوردها را پاک یا ویرایش کند، به مشتریان واقعی آسیب می‌زند. به استیجینگ پایگاه داده جداگانه بدهید.
- «اگر در استیجینگ کار کند، در پروداکشن نمی‌شکند.» استیجینگ ریسک را کم می‌کند، اما آن را از بین نمی‌برد. ترافیک واقعی، داده واقعی و سرویس‌های بیرونی همچنان می‌توانند غافلگیرتان کنند. راهی برای بازگشت نگه دارید.
- «استیجینگ باید گران باشد.» می‌تواند کوچک باشد. به همان راه‌اندازی پروداکشن نیاز دارد، نه به همان اندازه.
- «از کلیدهای پرداخت زنده در استیجینگ استفاده کنید تا واقع‌گرایانه باشد.» از حالت تست درگاه استفاده کنید. واقع‌گرایانه بودن یعنی پول واقعی، نه اینکه پول واقعی جابه‌جا شود.
- «استیجینگ فقط برای تیم‌های بزرگ است.» ایده — اول در جایی امن آزمایش کنید — برای یک نفر هم مفید است. میزان تشریفات می‌تواند با میزان ریسک تغییر کند.
- «استیجینگ باید عمومی باشد تا مردم امتحانش کنند.» آن را خصوصی یا محافظت‌شده نگه دارید، و جلوی ایندکس شدن آن توسط موتورهای جستجو را بگیرید تا کسی آن را با اپ واقعی اشتباه نگیرد.
چه چیزی از سازنده هوش مصنوعی بخواهید
- «هر تنظیمی که مخصوص محیط است — پایگاه داده، کلیدهای API، نشانی سایت — را از متغیرهای محیطی بخوان.»
- «یک اسکریپت seed اضافه کن که یک پایگاه داده غیرپروداکشن را با داده آزمایشی واقع‌گرایانه پر کند.»
- «تا وقتی که بگویم راه‌اندازی می‌کنیم، از حالت تست درگاه پرداخت استفاده کن.»
- «پیش از زنده شدن این تغییر، جریان‌هایی که باید آزمایش کنم و نتیجه‌ی هر کدام را فهرست کن.»
- «آیا این تغییر روی داده‌های موجود اثر می‌گذارد؟ ابتدا مهاجرت را به من نشان بده.»
- «مطمئن شو که نسخه‌های غیرپروداکشن سایت توسط موتورهای جستجو ایندکس نمی‌شوند.»
برای راهنمای گام‌به‌گام، نحوه راه‌اندازی محیط استیجینگ را ببینید. وقتی انتشارها زیاد شوند، خودکارسازی مسیر از کد تا استیجینگ و پروداکشن کار CI/CD است.
آزمایش پیش از انتشار در Mythex
Mythex جداکننده‌ای بین «استیجینگ و پروداکشن» ندارد؛ انتشار یک نشانی عمومی زنده به شما می‌دهد، و مستندات این را صریحاً گفته‌اند (اپ‌های چندسرویسی). آنچه می‌دهد، یک مرز روشن بین ساختن و زنده شدن است:
- پیش‌نمایش اپ شما را در یک سندباکس ابری خصوصی اجرا می‌کند وقتی در حال ساختن هستید. تغییرات ابتدا آنجا ظاهر می‌شوند، نه روی اپ زنده شما.
- اشتراک‌گذاری لینک‌های پیش‌نمایش می‌سازد تا یک مشتری یا همکار بتواند کار در حال انجام را بدون حساب Mythex و بدون اینکه شما منتشر کنید بررسی کند. لینک، سندباکس را دقیقاً همان‌طور که هست نشان می‌دهد، از جمله تغییرات نیمه‌کاره، و هر زمان می‌توانید آن را حذف کنید.
- انتشار پروژه را عکس‌برداری و مستقر می‌کند. تا وقتی دوباره منتشر نکنید، اپ زنده همان‌طور که بود می‌ماند.
- نقطه‌های بازیابی بعد از هر نوبت موفق ایجنت ذخیره می‌شوند، تا اگر تغییری بد پیش رفت، فایل‌های پروژه را برگردانید.
پیش‌نمایش را مثل تمرین خود در نظر بگیرید: پرداخت را تا زمان راه‌اندازی در حالت تست نگه دارید و قبل از هر انتشار جریان‌های کلیدی‌تان را اجرا کنید. وقتی مشتریان واقعی در میان باشند، از ایجنت بپرسید پیش‌نمایش شما از کدام پایگاه داده و کلیدها استفاده می‌کند، پیش از آزمایش هر کاری که داده را می‌نویسد یا پاک می‌کند. اگر به یک راه‌اندازی استیجینگ کاملاً جدا با پایگاه داده خودش نیاز دارید، از ایجنت بخواهید گزینه‌های پروژه‌تان را توضیح دهد، یا — در پلن Pro — پروژه را خروجی بگیرید یا با GitHub همگام کنید و روی زیرساختی که خودتان کنترل می‌کنید اجرایش کنید.
پرسش‌ها
محیط استیجینگ به زبان ساده چیست؟
محیط استیجینگ نسخه خصوصی اپ شماست، تا حد امکان نزدیک به نسخه زنده، که در آن تغییرات را پیش از دیدن کاربران واقعی آزمایش می‌کنید. اگر آنجا چیزی خراب شود، کسی بیرون از تیم شما تحت تأثیر قرار نمی‌گیرد.
تفاوت استیجینگ و پروداکشن چیست؟
پروداکشن اپ زنده‌ای است که کاربران و داده‌های واقعی به آن وابسته‌اند. استیجینگ یک نسخه تمرینی است که همان ساختار پروداکشن را دارد، اما داده‌های آزمایشی و کلیدهای آزمایشی جدا دارد تا بتوانید تغییرات را بی‌خطر امتحان کنید.
آیا استیجینگ از همان پایگاه داده پروداکشن استفاده می‌کند؟
نباید. استیجینگ باید پایگاه داده خودش را داشته باشد، پر از داده‌های آزمایشی یا یک نسخه پاک‌سازی‌شده از داده‌های پروداکشن. اشتراک پایگاه داده یعنی یک آزمایش ممکن است رکوردهای واقعی مشتریان را تغییر دهد یا پاک کند.
آیا اپ‌های کوچک به محیط استیجینگ نیاز دارند؟
همیشه به یک محیط کامل نیاز ندارند. یک پروژه انفرادی اغلب با یک پیش‌نمایش خصوصی، یک چک‌لیست و امکان بازگشت به نسخه قبلی کافی است. وقتی مشتریان واقعی، پرداخت یا یک تیم در میان باشد، جایی جدا برای آزمایش تغییرات ارزش بسیار بیشتری پیدا می‌کند.