دردسترس‌بودن App#

انتشار یک بازبینی App آن را به بازبینی منتشرشدهٔ فعال آن App تبدیل می‌کند؛ اما آن را قابل اجرا نمی‌کند. دردسترس‌بودن در Runtime یک تصمیم جداگانهٔ پلتفرم است: مدیر پلتفرم یک بازبینی دقیق منتشرشده را فعال یا غیرفعال می‌کند. انتشار App به‌تنهایی هرگز دردسترس‌بودن سراسری ایجاد نمی‌کند.

رکورد دردسترس‌بودن#

Registry برای هر بازبینی دقیق App یک رکورد دردسترس‌بودن نگه می‌دارد که از راه GET /v1/admin/apps/availability خوانده می‌شود:

فیلد	معنی
appId	شناسهٔ پایدار App
revisionId	بازبینی تغییرناپذیر دقیقی که این رکورد کنترل می‌کند
revision	شمارهٔ بازبینی
publisherHandle	handle ناشری که مالک App است
slug	slug اپ زیر آن Publisher
enabled	آیا این بازبینی دقیق فعلاً برای launch در Runtime فعال است
blocked	آیا بازبینی زیر مسدودسازی اضطراری فعال است
publishedAt	زمان انتشار بازبینی
updatedAt	زمان آخرین تغییر تصمیم دردسترس‌بودن، یا null

دردسترس‌بودن برای هر بازبینی دقیق مستقل است: فعال‌کردن بازبینی جدید و غیرفعال‌کردن بازبینی قدیمی دو تصمیم مستقل ممیزی‌شده‌اند، نه جابه‌جایی خودکار اشاره‌گر.

مرز اختیار#

هم خواندن و هم mutation عملیات مدیریت پلتفرم‌اند:

1. فراخوان باید مدیر پلتفرم باشد؛ توکن Project و عضویت Project با admin_required رد می‌شوند.
2. هر mutation دلیلی بین ۳ تا ۱۰۰۰ نویسه دارد.
3. به‌روزرسانی دردسترس‌بودن و رویداد ممیزی app.platform_availability.set در یک تراکنش commit می‌شوند و مدیر، App، بازبینی، وضعیت enabled، scope و دلیل را ثبت می‌کنند.

مسیر mutation، PUT /v1/admin/apps/availability با appId، revisionId، enabled و reason است. بدنهٔ بدشکل invalid_app_availability و بازبینی ناشناخته app_revision_not_found برمی‌گرداند.

فعال‌کردن یک بازبینی دقیق#

1. تأیید کنید بازبینی published است و ردیف فعلی دردسترس‌بودن آن را بخوانید.
2. قصد اپراتور را تأیید کنید: appId و revisionId دقیق و چکیدهٔ تغییرناپذیر build.
3. mutation فعال‌سازی را همراه دلیل بفرستید.
4. تأیید کنید رکورد به‌روزشده برای همان بازبینی دقیق enabled: true را نشان می‌دهد.

پیش از فعال‌سازی، Registry اتصال build را برای همان بازبینی دقیق دوباره بررسی می‌کند: بازبینی دقیقاً یک فهرست را نام می‌برد و آن فهرست هنوز به چکیده‌ای می‌رسد که با آن متصل شده است. اگر نرسد، mutation با app_build_artifact_invalid یا app_build_artifact_required fail-closed می‌شود، به‌جای اینکه بایت‌هایی را فعال کند که کسی بازبینی‌شان نکرده است. بازبینی‌های تاریخی قدیمی‌تر از شواهد build خواندنی می‌مانند، اما تازه submit، published یا enabled نمی‌شوند و مقصد rollback هم نیستند.

غیرفعال‌کردن یک بازبینی دقیق#

غیرفعال‌کردن از همان مسیر با enabled: false و دلیل مستقل انجام می‌شود. وضعیت انتشار بازبینی دست‌نخورده می‌ماند: غیرفعال‌کردن واجدشرایطی launch در Runtime را حذف می‌کند، اما انتشار را yank یا suspend نمی‌کند. بازبینی غیرفعال تا وقتی منتشرشده و block‌نشده است، با همان mutation ممیزی‌شده دوباره فعال می‌شود.

تعامل با block و بازگردانی#

• بازبینی زیر مسدودسازی اضطراری فعال blocked: true را گزارش می‌کند؛ مسیر launch به‌طور مستقل بازبینی‌های block‌شده را رد می‌کند، پس دردسترس‌بودن هرگز تنها لایهٔ اجرا نیست.
• بازگردانی اشاره‌گر منتشرشدهٔ فعال و enable دردسترس‌بودن هر دو پیش از تغییر وضعیت، آمادگی زندهٔ build را تکرار می‌کنند؛ هیچ‌کدام به شواهد کهنه اعتماد نمی‌کنند. بازیابی و بازگردانی را ببینید.
• دردسترس‌بودن هرگز انتشار کاتالوگ را تغییر نمی‌دهد: بازبینی منتشرشده در حالت غیرفعال هم در کاتالوگ دیده می‌شود.

تأیید اپراتور#

فعال‌سازی فقط وقتی کامل است که launch واقعی consumer اثبات کند همان بازبینی دقیق در یک Runtime مستقل اجرا می‌شود. Journey ساخت App این تکمیل را اثبات می‌کند؛ نبود مدرک launch مصرف‌کننده، Journey را با ALAMR_APP_LAUNCH_MISSING شکست می‌دهد. پاسخ موفق mutation را مدرک launch تلقی نکنید.

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