Firebase Extensions Deprecation and Shutdown

The Firebase Extensions service is deprecated and will shut down on March 31, 2027. While already installed extensions will execute indefinitely, key management features will no longer be available after this date. We recommend moving to self-managed function kits. For more details, see the FAQ and our publisher and user migration guides.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

העברת תוספים ל-Firebase לערכת פונקציות שנוצרה באופן עצמאי

בחירת מסלול העברה:

מעבר לערכות פונקציות ב-npm מעבר לערכת פונקציות שנוצרה באופן עצמאי

אם בעל האפליקציה לא יצר ערכת החלפה רשמית שמופצת ב-npm, המדריך הזה מסביר איך ליצור עותק של התוסף ולהגדיר אותו כערכת פונקציות מקומית.

בדיקת מגבלות ידועות בהעברה

לפני שמתחילים להעביר מופע של תוסף, צריך לבדוק אם ההגדרה שלכם משתמשת באחת מהתכונות הבאות שדורשות פתרון עקיף או שעדיין לא נתמכות בערכות פונקציות:

מאגרי Docker מותאמים אישית ומפתחות KMS דורשים פתרון עקיף ידני ‫Cloud Functions for Firebase לא תומך בפרמטרים של מערכת חלופית להגדרת מאגר Docker מותאם אישית או מפתח הצפנה בניהול הלקוח (מפתח KMS). אם התוסף מגדיר את אחד מהפרמטרים האלה, עיינו בפתרון החלופי בשאלות הנפוצות.

לפני שמתחילים

צריך להגדיר את ה-CLI של Firebase ולהפעיל פרויקט ב-Firebase. כשמשתמשים ב-CLI, חשוב לוודא שמשתמשים בגרסה >= 15.32.0 של firebase-tools, שכוללת את הפקודות החדשות של ערכת הפונקציות וההעברה.

הרשאות ותפקידים נדרשים בחשבון

בהתאם למה שצריך ליצור ולהגדיר באמצעות ה-CLI של Firebase במהלך ההעברה, לחשבון שבו אתם משתמשים כדי לבצע אימות מול 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 (אם צריך להפעיל ממשקי API חדשים)

מומלץ להשתמש בחשבון שכבר הותקנו בו תוספים ונפרסו בו פונקציות, כי רוב ההרשאות האלה כבר ניתנו. אם החשבון שאתם מעבירים צריך עוד תפקידים, תוכלו להוסיף אותם לפי ההוראות של Google Cloud IAM.

שדרוג מופע התוסף לגרסה העדכנית

חובה לעדכן את התוסף לגרסה העדכנית כדי לצמצם את ההבדל בין מופע התוסף לבין ערכת ההחלפה שלו. אם לא תשדרגו את התוסף, יכול להיות שיהיו שינויים משמעותיים שעלולים לגרום לכשל בין המופע של התוסף לבין הערכה שמחליפה אותו. יכול להיות שההגדרות שיוצאו לא יתאימו למה שהערכה מצפה לו בגלל שינויים בפרמטרים בין הגרסאות.

כדי לעדכן את התוסף, משתמשים באחת מהאפשרויות הבאות, בהתאם למקום שבו הוא הותקן:

ממסוף Firebase
מ-CLI של Firebase באמצעות:
- 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/.

כדי להעביר את קוד המקור של התוסף לפונקציה מהדור השני, פועלים לפי שלבים 1 עד 8 במדריך לבעלי תוכן דיגיטלי להעברת נתונים. ואז ממשיכים לשלבים הבאים.

התאמת הערכה המקומית לתמיכה באזור של הפונקציה המיוצאת ובפרמטרים מתקדמים

בערכת פונקציות מקומית, ה-CLI של 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";

בדיקת הערכה לפני ההעברה

עכשיו יש לכם ערכת פונקציות מקומית. כשפורסים אותה, היא פועלת בדיוק כמו התקנה חדשה של התוסף. השלב הבא הוא לאמת ולתקן את כל הבעיות שנוצרו בטעות במהלך התהליך, לפני שמעבירים אליו את המופעים של התוסף בסביבת הייצור.

קודם כל, מוסיפים את ה-fork כערכה מקומית, מגדירים אותה ופורסים אותה בפרויקט בדיקה. ערכות פונקציות מקומיות חייבות להיות בתוך פרויקט 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:

בדף Cloud Firestore במסוף Firebase, יוצרים את האוסף שהגדרתם בתור COLLECTION_PATH (users), אם הוא עדיין לא קיים.
יוצרים מסמך בשם bigquery-mirror-test שמכיל שדות עם ערכים כלשהם.
בדף BigQuery במסוף Google Cloud, שולחים שאילתה לטבלת יומן השינויים הגולמי. הוא צריך להכיל שורה אחת שמתעדת את יצירת המסמך:
```
SELECT * FROM `PROJECT_ID.analytics.users_raw_changelog`
```
שולחים שאילתה לתצוגה האחרונה, שאמורה להחזיר את אירוע השינוי האחרון של המסמך היחיד שקיים (bigquery-mirror-test):
```
SELECT * FROM `PROJECT_ID.analytics.users_raw_latest`
```
מוחקים את המסמך 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. אפשר גם לבצע בדיקת יחידה של הקוד באמצעות ה-SDK של 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. היא לא מוחקת את ספריית קוד המקור המקומית. כשמתקינים את הערכה להעברה בסביבת הייצור, אפשר לבחור שוב מזהה ערכה.

מעבר מתוספים לערכה המקומית

אחרי שבדקתם את הערכה המקומית, אתם יכולים להעביר את המופע של התוסף שנפרס בשידור חי.

1. התקנת המופע של ערכת הפונקציות החלופית

מתקינים את ערכת הפונקציות המקומית ומעבירים את --no-configure כדי לדלג על ההגדרה הידנית, כך שבשלב הבא אפשר יהיה לייצא את ההגדרות הקיימות של התוסף ישירות למכונה הזו של הערכה:

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

2. מגדירים את המכונה של ערכת הפונקציות באופן זהה לתוסף

צריך להתאים אישית את המופע הזה של הערכה עם הגדרה זהה לזו של התוסף שהוא מחליף. אתם יכולים לייצא את ההגדרות של המופע של התוסף לקובץ .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>

3. פריסה ואימות של הערכה החלופית

עכשיו, כשהערכה מותקנת וזמינה כקבוצת פונקציות, אתם יכולים לפרוס את הערכה החלופית. ערכות פונקציות פועלות כמו פונקציות רגילות, וכל מופע של ערכה משמש כבסיס קוד נפרד לארגון הפונקציות. אתם יכולים לפרוס את כל הפונקציות או רק מופע ספציפי של ערכה. כשמעבירים מופע יחיד של תוסף, צריך לפרוס רק את המופע הזה של הערכה.

אם בערכה שלכם יש פרמטרים חדשים שלא היו קיימים במופע של התוסף שהעברתם, ה-CLI של Firebase יבקש מכם להזין אותם בתחילת תהליך הפריסה. זה לא אמור לקרות בדוגמה הזו, כי היא מבוססת על גרסה עדכנית של התוסף 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 to BigQuery, משתמשים ב-lifecycle hooks. כך נראה הוק של מחזור חיים כשהוא מופעל:

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

הודעות היומן האלה מאשרות את הדברים הבאים:

נמצא והופעל הוק של מחזור חיים.
משימה הועברה לתור המשימות שמשויך להוק (hook) של מחזור החיים.
קישור ל-Cloud Logging כדי שתוכלו לוודא שהמשימה הושלמה בלי שגיאות.

עוברים דרך הקישור ליומנים למסוף Google Cloud כדי לוודא שאין שגיאות ביומנים ושהאירוע של תור המשימות עבר עיבוד בהצלחה. אם אירוע מחזור החיים לא בוצע בהצלחה, אפשר להפעיל אותו מחדש באמצעות הפקודה:

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

אם אתם פורסים מכונה של ערכת פונקציות בפעם הראשונה, הריצו את הפקודה:

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

אם בשלב כלשהו במהלך האימות תחליטו שאתם רוצים להפסיק או לבטל את ההעברה, תוכלו להסיר את הערכה לפי ההוראות שמפורטות בקטע הסרת התוסף.

אחרי שמוודאים שהפריסה הראשונית של ערכת הפונקציות הושלמה בהצלחה, צריך לוודא שהפונקציונליות של הערכה פועלת כמו שצריך. מכיוון שהתוסף עצמו עדיין פועל, צריך לוודא שמה שבודקים הוא לא רק שאחד משני הדברים עבד, כי התוסף פעל וימשיך לפעול.

אם העיבוד לא השתנה ולא מופיעות תוצאות כפולות מהתוסף ומהערכה, האפשרות הכי טובה היא לבדוק ישירות את היומנים של הערכה אחרי שמפעילים את הפונקציונליות שלה.

דוגמה מעשית: העברה של Cloud Firestore אל BigQuery

כשמשתמשים בתוסף Stream Cloud Firestore to 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                                                     │

4. הסרת התוסף

אחרי שמוודאים שערכת הפונקציות נפרסה, אפשר להסיר את התוסף כדי לא לשכפל את ההתנהגות שלו – פעם אחת בערכה ופעם אחת בתוסף. אתם יכולים להסיר את כל התוספים מ-CLI של Firebase, לא משנה איך התקנתם אותם, אם תעבירו את הדגל --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

אם העברתם את שני המופעים האלה של התוספים לשני מופעים של ערכת פונקציות בבסיס קוד אחד כשעבדתם עם ה-CLI של Firebase, ופרסתם באמצעות 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 או להתקין מכונה שנייה.

העברת תוספים ל-Firebase לערכת פונקציות שנוצרה באופן עצמאי קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

בדיקת מגבלות ידועות בהעברה

לפני שמתחילים

הרשאות ותפקידים נדרשים בחשבון

שדרוג מופע התוסף לגרסה העדכנית

פיצול התוסף לערכת פונקציות מקומית

התאמת הערכה המקומית לתמיכה באזור של הפונקציה המיוצאת ובפרמטרים מתקדמים

בדיקת הערכה לפני ההעברה

(אופציונלי) ניקוי אחרי הבדיקה

מעבר מתוספים לערכה המקומית

1. התקנת המופע של ערכת הפונקציות החלופית

2. מגדירים את המכונה של ערכת הפונקציות באופן זהה לתוסף

3. פריסה ואימות של הערכה החלופית

4. הסרת התוסף

העברות מתקדמות

העברת תוספים ל-Firebase לערכת פונקציות שנוצרה באופן עצמאי