دیجی‌پی
انتشار اولین اپ؛ چک‌لیست دامنه، دیتابیس و نسخهٔ قابل بازگشت
قبل از انتشار اپ ساخته‌شده با AI چه چیزهایی را بررسی کنیم؟ یک چک‌لیست اجرایی برای تنظیمات سرور، داده، HTTPS، کش، تست زنده و برگشت نسخه.
محمد فغانیمنتشرشده
انتشار یعنی یک نسخهٔ مشخص، نه صرفاً یک لینک
وقتی اپ روی کامپیوتر تو کار می‌کند، هنوز معلوم نیست روی محیط واقعی هم همان رفتار را داشته باشد. نسخهٔ Node، متغیرهای محیطی، آدرس سرویسها و محل ذخیرهٔ فایل ممکن است متفاوت باشند. قبل از انتشار، نسخه‌ای را مشخص کن که می‌خواهی تحویل بدهی: تغییرات آن چیست، کدام بررسی‌ها را گذرانده و اگر خراب شد به چه نسخه‌ای برمی‌گردی. همین اطلاعات کوتاه، فرق یک انتشار قابل پیگیری با مجموعه‌ای از تغییرات فراموش‌شده است. برای نسخهٔ اول هم این نظم ارزش دارد؛ تعداد کم کاربران دلیل خوبی برای گم‌کردن نسخهٔ اجراشده نیست.
در مثال اپ کافه، معیار انتشار این نیست که منو آنلاین دیده شود. باید یک سفارش جدید روی همان محیط ذخیره شود، در پنل کافه ظاهر شود و پس از بازشدن دوبارهٔ صفحه باقی بماند. این سه کار، وابستگی واقعی به سرور و دیتابیس را آزمایش می‌کند. سناریو را پیش از انتشار بنویس و بعد از انتشار دقیقاً همان را اجرا کن. نام نسخه و زمان بررسی را کنار نتیجه نگه دار تا بتوانی مشکل بعدی را به یک تغییر مشخص وصل کنی.
محیط اجرا و دستور build را تثبیت کن
از ایجنت بخواه نسخهٔ موردنیاز محیط اجرا، دستور نصب وابستگی‌ها، دستور ساخت و دستور اجرای محصول را مستند کند. اجرای موفق ابزار توسعه کافی نیست؛ خروجی production را هم اجرا کن. بعضی خطاها فقط در مرحلهٔ ساخت یا هنگام خواندن تنظیمات واقعی دیده می‌شوند. فایل قفل وابستگی‌ها را نگه دار تا نصب بعدی بی‌دلیل مجموعهٔ متفاوتی از بسته‌ها نگیرد. قبل از انتخاب میزبان، مطمئن شو محیط انتخابی همان نوع برنامه را اجرا می‌کند؛ فضای مخصوص فایل استاتیک جای سرور موردنیاز یک اپ پویا را نمی‌گیرد.
اگر از یک پلتفرم مدیریتشده استفاده می‌کنی، تنظیمات همان پلتفرم را بخوان و یک انتشار آزمایشی انجام بده. برای نمونه، مستندات رسمی لیارا مسیر اجرای NodeJS و مدیریت متغیرهای محیطی را توضیح میدهد؛ لینک آن در منابع این راهنما آمده است. این اشاره به معنی مناسب‌بودن یک سرویس برای تمام پروژه‌ها نیست. معیار تو باید نیاز اپ، دسترسی شبکه به سرویسهای لازم و امکان نگهداری آن باشد. هزینه و محدودیت حساب را نیز از پنل همان سرویس بررسی کن؛ این راهنما قیمت یا ظرفیت ثابتی وعده نمی‌دهد.
تنظیمات و داده را از کد جدا نگه دار
آدرس دیتابیس، کلید سرویس و رمزهای لازم را در تنظیمات محیط سرور قرار بده. چیزی که به کد مرورگر وارد می‌شود، قابل مشاهده است؛ حتی اگر نام متغیرش شامل secret باشد. مقدارهای محیط آزمایش را جدا از محیط واقعی نگه دار و از ایجنت بخواه فقط نام متغیرهای لازم را در فایل نمونه بنویسد، نه مقدار واقعی آن‌ها را. برای تست اتصال، یک عملیات محدود انجام بده و نتیجه را بررسی کن. چاپ‌کردن تمام تنظیمات در لاگ برای عیب‌یابی، راه مناسبی برای این کار نیست.
محل نگهداری فایل و دیتابیس باید پس از تعویض نسخه باقی بماند. پوشهٔ داخل یک اجرای موقت یا کانتینر، لزوماً محل ماندگار نیست. یک فایل آزمایشی بارگذاری کن، برنامه را با روش معمول خودت دوباره اجرا کن و بررسی کن فایل و رکورد هنوز قابل استفاده باشند. سپس روش بکاپ و بازیابی را مشخص کن. وجود فایل بکاپ کافی نیست؛ یک بار بازیابی را در محیط جدا امتحان کن و ثبت کن چه داده‌ای و تا چه زمانی قابل برگرداندن است. این تصمیم را قبل از جمع‌شدن سفارش واقعی بگیر.
دامنه و HTTPS را از بیرون محیط خودت بررسی کن
دامنه باید به سرویس درست برسد و آدرس اصلی سایت مشخص باشد. اگر هم آدرس دارای www و هم آدرس بدون آن پاسخ می‌دهند، یکی را آدرس اصلی انتخاب و دیگری را به آن هدایت کن. ریدایرکت نباید حلقه بسازد یا کاربر را بین HTTP و HTTPS بچرخاند. برای بررسی، سایت را با دستگاه یا شبکه‌ای دیگر باز کن؛ نتیجهٔ دیده‌شده فقط در مرورگر خودت ممکن است از کش یا تنظیمات محلی تأثیر گرفته باشد. صفحهٔ ورود، یک صفحهٔ عمومی و یک آدرس ناموجود را جدا آزمایش کن.
اگر CDN بین کاربر و سرور است، تحویل موفق گواهی به مرورگر فقط یک بخش مسیر است. اتصال CDN به سرور اصلی هم باید طبق تنظیمات معتبر همان سرویس برقرار باشد. برای رفع خطا، حفاظت ارتباط را خاموش نکن؛ آدرس مبدأ، نام دامنه و گواهی آن بخش را بررسی کن. آدرس بازگشت درگاه، ورود و سرویسهای دیگر نیز باید با محیط واقعی هماهنگ باشند. یک آدرس localhost که در تنظیمات جا مانده، میتواند جریانی را خراب کند که صفحهٔ اول آن کاملاً سالم به نظر می‌رسد.
کش عمومی و پاسخ شخصی را از هم جدا کن
فایل‌های نسخه‌دار مثل bundle جاوااسکریپت معمولاً می‌توانند طولانی‌تر کش شوند. اما صفحهٔ حساب، نتیجهٔ پرداخت و پاسخ حاوی اطلاعات شخصی نباید در کش مشترک کاربران قرار بگیرند. اگر هدر سایت برای کاربر واردشده نام او را نشان میدهد، حتی HTML صفحهٔ اصلی هم ممکن است شخصی باشد. قبل از فعال‌کردن کش HTML، درخواست بدون ورود و درخواست دارای نشست را جدا بررسی کن. CDN باید سیاست پاسخ مبدأ و روش جداسازی درخواست‌ها را رعایت کند؛ روشن‌کردن یک گزینهٔ عمومی Cache Everything، به‌تنهایی طراحی درستی نیست.
برای صفحات عمومی که باید در جست‌وجو دیده شوند، متن اصلی در خروجی قابل خواندن باشد، عنوان و canonical به همان آدرس اصلی اشاره کنند و noindex ناخواسته وجود نداشته باشد. صفحهٔ ورود و مسیرهای شخصی را وارد سایت‌مپ نکن. سایت‌مپ، درخواست برای ایندکس است و تضمین آن نیست. اگر صفحه‌ای در گوگل دیده نمی‌شود، وضعیتش را در URL Inspection بخوان و تست زنده را از وضعیت ثبت‌شده در ایندکس جدا تفسیر کن. جزئیات این تفکیک را در راهنمای رسمی گوگل که پایین صفحه آمده بررسی کن.
تست زنده، مشاهدهٔ خطا و برگشت را آماده کن
پس از انتشار، فقط کد ۲۰۰ صفحهٔ اول را نبین. مسیر اصلی کاربر را با دادهٔ آزمایشی مشخص اجرا کن: منو را بخوان، سفارش بساز، نتیجه را ببین و آن را در پنل پیدا کن. یک درخواست بدون مجوز نیز بفرست تا مطمئن شوی اطلاعات خصوصی پنهان مانده‌اند. اگر پرداخت اضافه شده، سناریوهای نتیجهٔ نامعلوم و بازگشت تکراری را هم در برنامهٔ بررسی داشته باش. تستی که روی نسخهٔ محلی گذشته، به‌تنهایی صحت دامنه و تنظیمات نسخهٔ زنده را ثابت نمیکند.
برای چند خطای اصلی، نشانهٔ قابل مشاهده تعریف کن: قطع اتصال دیتابیس، افزایش خطاهای سرور و شکست ثبت سفارش. لاگ باید شناسهٔ درخواست یا سفارش را داشته باشد تا مشکل قابل پیگیری شود، اما کلید سرویس و اطلاعات محرمانه را ننویسد. روش بازگشت نسخه را پیش از نیاز تمرین کن. برگشت کد همیشه دادهٔ تغییرکرده را برنمی‌گرداند؛ اگر ساختار دیتابیس عوض می‌شود، سازگاری نسخهٔ قبل و بعد را هم در نظر بگیر. انتشار زمانی آماده است که هم مسیر موفق را بشناسی و هم بدانی در خطا چه چیزی را بررسی و چطور سرویس را بازیابی کنی.
فایل‌های همراه این راهنما
برای بررسی بیشتر
پرسش‌های پرتکرار
- برای انتشار اولین اپ حتماً VPS لازم دارم؟
- نه. انتخاب محیط به نوع برنامه و نیازهای آن بستگی دارد. یک سرویس مدیریتشده هم میتواند مناسب باشد؛ مهم این است که محیط اجرا، دیتابیس، ذخیرهٔ ماندگار، تنظیمات و دسترسی شبکهٔ موردنیاز را تأمین کند و روش انتشار و بازیابی آن را بفهمی.
- چرا اپ محلی درست است ولی روی دامنه خطا میدهد؟
- نسخهٔ محیط اجرا، تنظیمات، آدرس سرویسها، دسترسی شبکه، مجوز فایل یا مرحلهٔ build ممکن است متفاوت باشد. لاگ همان اجرای زنده را بخوان و خطا را با یک درخواست مشخص بازتولید کن؛ صرف تغییر ظاهر صفحه یا ساخت دوبارهٔ کد علت را روشن نمیکند.
- بعد از انتشار چه چیزی را اول بررسی کنم؟
- یک مسیر واقعی از ابتدا تا انتها را اجرا کن، ماندگاری داده را ببین و دسترسی بدون مجوز را آزمایش کن. سپس خطاهای سرور و سرویسهای وابسته را بررسی کن. سلامت صفحهٔ اول و روشنبودن سرویس، موفقیت ثبت سفارش یا پرداخت را تضمین نمیکند.