انتقال دادن «افزونه‌های Firebase» به کیت تابع خودساخته

انتخاب مسیر انتقال: انتقال به کیت‌های تابع در npm انتقال به کیت تابع خودساخته

اگر ناشری کیت جایگزین رسمی ایجاد نکرده باشد که در npm توزیع شده باشد، این راهنما مراحل انشعاب افزونه آن‌ها و راه‌اندازی آن به‌عنوان کیت تابع محلی را به شما نشان می‌دهد.

بررسی محدودیت‌های شناخته‌شده انتقال

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

  • مخازن Docker سفارشی و کلیدهای KMS به راه‌حل دستی نیاز دارند Cloud Functions for Firebase از پارامترهای سیستم جایگزین برای پیکربندی مخزن Docker سفارشی یا «کلید رمزگذاری مدیریت‌شده توسط مشتری» (کلید KMS) پشتیبانی نمی‌کند. اگر افزونه شما هرکدام از این پارامترها را پیکربندی می‌کند، به راه‌حل پرسشگان مراجعه کنید.

قبل از شروع

باید Firebase CLI را راه‌اندازی کنید و Firebase پروژه را مقداردهی اولیه کنید. هنگام استفاده از CLI، مطمئن شوید از نسخه >= 15.32.0 firebase-tools استفاده می‌کنید که دارای دستورات جدید انتقال و کیت تابع است.

اجازه‌ها و نقش‌های لازم حساب

بسته به آنچه باید توسط Firebase CLI درطول انتقال ایجاد و پیکربندی شود، حسابی که برای اصالت‌سنجی با Firebase و Google Cloud استفاده می‌کنید باید نقش‌های زیر را داشته باشد:

  • roles/firebaseextensions.editor
  • roles/cloudbuild.builds.editor
  • roles/artifactregistry.writer
  • roles/run.developer
  • roles/iam.serviceAccountUser
  • roles/iam.serviceAccountCreator
  • roles/cloudfunctions.admin (اگر لازم است setIamPermissions را برای نقاط پایانی عمومی انجام دهید)
  • roles/secretmanager.admin (درصورت استفاده از اسرار)
  • roles/serviceusage.serviceUsageAdmin (اگر لازم است میاناهای برنامه‌سازی کاربردی جدیدی را فعال کنید)

توصیه می‌کنیم از حسابی استفاده کنید که قبلاً افزونه نصب کرده و تابع مستقر کرده است، زیرا اکثر این اجازه‌ها قبلاً اعطا شده‌اند. اگر حساب انتقالی شما به نقش‌های بیشتری نیاز دارد، Google Cloudدستورالعمل‌های IAM را برای افزودن آن‌ها دنبال کنید.

نمونه افزونه‌تان را به جدیدترین نسخه ارتقا دهید

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

بسته به اینکه افزونه‌تان کجا نصب شده است، از یکی از گزینه‌های زیر برای به‌روزرسانی آن استفاده کنید:

  • از کنسول Firebase
  • از Firebase CLI بااستفاده از:
    • firebase ext:update <extension-instance-id> --project <project-id> firebase deploy --only extensions --project <project-id>

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

انشعاب افزونه به کیت تابع محلی

قبل‌از شروع تبدیل افزونه به کیت تابع محلی، مطمئن شوید که کد منبع افزونه در پروژه Firebase شما قرار دارد. برای انجام این کار، مخزن افزونه را از GitHub شبیه‌سازی کنید، دایرکتوری‌ای در Firebase ریشه پروژه ایجاد کنید، و پوشه افزونه functions/ و extension.yaml را در آن کپی کنید:

mkdir -p path/to/kit
cp -r /path/to/extension-source/functions/* path/to/kit/
cp /path/to/extension-source/extension.yaml path/to/kit/.

مراحل ۱ تا ۸ راهنمای انتقال ناشر را دنبال کنید تا کد منبع افزونه‌تان را به تابع نسل دوم انتقال دهید. سپس مراحل زیر را دنبال کنید.

کیت محلی‌تان را طوری بسازید که از منطقه تابع صادرشده و پارامترهای پیشرفته پشتیبانی کند

در کیت تابع محلی، رابط خط فرمان Firebase فایل index.ts را برای راه‌اندازی بسته و پیکربندی آن برای استفاده از پارامترهای سیستم منتقل‌شده تولید نمی‌کند. برای استفاده از منطقه تابع و پارامترهای پیشرفته‌ای که برای افزونه‌تان پیکربندی شده است، فایل index.ts را طوری تنظیم کنید که قالب صادرشده توسط firebase ext:export --mode functions را در فایل متغیر محیطی بخواند.

به‌طور خاص، در فایل سطح بالای index.ts که توابع شما را صادر می‌کند، پارامتری برای FUNCTION_DEFAULT_REGION تعریف کنید و setGlobalOptions را با متغیرهای محیطی به‌شکل EXT_MIGRATED_SYSTEM_<GLOBAL_OPTION> فراخوانی کنید، مشابه الگوی index-kit-migration.ts که توسط CLI استفاده می‌شود:

import { setGlobalOptions } from "firebase-functions";
import { MemoryOption, VpcEgressSetting, IngressSetting } from "firebase-functions/v2/options";
import { defineString } from "firebase-functions/params";

export const regionParam = defineString("FUNCTION_DEFAULT_REGION", {
  input: { text: { nonEmpty: true } },
  description: "Global default region where functions should be deployed. Can be overridden per-function.",
});

setGlobalOptions({
  region: regionParam,
  memory: (process.env.EXT_MIGRATED_SYSTEM_MEMORY as MemoryOption) ?? undefined,
  timeoutSeconds: process.env.EXT_MIGRATED_SYSTEM_TIMEOUTSECONDS
    ? Number(process.env.EXT_MIGRATED_SYSTEM_TIMEOUTSECONDS)
    : undefined,
  vpcConnectorEgressSettings:
    process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOREGRESSSETTINGS &&
    process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOREGRESSSETTINGS !== "VPC_CONNECTOR_EGRESS_SETTINGS_UNSPECIFIED"
      ? (process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOREGRESSSETTINGS as VpcEgressSetting)
      : undefined,
  vpcConnector: process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOR ?? undefined,
  maxInstances: process.env.EXT_MIGRATED_SYSTEM_MAXINSTANCES
    ? Number(process.env.EXT_MIGRATED_SYSTEM_MAXINSTANCES)
    : undefined,
  minInstances: process.env.EXT_MIGRATED_SYSTEM_MININSTANCES
    ? Number(process.env.EXT_MIGRATED_SYSTEM_MININSTANCES)
    : undefined,
  ingressSettings: (process.env.EXT_MIGRATED_SYSTEM_INGRESSSETTINGS as IngressSetting) ?? undefined,
  // Parses a comma-separated string of key:value pairs into a key-value object
  // (for example, "key1:value1,key2:value2" -> { key1: "value1", key2: "value2" }).
  labels: process.env.EXT_MIGRATED_SYSTEM_LABELS
    ? process.env.EXT_MIGRATED_SYSTEM_LABELS.split(",").reduce<Record<string, string> | undefined>(
        (acc, curr) => {
          const [key, value] = curr.split(":");
          const trimmedKey = key?.trim();
          const trimmedValue = value?.trim();
          if (!trimmedKey || !trimmedValue) {
            return acc;
          }
          acc = acc ?? {};
          acc[trimmedKey] = trimmedValue;
          return acc;
        },
        undefined,
      )
    : undefined,
});

// Re-export all functions so the Firebase CLI can deploy them
export * from "./your-functions";

کیت خود را قبل‌از انتقال آزمایش کنید

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

ابتدا، انشعاب خود را به‌عنوان کیت محلی اضافه کنید، آن را پیکربندی کنید، و آن را در پروژه آزمایشی مستقر کنید. کیت‌های تابع محلی باید در پروژه Firebase شما قرار داشته باشند، بنابراین اگر مخزن افزونه کلون‌شده خارج از پروژه Firebase شما است، آن را به داخل دایرکتوری پروژه منتقل کنید. سپس فرمان نصب کیت زیر را اجرا کنید تا آن را به‌عنوان کیت محلی نصب کنید:

firebase functions:kits:install --directory <path-to-your-fork> --project <test-project-id>

این فرمان شما را در انتخاب شناسه کیت، شناسه نمونه، و پیکربندی برای اولین نمونه آزمایشی‌تان راهنمایی می‌کند. سپس فایل firebase.json شما را اصلاح می‌کند تا کیت محلی‌ای را که به فهرست راهنمای انشعابی شما اشاره می‌کند ثبت کند، و پیکربندی‌های هر نمونه در فایل .env در function-kits/<kit-id>/config-<instance-id> ذخیره می‌شود.

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

firebase deploy --only functions:<kit-instance-id> --project <test-project-id>

نمونه حل‌شده: جاری‌سازی Cloud Firestore به BigQuery (firestore-bigquery-export)

درستی‌سنجی کردن همگام‌سازی سرتاسر Cloud Firestore به BigQuery:

  1. در صفحه Cloud Firestore کنسول Firebase، مجموعه‌ای را که به‌عنوان COLLECTION_PATH (users) تنظیم کرده‌اید ایجاد کنید (اگر ازقبل وجود ندارد).
  2. سندی به‌نام bigquery-mirror-test ایجاد کنید که حاوی فیلدهایی با مقادیر مختلف باشد.

  3. در صفحه BigQuery کنسول Google Cloud، جدول گزارش تغییرات خام را پُرسمان کنید. این فایل باید حاوی یک ردیف باشد که ایجاد سند را ثبت کند:

    SELECT * FROM `PROJECT_ID.analytics.users_raw_changelog`

  4. آخرین نمای را پُرسمان کنید که باید آخرین رویداد تغییر را برای تنها سند موجود (bigquery-mirror-test) برگرداند:

    SELECT * FROM `PROJECT_ID.analytics.users_raw_latest`

  5. سند bigquery-mirror-test را در Cloud Firestore حذف کنید. از نمای جدیدترین ناپدید می‌شود و رویداد DELETE به جدول گزارش تغییرات خام اضافه می‌شود.

    می‌توانید سابقه کامل یک سند را با موارد زیر بررسی کنید:

    SELECT *
   FROM `PROJECT_ID.analytics.users_raw_changelog`
   WHERE document_name = "bigquery-mirror-test"
   ORDER BY timestamp ASC

تفاوت‌های آزمایش کردن افزونه:

  • راه‌انداز به‌عنوان kit-<kit-instance-id>-fsexportbigquery مستقر می‌شود، نه ext-<instanceId>-fsexportbigquery. آن نام را در داشبورد و گزارش‌های Cloud Functions جستجو کنید.
  • کد شما در Firebase Local Emulator Suite به‌عنوان توابع استاندارد اجرا می‌شود. می‌توانید مقادیر پارامتر را برای استفاده در شبیه‌ساز با .env.local تنظیم کنید. همچنین می‌توانید کدتان را بااستفاده از کیت توسعه نرم‌افزار firebase-functions-test همان‌طور که در آزمایش واحد Cloud Functions شرح داده شده است آزمایش واحد کنید.
  • تأمین دیگر توسط زمان اجرای «افزونه‌ها» انجام نمی‌شود. اگر جدول گزارش تغییرات پس‌از استقرار وجود ندارد، تکلیف راه‌اندازی را به‌صورت دستی دوباره اجرا کنید: firebase functions:lifecycle:run afterFirstDeploy <kit-instance-id>. تکلیف تکرارپذیر است، بنابراین اجرای مجدد آن مجموعه داده، جدول، و نماها را تطبیق می‌دهد.
  • مقادیر پارامتر از .env می‌آید نه از فرم نصب، بنابراین اجرای مجدد firebase deploy پس‌از تکمیل .env غیرتعاملی است.

(اختیاری) پاک‌سازی از آزمایش

اگر می‌خواهید این نمونه آزمایشی را پس‌از آزمایش بردارید، آن را حذف نصب کنید:

firebase functions:kits:uninstall --instance <kit-instance-id> --project <test-project-id>

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

انتقال از افزونه‌ها به کیت محلی

اکنون که کیت محلی شما آزمایش شده است، می‌توانید نمونه افزونه مستقرشده زنده خود را منتقل کنید.

۱. نصب نمونه کیت تابع جایگزین

کیت تابع محلی‌تان را نصب کنید و --no-configure را رد کنید تا از پیکربندی دستی رد شوید تا مرحله بعدی بتواند پیکربندی افزونه موجودتان را مستقیماً به این نمونه کیت صادر کند:

firebase functions:kits:install --no-configure --directory <path-to-your-fork> --project <project-id>

۲. نمونه کیت تابع را به‌طور یکسان با افزونه پیکربندی کنید

باید این نمونه کیت را با پیکربندی یکسان با افزونه‌ای که جایگزین آن می‌شود سفارشی‌سازی کنید. می‌توانید پیکربندی نمونه افزونه‌تان را به فایل .env صادر کنید که داده‌های پیکربندی مرجع محرمانه، متغیر محیطی، و پارامتر را برای همه Cloud Functions، ازجمله کیت‌ها، ذخیره می‌کند. برای صادر کردن مستقیم آن به فایل پیکربندی کیت، این دستور را اجرا کنید:

firebase ext:export --mode functions --instance <extension-instance-id> --kit-instance <kit-instance-id> --project <project-id>

در پایان این مرحله، اطلاعات پیکربندی این نمونه در فایل .env مختص پروژه در فهرست راهنمای پیکربندی نمونه شما ذخیره می‌شود، مانند: function-kits/<kit-name>/config-<instance-id>/.env.<project-id>

۳. کیت جایگزین را مستقر و درستی‌سنجی کنید

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

اگر کیت شما از پارامترهای جدیدی استفاده می‌کند که در نمونه افزونه‌ای که از آن مهاجرت کرده‌اید وجود نداشت، Firebase CLI در ابتدای فرایند استقرار از شما می‌خواهد آن‌ها را وارد کنید. این مورد در این مثال کاربردی از افزونه به‌روز firestore-bigquery-export انتظار نمی‌رود، اما بسیاری از کیت‌ها برای هر منبع راه‌انداز رویداد که توسط کیت استفاده می‌شود، پارامتر جدیدی درخواست می‌کنند. به‌عنوان بخشی از این انتقال، کیت‌های به‌روزشده از توابع نسل دوم استفاده می‌کنند، درحالی‌که افزونه‌ها قبلاً از توابع نسل اول استفاده می‌کردند. در نسل دوم، توابع نزدیک به منابع رویدادشان قرار دارند و به‌عنوان پارامتر اضافی اضافه می‌شوند. در به‌روزرسانی‌های آینده، اگر پارامترهای جدیدی اضافه شود، CLI در استقرار بعدی از شما درخواست می‌کند.

نمونه حل‌شده:

firebase deploy --only functions:firestore-bigquery-export --project my-project

برونداد:

=== Deploying to 'my-project'...
i  deploying functions
i  functions: Loaded environment variables from function-kits/firestore-bigquery-export/config-firestore-bigquery-export/.env.my-project
i  functions: ensuring required API bigquery.googleapis.com is enabled...
i  functions: ensuring required API cloudtasks.googleapis.com is enabled...
✔  functions: required APIs are enabled
i  functions: granting declarative IAM roles to managed service account:
   - BigQuery Data Editor
   - BigQuery User
   - Cloud Datastore User
   - Eventarc Event Receiver
   - roles/run.invoker
✔  functions: successfully granted IAM roles
i  functions: creating Node.js 22 (2nd Gen) function kit-firestore-bigquery-export-fsexportbigquery(us-central1)...
i  functions: creating Node.js 22 (2nd Gen) function kit-firestore-bigquery-export-initBigQuerySync(us-central1)...
i  functions: creating Node.js 22 (2nd Gen) function kit-firestore-bigquery-export-setupBigQuerySync(us-central1)...
✔  functions[kit-firestore-bigquery-export-fsexportbigquery(us-central1)] Successful create operation.
✔  functions[kit-firestore-bigquery-export-initBigQuerySync(us-central1)] Successful create operation.
✔  functions[kit-firestore-bigquery-export-setupBigQuerySync(us-central1)] Successful create operation.
i  functions: Executing afterFirstDeploy lifecycle hook targeting: kit-firestore-bigquery-export-initBigQuerySync...
✔  functions: Successfully queued task for lifecycle hook kit-firestore-bigquery-export-initBigQuerySync in queue projects/my-project/locations/us-central1/queues/kit-firestore-bigquery-export-initBigQuerySync.
✔  Deploy complete!

برای تأیید اینکه firebase deploy کیت هیچ خطایی نداشته است، گزارش‌های استقرار را بررسی کنید تا ببینید آیا قلاب‌های چرخه حیات فعال شده‌اند یا نه. افزونه‌های پرطرفدار، مثل Stream Cloud Firestore به BigQuery، از قلاب‌های چرخه حیات استفاده می‌کنند. در زیر نمونه‌ای از ظاهر قلاب چرخه حیات هنگام راه‌اندازی آورده شده است:

i  functions: Executing afterFirstDeploy lifecycle hook targeting: kit-firestore-bigquery-export-initBigQuerySync...
✔  functions: Successfully queued task for lifecycle hook kit-firestore-bigquery-export-initBigQuerySync in queue projects/my-project/locations/europe-west1/queues/kit-firestore-bigquery-export-initBigQuerySync.
i  functions: View logs for afterFirstDeploy at: https://console.cloud.google.com/logs/query;query=resource.type%3D%22cloud_run_revision%22%0Aresource.labels.service_name%3D%22kit-firestore-bigquery-export--initbigquerysync%22%0Aresource.labels.location%3D%22europe-west1%22;project=my-project

این پیام‌های گزارش موارد زیر را تأیید می‌کنند:

  • یک قلاب چرخه حیات پیدا و اجرا شد.
  • تکلیفی در صف تکلیف مرتبط با قلاب چرخه حیات قرار گرفت.
  • پیوندی به Cloud Logging ارائه شده است تا بتوانید تأیید کنید که تکلیف بدون خطا تکمیل شده است.

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

firebase functions:lifecycle:run <hook-name> <codebase>

اگر برای اولین‌بار است که نمونه کیت تابع را مستقر می‌کنید، این دستور را اجرا کنید:

firebase functions:lifecycle:run afterFirstDeploy <kit-instance-id>

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

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

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

نمونه کارشده: جاری‌سازی Cloud Firestore به BigQuery

با «افزونه جاری‌سازی Cloud Firestore به BigQuery»، اگر رویداد یکسانی به کیت و افزونه ارسال شود، نوشتن در هر دو «جدول گزارش تغییرات خام» (*_raw_changelog) و جدول آخرین نما (*_raw_latest) تکرارزدایی خواهد شد. بنابراین نمی‌توانید از وجود هرگونه ردیف یا ردیف تکراری در BigQuery برای اعتبارسنجی عملکرد کیت استفاده کنید.

می‌توانید گزارش‌های توابع را کمی پس‌از نوشتن در مجموعه Firestore خود بااستفاده از firebase functions:logs مشاهده کنید و به‌دنبال ورودی گزارشی بگردید که نشان می‌دهد نوشتن را با موفقیت پردازش کرده است. برای این کیت با شناسه نمونه پیش‌فرض firestore-bigquery-export به‌صورت زیر خواهد بود:

2026-09-25T19:52:46.328612Z I kit-firestore-bigquery-export-fsexportbigquery: Started execution of extension
2026-09-25T19:52:46.328644Z I kit-firestore-bigquery-export-fsexportbigquery: {"message":"Firestore event received by onDocumentWritten trigger","document_name":"projects/extensions-eventarc-testing/databases/(default)/documents/exported-messages/cmGP6XLyksqGdw2OgTOq","operation":0,"event_id":"9f59a2a4-1a5e-4c41-a32d-561e3c734502"}
2026-09-25T19:52:46.616064Z I kit-firestore-bigquery-export-fsexportbigquery: Completed execution of extension
2026-09-2

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

firebase functions:log --only <function name>

برای پیدا کردن نام‌های تابع خاص برای نمونه کیت، می‌توانید از فرمان زیر استفاده کنید:

firebase functions:list | grep kit-<kit instance id>

برای این مثال:

firebase functions:list | grep kit-firestore-bigquery-export
│ kit-firestore-bigquery-export-fsexportbigquery  │ v2      │ google.cloud.firestore.document.v1.written                    │
│ kit-firestore-bigquery-export-initBigQuerySync  │ v2      │ taskQueue                                                     │
│ kit-firestore-bigquery-export-setupBigQuerySync │ v2      │ taskQueue                                                     │
│ kit-firestore-bigquery-export-syncBigQuery      │ v2      │ taskQueue                                                     │

۴. حذف نصب افزونه

وقتی کیت تابع مستقرشده را درستی‌سنجی کردید، می‌توانید افزونه را حذف نصب کنید تا رفتار آن یک‌بار برای کیت و یک‌بار برای افزونه تکرار نشود. می‌توانید همه افزونه‌ها را از Firebase CLI حذف نصب کنید صرف‌نظر از اینکه چگونه آن‌ها را نصب کرده‌اید، اگر پرچم --immediate را ارسال کنید:

firebase ext:uninstall <extension-instance-id> --project <project-id> --immediate

نمونه حل‌شده:

firebase ext:uninstall firestore-bigquery-export --project my-project --immediate

برونداد:

i  extensions: uninstalling firestore-bigquery-export...
i  extensions: deleting extension instance resources in project my-project...
✔  extensions: successfully uninstalled firestore-bigquery-export

انتقال‌های پیشرفته

می‌توانید در چندین پروژه Firebase افزونه داشته باشید که می‌خواهید با یک پایگاه کد واحد مدیریت کنید. برای مثال، اگر زیرساخت یکسانی را در محیط testing و محیط production مستقر کنید، که هرکدام نمونه documents Cloud Firestore دارند که به BigQuery صادر می‌کنید، ممکن است دو نمونه از افزونه firestore-bigquery-export نصب‌شده داشته باشید:

  • export-documents-testing
  • export-documents-production

اگر این دو نمونه افزونه را به دو نمونه کیت تابع در یک پایگاه کد واحد هنگام کار با Firebase CLI منتقل کرده و بااستفاده از firebase deploy --project testing و firebase deploy --project production مستقر کرده باشید، هر استقرار دو نمونه در هر دو محیط testing و production ایجاد می‌کند.

به‌جای آن، دو نمونه افزونه را با یک نمونه کیت تابع firestore-bigquery-export که در چند پروژه مستقر شده است جایگزین کنید، به‌طوری‌که هر پروژه پیکربندی خودش را داشته باشد. فهرست پیکربندی شما برای نمونه باید به‌صورت زیر باشد:

  • config-export-documents/
    • .env.testing
    • .env.production

هر استقرار در testing و production یک نمونه از کیت شما را با پیکربندی مربوطه ایجاد می‌کند. فرمان‌های CLI موجود این راه‌اندازی را ایجاد می‌کنند، به‌شرطی که پرچم --project را در هر فراخوانی ext:migrate یا functions:kits:install ارسال کنید.

نمونه حل‌شده:

firebase functions:kits:install --package @firebase-function-kits/firestore-bigquery-export --project testing --no-configure --template migration

✔ What would you like to name this kit? firestore-bigquery-export
✔ What would you like to name this instance? export-documents
✔  Wrote function-kits/firestore-bigquery-export/source/package.json
✔  Wrote function-kits/firestore-bigquery-export/source/tsconfig.json
✔  Wrote function-kits/firestore-bigquery-export/source/.gitignore
✔  Wrote function-kits/firestore-bigquery-export/source/src/index.ts
i  functions: Running npm install
✔  Wrote configuration info to firebase.json
✔  functions: Function kit firestore-bigquery-export successfully installed.

# This creates the export-documents instance with an empty .env.testing file
# for the testing project. Now populate it via export:
firebase ext:export --mode functions --instance export-documents-testing \
  --kit-instance export-documents --project testing

# Repeat the export for production into the same kit instance to create
# .env.production from the export-documents-prod instance:
firebase ext:export --mode functions --instance export-documents-prod \
  --kit-instance export-documents --project production

اکنون یک نمونه کیت دارید که برای استقرار در پروژه‌های testing و production با پیکربندی‌های مربوطه‌شان پیکربندی شده است. اگر نمونه‌ای در پروژه testing ایجاد کنید و فرمان functions:kits:install را برای همان بسته در پروژه production اجرا کنید، گزینه‌ای برای استفاده مجدد از نمونه پیکربندی‌شده برای testing یا نصب نمونه دوم به شما نشان داده می‌شود.