چطور یک محیط استیجینگ برای اپ خود راه‌اندازی کنیم

برای راه‌اندازی محیط استیجینگ، یک نسخه دوم از اپ را روی نشانی خصوصی خودش دیپلوی کنید، پایگاه داده و کلیدهای API تست جداگانه به آن بدهید، و تا جای ممکن تنظیمات آن را با محیط اصلی یکی کنید. سپس هر تغییر مهم را ابتدا روی استیجینگ منتشر کنید، جریان‌های اصلی را امتحان کنید و فقط وقتی همه‌چیز درست به نظر رسید، روی محیط اصلی منتشر کنید.

اگر این ایده برایتان تازه است، محیط استیجینگ چیست مفهوم را توضیح می‌دهد. این راهنما راه‌اندازی عملی است، برای کسانی که با ابزارهای هوش مصنوعی می‌سازند و یک تیم DevOps ندارند.

توسعه، استیجینگ و محیط اصلی

بیشتر اپ‌های کوچک به سه جا نیاز دارند، حتی اگر اولی فقط پیش‌نمایش سازنده‌تان باشد:

هدف استیجینگ این است که مثل محیط اصلی رفتار کند؛ همان کد، همان پشته، و همان نوع تنظیمات، اما اشتباه در آن به کسی آسیب نمی‌زند.

گام ۱: تعیین کنید استیجینگ باید چه چیزی را تطابق دهد

استیجینگ فقط وقتی مفید است که مشکلات پیش از محیط اصلی در آن ظاهر شوند. این موارد را یکی کنید:

• همان کد، که به همان شکل منتشر می‌شود.
• همان پشته و نسخه‌ها: فریم‌ورک، runtime، نوع پایگاه داده.
• همان نوع پیکربندی: همان نام متغیرهای محیطی، با مقادیر تست.
• همان سرویس‌ها: اگر محیط اصلی یک وب‌اپ و یک API دارد، استیجینگ هم هر دو را داشته باشد.

اندازه (یک ماشین کوچک‌تر اشکالی ندارد) و داده می‌توانند متفاوت باشند.

گام ۲: ساخت کپی

ساده‌ترین روش: یک دیپلوی دوم از همان پروژه، روی نشانی متفاوت مثل staging.yourapp.com یا yourapp-staging.example.com.

نحوه انجامش به میزبان شما بستگی دارد:

• میزبان‌هایی با دیپلوی پیش‌نمایش یا استیجینگ داخلی می‌توانند برای یک شاخه Git خودکار یکی بسازند.
• میزبان‌هایی بدون این امکان: یک اپ یا پروژه دوم از همان کد بسازید و جداگانه دیپلوی کنید.
• کد در Git: یک شاخه staging یا main نگه دارید که به استیجینگ دیپلوی می‌شود، و محیط اصلی را از یک نسخه منتشر کنید. چطور از Git با اپی که با هوش مصنوعی ساخته شده استفاده کنیم را ببینید.

گام ۳: به استیجینگ پایگاه داده جدا بدهید

این گام شما را محافظت می‌کند. اگر استیجینگ و محیط اصلی پایگاه داده مشترک داشته باشند، یک تست که رکوردی را حذف می‌کند، رکوردهای واقعی را حذف می‌کند.

• یک پایگاه داده جدا برای استیجینگ بسازید.
• آن را با داده seed پر کنید؛ یعنی رکوردهای ساختگی واقع‌گرایانه که هوش مصنوعی می‌تواند برایتان تولید کند.
• اگر به کپی داده محیط اصلی نیاز دارید، ابتدا نام‌ها، ایمیل‌ها و هر چیز شخصی را حذف یا تغییر دهید.

یک اسکریپت seed بنویس که یک پایگاه داده خالی را با داده تست واقع‌گرایانه پر کند: ۲۰ مشتری، ۵۰ سفارش در وضعیت‌های مختلف، و دو کاربر ادمین. از نام‌های واضحاً ساختگی و نشانی‌های ایمیل example.com استفاده کن.

پیش از اعتماد به تنظیمات، تأیید کنید هر نسخه به کدام پایگاه داده وصل است. مستقیم بپرسید:

این اپ به کدام پایگاه داده وصل است و آن تنظیم از کجا می‌آید؟ نام متغیر را نشان بده، نه رمز عبور را.

گام ۴: از کلیدهای تست و تنظیمات جدا استفاده کنید

هرچیزی که با یک سرویس بیرونی حرف می‌زند باید در استیجینگ از اعتبارنامه‌های تست استفاده کند:

• پرداخت در حالت تست (مثلاً کلیدهای تست Stripe)، تا هیچ کارت واقعی شارژ نشود.
• ایمیل به یک sandbox یا فقط به نشانی خودتان، تا مشتریان هرگز پیام تست دریافت نکنند.
• هوش مصنوعی و APIهای پولی دیگر با کلید جدا و سقف هزینه پایین.
• وب‌هوک‌ها به نشانی استیجینگ، نه محیط اصلی.

نام متغیرها را در هر دو محیط یکسان نگه دارید و فقط مقادیر را عوض کنید. به این ترتیب کد لازم نیست بداند کجا اجرا می‌شود. برای اطلاعات بیشتر، چطور کلیدهای API را امن نگه داریم را ببینید.

گام ۵: استیجینگ را خصوصی نگه دارید

استیجینگ نباید عمومی باشد:

• آن را پشت ورود، رمز عبور، یا فهرست مجاز ایمیل‌های تیم قرار دهید.
• با تگ meta از نوع noindex یا هدر X-Robots-Tag جلوی ایندکس شدنش توسط موتورهای جستجو را بگیرید.
• از سایت عمومی‌تان به آن لینک ندهید.
• ظاهرش را متفاوت کنید؛ یک بنر رنگی با عبارت «STAGING» جلوی تست در تب اشتباه را می‌گیرد.

وقتی متغیر محیطی APP_ENV برابر «staging» است، در بالای هر صفحه یک بنر زرد پررنگ با متن «STAGING — فقط داده تست» اضافه کن. در آن حالت یک تگ meta از نوع noindex هم اضافه کن.

گام ۶: یک روال انتشار بسازید

استیجینگ فقط وقتی کمک می‌کند که هربار از آن استفاده کنید. یک روال ساده:

1. تغییر را در محیط توسعه بسازید و در پیش‌نمایش بررسی کنید.
2. آن را روی استیجینگ منتشر کنید.
3. جریان‌های اصلی را امتحان کنید: ثبت‌نام، ورود، ویژگی اصلی، پرداخت، و هر بخشی که تغییر به آن دست زده.
4. اگر چیزی خراب شد، اصلاح کنید و دوباره روی استیجینگ منتشر کنید.
5. همان نسخه را روی محیط اصلی منتشر کنید.
6. محیط اصلی را سریع بررسی کنید: همان جریان‌ها، به‌طور مختصر.

جریان‌های اصلی را به‌صورت یک اسکریپت کوتاه تست بنویسید. برای اینکه چه چیزهایی را شامل شود، چطور اپ را پیش از عرضه تست کنیم را ببینید.

گام ۷: تغییرات پایگاه داده را با احتیاط انجام دهید

تغییر ساختار پایگاه داده، مثل افزودن ستون یا تغییر نام جدول، جایی است که استیجینگ ارزشش را ثابت می‌کند.

• هر تغییر ساختاری را ابتدا روی استیجینگ اجرا کنید.
• بررسی کنید داده‌های موجود سالم مانده‌اند، نه فقط اینکه ویژگی‌های جدید کار می‌کنند.
• پیش از اجرای همان تغییر روی محیط اصلی، از پایگاه داده آن بک‌آپ بگیرید. چطور از پایگاه داده اپ بک‌آپ بگیریم را ببینید.
• تغییراتی را ترجیح دهید که چیزی اضافه می‌کنند، نه تغییر نام یا حذف؛ تا اگر برگشتید، نسخه قدیمی هنوز کار کند.

نمونه پرامپت‌ها

توضیح بده اگر این تغییر پایگاه داده را روی محیط اصلی اجرا کنیم، برای داده‌های موجود چه اتفاقی می‌افتد. آیا چیزی حذف یا تغییر نام می‌شود؟

همه تنظیمات مخصوص محیط — نشانی‌های API، کلیدها، فرستنده ایمیل، و نشانی خود سایت — را از متغیرهای محیطی با نام‌های یکسان در استیجینگ و محیط اصلی بگیر. آن‌ها را فهرست کن.

بر اساس کاری که این اپ انجام می‌دهد، یک چک‌لیست کوتاه از جریان‌هایی بنویس که باید پیش از هر انتشار روی استیجینگ تست کنم.

اشتباهات رایج

• پایگاه داده مشترک. پرخطرترین اشتباه. استیجینگ همیشه باید پایگاه داده خودش را داشته باشد.
• کلیدهای زنده در استیجینگ. شارژ واقعی، ایمیل واقعی به مشتریان واقعی.
• فاصله گرفتن استیجینگ از محیط اصلی. نسخه یا تنظیمات متفاوت باعث می‌شود استیجینگ دیگر مشکلات را پیدا نکند.
• سایت استیجینگ عمومی و ایندکس‌شده که کنار سایت واقعی شما در نتایج جستجو ظاهر می‌شود.
• رد کردن استیجینگ برای تغییرات «کوچک». تغییرات کوچک هم چیزها را خراب می‌کنند.
• تست در تب اشتباه. یک بنر قابل‌مشاهده این را حل می‌کند.

چک‌لیست

• استیجینگ همان کد، پشته و سرویس‌های محیط اصلی را اجرا می‌کند.
• استیجینگ پایگاه داده جدای خودش را با داده تست یا پاک‌شده دارد.
• پرداخت، ایمیل و APIهای پولی در استیجینگ از کلیدهای تست استفاده می‌کنند.
• نام متغیرها بین محیط‌ها یکسان است؛ فقط مقادیرشان فرق دارد.
• استیجینگ پشت ورود یا رمز عبور است و ایندکس نمی‌شود.
• وقتی روی استیجینگ هستید بنری نمایش داده می‌شود.
• هر انتشار ابتدا به استیجینگ می‌رود، با فهرست نوشته‌شده‌ای از جریان‌های بررسی.
• تغییرات پایگاه داده ابتدا روی استیجینگ اجرا می‌شوند، با بک‌آپ از محیط اصلی پیش از انتشار.

استیجینگ در Mythex

قابلیت Publish در Mythex برای هر اپ یک نشانی زنده می‌دهد؛ کلید جداگانه‌ای برای استیجینگ وجود ندارد. در عمل دو گزینه دارید:

• پیش‌نمایش به‌عنوان بررسی پیش از انتشار. هر پروژه در یک فضای ابری خصوصی با یک Preview زنده اجرا می‌شود. /test باعث می‌شود عامل مثل یک کاربر در آن کلیک کند، و لینک Share به مشتری یا همکار اجازه می‌دهد پیش‌نمایش را بدون انتشار بررسی کند. پیش‌نمایش و کد را ببینید. برای بسیاری از پروژه‌های فردی همین کافی است.
• یک پروژه دوم به‌عنوان استیجینگ. در طرح Pro، پروژه را خروجی بگیرید و در یک پروژه جدید وارد کنید، به آن پایگاه داده و رازهای تست جدا بدهید، و با نشانی (slug) خودش منتشرش کنید. پیش از منتشر کردن پروژه اصلی، روی آن منتشر کنید.

در هر حال، پیش از هر تست مخرب از عامل بپرسید پیش‌نمایش و اپ منتشرشده از کدام پایگاه داده استفاده می‌کنند، و برای برگرداندن تغییر بد از checkpointها استفاده کنید. برای عمومی‌تر کردن اپ، چطور یک نمونه اولیه ساخته‌شده با هوش مصنوعی را به محیط اصلی ببریم را ببینید.

پرسش‌ها