Firebase एक्सटेंशन को खुद बनाए गए फ़ंक्शन किट में माइग्रेट करना

माइग्रेशन का तरीका चुनें: npm पर फ़ंक्शन किट पर माइग्रेट करना खुद की बनाई गई फ़ंक्शन किट पर माइग्रेट करना

अगर किसी पब्लिशर ने npm पर डिस्ट्रिब्यूट की गई आधिकारिक रिप्लेसमेंट किट नहीं बनाई है, तो यह गाइड आपको उनके एक्सटेंशन को फ़ोर्क करने और उसे लोकल फ़ंक्शन किट के तौर पर सेट अप करने का तरीका बताती है.

माइग्रेशन से जुड़ी सीमाओं के बारे में जानें

किसी एक्सटेंशन इंस्टेंस को माइग्रेट करने से पहले, देखें कि आपके सेटअप में इनमें से किसी सुविधा का इस्तेमाल किया जा रहा है या नहीं. इन सुविधाओं के लिए, कोई दूसरा तरीका अपनाना पड़ता है या फ़ंक्शन किट में ये सुविधाएं अब तक काम नहीं करती हैं:

  • कस्टम Docker रिपॉज़िटरी और केएमएस कुंजियों के लिए, मैन्युअल तरीके से काम करना पड़ता है Cloud Functions for Firebase, कस्टम Docker रिपॉज़िटरी या ग्राहक की ओर से मैनेज की जाने वाली एन्क्रिप्शन कुंजी (केएमएस कुंजी) को कॉन्फ़िगर करने के लिए, सिस्टम पैरामीटर को बदलने की सुविधा के साथ काम नहीं करता. अगर आपका एक्सटेंशन इनमें से किसी भी पैरामीटर को कॉन्फ़िगर करता है, तो अक्सर पूछे जाने वाले सवालों में बताया गया तरीका देखें.

शुरू करने से पहले

आपको Firebase सीएलआई सेट अप करना होगा और Firebase प्रोजेक्ट शुरू करना होगा. सीएलआई का इस्तेमाल करते समय, पक्का करें कि firebase-tools वर्शन >= 15.32.0 का इस्तेमाल किया जा रहा हो. इसमें माइग्रेशन और फ़ंक्शन किट के नए कमांड मौजूद हैं.

खाते के लिए ज़रूरी अनुमतियां और भूमिकाएं

माइग्रेशन के दौरान, 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 (अगर आपको नए एपीआई चालू करने हैं)

हमारा सुझाव है कि ऐसे खाते का इस्तेमाल करें जिससे पहले भी एक्सटेंशन इंस्टॉल किए गए हों और फ़ंक्शन डिप्लॉय किए गए हों. ऐसा इसलिए, क्योंकि ऐसे खाते को ज़्यादातर अनुमतियां पहले ही मिल चुकी होंगी. अगर माइग्रेट किए जा रहे खाते को ज़्यादा भूमिकाओं की ज़रूरत है, तो उन्हें जोड़ने के लिए Google Cloud IAM के निर्देशों का पालन करें.

अपने एक्सटेंशन इंस्टेंस को नए वर्शन पर अपग्रेड करना

आपको अपने एक्सटेंशन को नए वर्शन पर अपडेट करना होगा, ताकि आपके एक्सटेंशन इंस्टेंस और उसके रिप्लेसमेंट किट के बीच का अंतर कम हो सके. अगर आपका एक्सटेंशन अपग्रेड नहीं किया गया है, तो आपके एक्सटेंशन इंस्टेंस और उसकी किट के रिप्लेसमेंट के बीच काफ़ी अहम और नुकसान पहुंचा सकने वाले बदलाव हो सकते हैं. ऐसा हो सकता है कि एक्सपोर्ट किया गया कॉन्फ़िगरेशन, किट की उम्मीद के मुताबिक न हो. ऐसा वर्शन के हिसाब से पैरामीटर में होने वाले बदलावों की वजह से होता है.

एक्सटेंशन को अपडेट करने के लिए, इनमें से किसी एक विकल्प का इस्तेमाल करें. यह इस बात पर निर्भर करता है कि उसे कहां इंस्टॉल किया गया था:

  • Firebase कंसोल से
  • Firebase सीएलआई से, इसका इस्तेमाल करके:
    • firebase ext:update <extension-instance-id> --project <project-id> firebase deploy --only extensions --project <project-id>

अगर इस चरण को स्किप किया जाता है, तो कॉन्फ़िगरेशन एक्सपोर्ट करते समय सीएलआई आपको अपग्रेड करने के लिए कहेगा. ऐसा तब होगा, जब आपका एक्सटेंशन नए वर्शन पर न हो.

एक्सटेंशन को लोकल फ़ंक्शन किट में फ़ोर्क करना

किसी एक्सटेंशन को लोकल फ़ंक्शन किट में बदलने से पहले, पक्का करें कि एक्सटेंशन का सोर्स कोड आपके 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 के लिए एक पैरामीटर तय करें और EXT_MIGRATED_SYSTEM_<GLOBAL_OPTION> फ़ॉर्म के एनवायरमेंट वैरिएबल के साथ setGlobalOptions को कॉल करें. यह सीएलआई के इस्तेमाल किए गए index-kit-migration.ts टेंप्लेट जैसा ही है:

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 फ़ाइल में बदलाव करता है, ताकि आपकी फ़ोर्क की गई डायरेक्ट्री पर ले जाने वाली लोकल किट को रजिस्टर किया जा सके. साथ ही, हर इंस्टेंस के कॉन्फ़िगरेशन को function-kits/<kit-id>/config-<instance-id> में मौजूद .env फ़ाइल में सेव किया जा सके.

अपनी लोकल किट को टेस्ट प्रोजेक्ट में डिप्लॉय करें. इसके लिए, सही संसाधनों का इस्तेमाल करें, ताकि उसके व्यवहार की जांच की जा सके. अगर आपने एक्सटेंशन की जांच करने के लिए, पहले से ही कोई टेस्ट प्रोजेक्ट सेट अप किया हुआ है, तो यह कमांड चलाएं:

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

उदाहरण: Cloud Firestore से BigQuery तक स्ट्रीम करें (firestore-bigquery-export)

Cloud Firestore से BigQuery तक के सिंक की एंड-टू-एंड पुष्टि करें:

  1. Firebase कंसोल के Cloud Firestore पेज पर, वह कलेक्शन बनाएं जिसे आपने COLLECTION_PATH (users) के तौर पर सेट किया है. ऐसा तब करें, जब वह कलेक्शन पहले से मौजूद न हो.
  2. bigquery-mirror-test नाम का एक दस्तावेज़ बनाएं, जिसमें किसी भी वैल्यू वाले कोई भी फ़ील्ड हों.

  3. Google Cloud कंसोल के BigQuery पेज पर, रॉ चेंजलॉग टेबल के लिए क्वेरी करें. इसमें दस्तावेज़ बनाने की जानकारी वाली एक लाइन होनी चाहिए:

    SELECT * FROM `PROJECT_ID.analytics.users_raw_changelog`

  4. सबसे नए व्यू के लिए क्वेरी करें. इससे, मौजूद एकमात्र दस्तावेज़ (bigquery-mirror-test) के लिए, बदलाव से जुड़ा सबसे नया इवेंट दिखेगा:

    SELECT * FROM `PROJECT_ID.analytics.users_raw_latest`

  5. Cloud Firestore में मौजूद bigquery-mirror-test दस्तावेज़ को मिटाएं. यह सबसे नए व्यू से हट जाता है और बदलावों के लॉग की रॉ टेबल में 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 SDK टूल का इस्तेमाल करके, अपने कोड का यूनिट टेस्ट भी किया जा सकता है. इसके बारे में Cloud Functions का यूनिट टेस्ट में बताया गया है.
  • अब एक्सटेंशन रनटाइम से प्रोविज़निंग नहीं की जाती. अगर डिप्लॉय करने के बाद, चेंजलॉग टेबल मौजूद नहीं है, तो सेटअप टास्क को मैन्युअल तरीके से फिर से चलाएं: firebase functions:lifecycle:run afterFirstDeploy <kit-instance-id>. टास्क आइडेंपोटेंट है. इसलिए, इसे फिर से चलाने पर डेटासेट, टेबल, और व्यू को फिर से व्यवस्थित किया जाता है.
  • पैरामीटर की वैल्यू, इंस्टॉलेशन फ़ॉर्म के बजाय .env से मिलती हैं. इसलिए, .env के पूरा होने के बाद, firebase deploy को फिर से चलाने पर, इंटरैक्ट नहीं किया जा सकता.

(ज़रूरी नहीं) टेस्टिंग के बाद डेटा मिटाना

अगर आपको टेस्टिंग के बाद इस टेस्ट इंस्टेंस को हटाना है, तो इसे अनइंस्टॉल करें:

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. किट को डिप्लॉय करना और उसकी पुष्टि करना

अब किट इंस्टॉल हो गई है और फ़ंक्शन के सेट के तौर पर उपलब्ध है. इसलिए, किट को बदलने की प्रोसेस को डिप्लॉय किया जा सकता है. फ़ंक्शन किट, स्टैंडर्ड फ़ंक्शन की तरह काम करती हैं. इनमें हर किट इंस्टेंस, आपके फ़ंक्शन को व्यवस्थित करने के लिए एक अलग कोड बेस के तौर पर काम करता है. आपके पास अपने सभी फ़ंक्शन या सिर्फ़ किसी खास किट इंस्टेंस को डिप्लॉय करने का विकल्प होता है. किसी एक एक्सटेंशन इंस्टेंस को माइग्रेट करते समय, सिर्फ़ उस किट इंस्टेंस को डिप्लॉय करें.

अगर आपकी किट में ऐसे नए पैरामीटर इस्तेमाल किए जाते हैं जो उस एक्सटेंशन इंस्टेंस में मौजूद नहीं थे जिससे आपने माइग्रेट किया है, तो डिप्लॉयमेंट की प्रोसेस शुरू होने पर, Firebase सीएलआई आपसे उनके बारे में पूछता है. अप-टू-डेट firestore-bigquery-export एक्सटेंशन के इस उदाहरण में, इसकी उम्मीद नहीं की जाती. हालांकि, कई किट, किट के इस्तेमाल किए गए किसी भी इवेंट ट्रिगर सोर्स के लिए, नए पैरामीटर का अनुरोध करती हैं. इस माइग्रेशन के तहत, अपडेट की गई किट में 2nd gen फ़ंक्शन इस्तेमाल किए जाते हैं. पहले, एक्सटेंशन में 1st gen फ़ंक्शन इस्तेमाल किए जाते थे. दूसरी जनरेशन में, फ़ंक्शन अपने इवेंट सोर्स के पास मौजूद होते हैं और उन्हें एक अतिरिक्त पैरामीटर के तौर पर जोड़ा जाता है. आने वाले समय में, अगर नए पैरामीटर जोड़े जाते हैं, तो सीएलआई आपको अगले डिप्लॉयमेंट के बारे में सूचना देगा.

उदाहरण:

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 तक स्ट्रीम करना

Stream Cloud Firestore to BigQuery एक्सटेंशन, रॉ चेंजलॉग टेबल (*_raw_changelog) और सबसे नए व्यू की टेबल (*_raw_latest) दोनों में डेटा सेव करता है. अगर किट और एक्सटेंशन को एक ही इवेंट डिलीवर किया जाता है, तो डुप्लीकेट कॉपी हटा दी जाएगी. इसलिए, BigQuery में किसी भी लाइन या डुप्लीकेट लाइन की मौजूदगी का इस्तेमाल करके, यह पुष्टि नहीं की जा सकती कि किट काम कर रही है या नहीं.

firebase functions:logs का इस्तेमाल करके, Firestore कलेक्शन में डेटा लिखने के कुछ ही समय बाद, फ़ंक्शन लॉग देखे जा सकते हैं. साथ ही, लॉग एंट्री में यह देखा जा सकता है कि डेटा लिखने की प्रोसेस पूरी हुई या नहीं. 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. एक्सटेंशन को अनइंस्टॉल करना

डिप्लॉय की गई फ़ंक्शन किट की पुष्टि करने के बाद, एक्सटेंशन को अनइंस्टॉल किया जा सकता है. इससे, किट और एक्सटेंशन के लिए, उसके व्यवहार की डुप्लीकेट कॉपी नहीं बनाई जा सकेगी. 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

अगर आपने Firebase सीएलआई का इस्तेमाल करते समय, एक्सटेंशन के इन दो इंस्टेंस को एक ही कोड बेस में फ़ंक्शन किट के दो इंस्टेंस पर माइग्रेट किया है और firebase deploy --project testing और firebase deploy --project production का इस्तेमाल करके डिप्लॉय किया है, तो हर डिप्लॉयमेंट से testing और production, दोनों एनवायरमेंट में दो इंस्टेंस बन जाएंगे.

इसके बजाय, एक्सटेंशन के दो इंस्टेंस को फ़ंक्शन किट के एक इंस्टेंस से बदलें. यह इंस्टेंस, firestore-bigquery-export के लिए होगा और इसे कई प्रोजेक्ट में डिप्लॉय किया जाएगा. हर प्रोजेक्ट का अपना कॉन्फ़िगरेशन होगा. इंस्टेंस के लिए आपकी कॉन्फ़िगरेशन डायरेक्ट्री, कुछ इस तरह दिखनी चाहिए:

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

testing और production पर हर डिप्लॉयमेंट, आपकी किट का एक इंस्टेंस बनाता है. साथ ही, उससे जुड़ा कॉन्फ़िगरेशन भी बनाता है. मौजूदा सीएलआई कमांड, इस सेटअप को तब तक बनाते हैं, जब तक ext:migrate या functions:kits:install के हर इन्वोकेशन में --project फ़्लैग पास किया जाता है.

उदाहरण:

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 प्रोजेक्ट में कोई इंस्टेंस बनाया है और production प्रोजेक्ट में उसी पैकेज के लिए functions:kits:install कमांड चलाया है, तो आपको testing के लिए कॉन्फ़िगर किए गए इंस्टेंस को फिर से इस्तेमाल करने या दूसरा इंस्टेंस इंस्टॉल करने का विकल्प दिखेगा.