Firebase Studio تعطیل می‌شود؛ راهنمای مهاجرت امن به Google AI Studio

Firebase Studio هنوز برای کاربران دارای Workspace موجود قابل استفاده است، اما دیگر مقصد بلندمدت پروژه نیست. Google اعلام کرده ساخت Workspace جدید و ثبت‌نام کاربر جدید از ۲۲ ژوئن ۲۰۲۶ متوقف شده و سرویس در ۲۲ مارس ۲۰۲۷ به‌طور کامل خاموش می‌شود. پس از تاریخ نهایی، داده‌های باقی‌مانده به‌صورت دائمی حذف می‌شوند و قابل بازیابی نیستند.

اگر پروژه‌ای در Firebase Studio دارید، تصمیم درست حذف عجولانه یا انتقال کور نیست. ابتدا باید نوع پروژه، روش انتشار، URL عمومی، Secretها و وابستگی‌های Firebase را فهرست کنید؛ سپس یکی از دو مسیر رسمی Google AI Studio یا Google Antigravity را انتخاب و خروجی را مستقل آزمایش کنید. این راهنما همان مسیر را قدم‌به‌قدم توضیح می‌دهد.

Firebase Studio دقیقاً چه زمانی تعطیل می‌شود؟

اعلام پایان سرویس در ۱۹ مارس ۲۰۲۶ منتشر شد. از ۲۲ ژوئن ۲۰۲۶ ایجاد Workspace و ثبت‌نام جدید متوقف شده است. کاربران فعلی تا ۲۲ مارس ۲۰۲۷ می‌توانند Workspaceهای موجود را باز کنند، توسعه دهند و مهاجرت را انجام دهند. در روز پایان، داده‌های باقی‌مانده حذف می‌شوند؛ بنابراین دانلود ZIP در آخرین روز، برنامه مهاجرت محسوب نمی‌شود.

Sunset شدن Firebase Studio به‌معنای تعطیلی Firebase، Firestore، Authentication یا App Hosting نیست. ابزار محیط توسعه کنار گذاشته می‌شود و سرویس‌های Backend می‌توانند بعد از انتقال نیز ادامه پیدا کنند. همین تفکیک مانع تصمیم اشتباه برای بازنویسی کامل برنامه می‌شود.

Google AI Studio یا Antigravity؛ کدام مسیر مناسب است؟

Google دو مقصد رسمی پیشنهاد می‌کند. Google AI Studio برای نمونه‌سازی سریع و توسعه مبتنی بر Prompt در مرورگر مناسب است. Antigravity برای Workflow کدمحور، محیط محلی، کنترل عمیق‌تر مخزن و کار عامل‌ها انتخاب منطقی‌تری است. انتخاب باید از شیوه کار تیم بیاید، نه از شباهت ظاهری رابط.

برای آشنایی با مسیر مقصد، راهنمای Google AI Studio و حفاظت از API Key را بخوانید. اگر محیط محلی و Agent برایتان اولویت دارد، آموزش نصب و اجرای امن Google Antigravity در ویندوز مکمل این تصمیم است.

چه زمانی Google AI Studio انتخاب بهتری است؟

اگر اپ با Prototyper ساخته شده، بیشتر تغییرها را با توضیح طبیعی انجام می‌دهید و می‌خواهید سریع به Preview و انتشار برسید، AI Studio اصطکاک کمتری دارد. Build mode اپ وب تمام‌پشته با Frontend و Runtime سمت سرور ایجاد می‌کند، امکان Import از GitHub دارد و Secret مربوط به Gemini را در محیط سمت سرور نگه می‌دارد.

چه زمانی Antigravity انتخاب بهتری است؟

اگر پروژه از مخزن موجود وارد شده، Build سفارشی دارد، به Terminal و Extensionها وابسته است یا تیم شما Code Review و Branching جدی دارد، انتقال به محیط کدمحور مناسب‌تر است. قبل از مهاجرت، نسخه‌های Runtime، فرمان‌های Build، Service Accountها و دسترسی هر ابزار را مستند کنید. برای اتصال ابزارهای عامل به سرویس‌ها نیز اصول اتصال امن ابزارهای هوش مصنوعی با MCP Server مفید است.

پیش از زدن Move now چه چیزهایی را ثبت کنیم؟

مهاجرت قابل اعتماد با Inventory شروع می‌شود. صرف دیدن صفحه Preview ثابت نمی‌کند که Database، Login، Jobهای زمان‌بندی‌شده یا متغیرهای محیطی بعد از انتقال کار می‌کنند. برای هر Workspace یک برگه کنترل بسازید و موارد زیر را ثبت کنید.

• نام Workspace، مالک، اعضای تیم و سطح دسترسی هر فرد
• آدرس مخزن، Branch انتشار و آخرین Commit تأییدشده
• شناسه Firebase Project، Region و Backend مربوط به App Hosting
• دامنه سفارشی، URL با پسوند hosted.app و DNS مرتبط
• Firebase Authentication، Providerهای ورود و Authorized Domainها
• Collectionهای Firestore، Ruleها، Indexها و داده آزمایشی لازم
• نام متغیرهای محیطی و Secretها بدون کپی مقدار آن‌ها در سند عمومی
• فرمان Build، نسخه Node.js، Package Manager و Health Check

از پروژه یک خروجی مستقل بگیرید. راهنمای رسمی امکان Zip and Download یا انتقال به GitHub را ذکر می‌کند. نسخه پشتیبان را با تاریخ، Commit و مسئول بازیابی مشخص کنید و یک‌بار در محیط جداگانه باز شدن آن را آزمایش کنید.

مهاجرت مستقیم به Google AI Studio

در Workspace موجود، گزینه Move now را انتخاب کنید و ابتدا Prepare for AI Studio را اجرا کنید. پس از آماده‌سازی، Move to Google AI Studio را بزنید. تبدیل و بارگذاری پروژه ممکن است چند دقیقه زمان ببرد. بعد از باز شدن پروژه در مقصد، فقط به Preview اکتفا نکنید.

1. فهرست فایل‌ها و ساختار پوشه‌ها را با مبدأ مقایسه کنید.
2. Dependencyها را نصب و خروجی Build را بدون Warning بحرانی بررسی کنید.
3. یک مسیر اصلی کاربر را از ابتدا تا انتها اجرا کنید.
4. درخواست‌های Gemini را از DevTools بررسی کنید و مطمئن شوید کلید در Browser Bundle نیست.
5. ورود، خروج، Refresh Session و نقش‌های مختلف را آزمایش کنید.
6. خواندن و نوشتن Firestore را با Ruleهای واقعی و Emulator کنترل کنید.
7. خطاهای Runtime و Logهای استقرار را پیش از سوییچ ترافیک بازبینی کنید.

Google AI Studio می‌تواند پروژه را با GitHub همگام کند و از Build mode روی Cloud Run منتشر کند. اگر URL جدید برایتان قابل قبول است، این مسیر ساده‌تر است. اگر باید دامنه یا URL فعلی App Hosting حفظ شود، بخش بعدی را دقیق اجرا کنید.

حفظ URL فعلی Firebase App Hosting

برای نگه داشتن آدرس *.hosted.app یا دامنه سفارشی، کد را از AI Studio به GitHub Sync متصل و همان Repository را به Backend موجود App Hosting وصل کنید. ترتیب کار مهم است، زیرا Push به Branch زنده می‌تواند Rollout ایجاد کند.

1. در Firebase Console، Backend فعلی App Hosting و Branch زنده را ثبت کنید.
2. در AI Studio، GitHub panel را باز و Repository جدید یا موجود را متصل کنید.
3. پیش از Commit، فهرست فایل‌ها را بازبینی کنید و مطمئن شوید .env وارد مخزن نشده است.
4. در App Hosting، بخش Deployment را به Repository و Branch صحیح وصل کنید.
5. اولین Rollout را با یک تغییر کم‌ریسک اجرا و وضعیت Build را بررسی کنید.
6. پس از تأیید Health و مسیرهای اصلی، فرآیند قدیمی را بازنشسته کنید.

App Hosting روی Push به Branch زنده Build و Rollout ایجاد می‌کند. بنابراین Protection Rule، Review اجباری و تفکیک Branch آزمایشی از Production را قبل از اتصال فعال کنید. دامنه سفارشی را تنها پس از مشاهده پاسخ سالم از Backend مقصد تغییر دهید.

کلید Gemini و فایل .env را امن نگه دارید

یکی از مهم‌ترین تفاوت‌های مهاجرت این است که Firebase Studio هنگام انتشار، کلید Gemini را از Workspace می‌گرفت و به متغیر محیطی App Hosting تبدیل می‌کرد. پس از انتقال به AI Studio و استفاده از GitHub Sync، باید متغیر لازم را در Firebase Console به‌صورت دستی تنظیم کنید. فایل .env نباید وارد GitHub شود.

اگر احتمال می‌دهید Secret قبلاً Commit شده، حذف فایل در Commit جدید کافی نیست؛ History همچنان مقدار را نگه می‌دارد. ابتدا کلید را باطل و جایگزین کنید، سپس History را طبق سیاست تیم پاک‌سازی کنید. برای کنترل دقیق‌تر دسترسی، Secret Manager از متغیر قابل مشاهده برای همه اعضای پروژه مناسب‌تر است.

Authentication و Firestore را پس از انتقال آزمایش کنید

انتقال کد به‌تنهایی تنظیمات هویت و داده را منتقل یا تصحیح نمی‌کند. اگر Google Sign-In بعد از مهاجرت خطای دامنه می‌دهد، دامنه جدید اپ را در Firebase Authentication و بخش Authorized domains اضافه کنید. این کار را فقط برای دامنه‌ای انجام دهید که مالکیت و مقصد آن را می‌شناسید.

Ruleهای Firestore را با حساب‌های دارای نقش متفاوت امتحان کنید: کاربر ناشناس، کاربر عادی، مالک رکورد و مدیر. فقط موفق بودن درخواست مدیر معیار امنیت نیست. Queryهای واقعی، Indexها، Upload فایل و مسیرهای خطا را هم آزمایش کنید.

• ورود با Providerهای فعال و خروج کامل
• بازیابی Session پس از Refresh
• دسترسی ممنوع برای کاربر بدون مجوز
• خواندن و نوشتن رکورد شخصی
• جلوگیری از خواندن داده کاربر دیگر
• محدودیت اندازه و نوع فایل Upload
• رفتار برنامه هنگام قطع Backend

چک‌لیست Cutover بدون قطعی

Cutover را در ساعت کم‌ترافیک و با مسئول مشخص انجام دهید. برای هر مرحله معیار موفقیت و مسیر Rollback داشته باشید. اگر Rollout جدید سالم نیست، تغییر DNS یا Branch زنده را ادامه ندهید.

1. Backup قابل بازیابی و Commit مرجع را قفل کنید.
2. محیط مقصد را با Secretهای جداگانه آماده کنید.
3. Smoke Test فنی و سناریوی واقعی کاربر را اجرا کنید.
4. Performance، Error Rate و هزینه سرویس‌های Cloud را پایش کنید.
5. دامنه و URL عمومی را پس از تأیید Health متصل کنید.
6. برای یک بازه کوتاه Logهای مبدأ و مقصد را کنار هم مقایسه کنید.
7. نتیجه، Rollback Point و مسئول نگهداری را ثبت کنید.

پروژه مبدأ را بلافاصله پاک نکنید. ابتدا مطمئن شوید نسخه مقصد Build می‌شود، داده و Login سالم است، Secretها افشا نشده‌اند و تیم مسیر توسعه جدید را می‌شناسد. سپس طبق سیاست نگهداری سازمان درباره بازنشسته‌کردن Workspace تصمیم بگیرید.

اشتباه‌های رایج در مهاجرت

• به تعویق انداختن تا مارس ۲۰۲۷: هر اختلال حساب، دسترسی یا Build در روزهای آخر فرصت بازیابی را کم می‌کند.
• Commit کردن .env: انتقال سریع ارزش افشای Secret و هزینه ناخواسته را ندارد.
• تکیه بر Preview: Preview موفق ممکن است خطای Auth، Rule یا Production Runtime را پنهان کند.
• ساخت Firebase Project جدید بدون نیاز: ممکن است URL، داده و تنظیمات موجود از مسیر اصلی جدا شوند.
• تغییر هم‌زمان Hosting و Database: دامنه خطا را بزرگ می‌کند؛ انتقال را مرحله‌ای انجام دهید.
• نادیده گرفتن Billing: App Hosting و Cloud Run می‌توانند به حساب صورتحساب و سهمیه وابسته باشند.

جمع‌بندی

Firebase Studio اکنون یک سرویس در حال Sunset است، نه یک گزینه مناسب برای شروع پروژه جدید. Workspaceهای موجود تا ۲۲ مارس ۲۰۲۷ فرصت مهاجرت دارند و پس از آن داده باقی‌مانده حذف می‌شود. برای توسعه Prompt-first در مرورگر، Google AI Studio مسیر رسمی مناسبی است؛ برای Workflow کدمحور و کنترل محلی، Antigravity را ارزیابی کنید.

اصل مهم این است که کد، URL و Secret سه مسئله جدا هستند. انتقال فایل‌ها پایان کار نیست. Repository، App Hosting، متغیر محیطی، Authentication، Firestore Rules و Rollout باید مستقل تأیید شوند.

همین امروز فهرست Workspaceهای فعال را تهیه کنید، برای هر پروژه یک مالک مهاجرت تعیین کنید و پیش از هر انتقال یک Backup قابل بازیابی بگیرید.

منابع رسمی

• راهنمای رسمی پایان Firebase Studio و مهاجرت پروژه
• یادداشت‌های انتشار و زمان‌بندی Sunset
• وضعیت دسترسی و مسیرهای رسمی مهاجرت
• ساخت اپ تمام‌پشته در Google AI Studio
• انتشار اپ از Google AI Studio روی Cloud Run
• معماری، GitHub و Secretها در Firebase App Hosting