您可以使用 Firebase CLI 指令，或在函式原始碼中設定執行階段選項，來部署、刪除及修改函式。
部署函式
如要部署函式，請執行下列 Firebase CLI 指令：
firebase deploy --only functions
根據預設，Firebase CLI 會同時部署來源中的所有函式。如果專案包含超過 5 個函式，建議您使用 --only 標記搭配特定函式名稱，只部署您編輯過的函式。部署特定函式可加快部署程序，並避免觸及部署配額。例如：
firebase deploy --only functions:addMessage,functions:makeUppercase
部署大量函式時，您可能會超過標準配額，並收到 HTTP 429 或 500 錯誤訊息。如要解決這個問題，請將函式分組部署，每組最多 10 個。
如需可用指令的完整清單，請參閱 Firebase CLI 參考資料。
根據預設，Firebase CLI 會在 functions/ 資料夾中尋找原始程式碼。您也可以視需要在程式碼集或多組檔案中整理函式。
刪除函式
您可以透過下列方式刪除先前部署的函式：
- 在 Firebase CLI 中使用
functions:delete明確指定 - 在 Google Cloud 控制台中明確設定。
- 隱含：在部署前從來源中移除函式。
所有刪除作業都會在移除正式版函式前，先提示您進行確認。
Firebase CLI 中的明確函式刪除作業支援多個引數和函式群組，並可讓您指定在特定區域執行的函式。您也可以覆寫確認提示。
# Delete all functions that match the specified name in all regions. firebase functions:delete myFunction
# Delete a specified function running in a specific region. firebase functions:delete myFunction --region us-east-1
# Delete more than one function firebase functions:delete myFunction myOtherFunction
# Delete a specified functions group. firebase functions:delete groupA
# Bypass the confirmation prompt. firebase functions:delete myFunction --force
透過隱含函式刪除功能，firebase deploy 會剖析來源，並從正式版中移除已從檔案中移除的任何函式。
修改函式的名稱、區域或觸發條件
如果您要為處理正式版流量的函式重新命名或變更區域或觸發條件，請按照本節中的步驟操作，避免在修改期間遺失事件。在您按照這些步驟操作之前，請先確認函式是否冪等，因為在變更期間，函式的新舊版本都會同時執行。
重新命名函式
如要重新命名函式，請在來源中建立新版本的函式並重新命名，然後執行兩個個別的部署指令。第一個指令會部署新命名的函式，第二個指令則會移除先前部署的版本。舉例來說，如果您有一個名為 webhook 的 Node.js 函式，而您想將其變更為 webhookNew，請按照下列方式修改程式碼：
// before
const functions = require('firebase-functions/v1');
exports.webhook = functions.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions/v1');
exports.webhookNew = functions.https.onRequest((req, res) => {
res.send("Hello");
});
接著，請執行下列指令來部署新函式：
# Deploy new function called webhookNew firebase deploy --only functions:webhookNew # Wait until deployment is done; now both webhookNew and webhook are running # Delete webhook firebase functions:delete webhook
變更函式的區域
如果您要變更處理實際流量的函式指定的區域，請依序執行下列步驟，以免事件遺失：
- 重新命名函式，並視需要變更其區域。
- 部署重新命名的函式，這會導致在兩組區域中暫時執行相同的程式碼。
- 刪除先前的函式。
舉例來說，如果您有一個名為 webhook 的函式，目前位於 us-central1 的預設函式區域，而您想要將該函式遷移至 asia-northeast1，則必須先修改原始碼，將函式重新命名並修訂區域。
// before
const functions = require('firebase-functions/v1');
exports.webhook = functions
.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions/v1');
exports.webhookAsia = functions
.region('asia-northeast1')
.https.onRequest((req, res) => {
res.send("Hello");
});
接著執行下列指令來部署：
firebase deploy --only functions:webhookAsia
目前有兩個相同的函式正在執行：webhook 在 us-central1 中執行，webhookAsia 在 asia-northeast1 中執行。
然後刪除 webhook：
firebase functions:delete webhook
現在只有一個函式 - webhookAsia，會在 asia-northeast1 中執行。
變更函式的觸發類型
隨著 Cloud Functions for Firebase 部署作業的進行，您可能會基於各種原因而需要變更函式的觸發事件類型。舉例來說，您可能想要將某種 Firebase Realtime Database 或 Cloud Firestore 事件類型變更為另一種類型。
您無法只變更原始碼並執行 firebase deploy，就變更函式的事件類型。為避免發生錯誤，請按照以下程序變更函式的觸發事件類型：
- 修改原始碼，納入使用所需觸發類型的新函式。
- 部署函式，這會導致暫時同時執行舊函式和新函式。
- 使用 Firebase CLI 明確從實際環境中刪除舊函式。
舉例來說，如果您有一個名為 objectChanged 的 Node.js 函式，且該函式使用舊版 onChange 事件類型，而您想將其變更為 onFinalize，請先重新命名該函式，然後編輯該函式，以便使用 onFinalize 事件類型。
// before
const functions = require('firebase-functions/v1');
exports.objectChanged = functions.storage.object().onChange((object) => {
return console.log('File name is: ', object.name);
});
// after
const functions = require('firebase-functions/v1');
exports.objectFinalized = functions.storage.object().onFinalize((object) => {
return console.log('File name is: ', object.name);
});
接著，請先執行下列指令建立新函式，再刪除舊函式：
# Create new function objectFinalized firebase deploy --only functions:objectFinalized # Wait until deployment is done; now both objectChanged and objectFinalized are running # Delete objectChanged firebase functions:delete objectChanged
設定執行階段選項
Cloud Functions for Firebase 可讓您選取執行階段選項，例如 Node.js 執行階段版本和個別函式逾時、記憶體配置，以及最小/最大函式例項。
最佳做法是在函式程式碼內的設定物件上設定這些選項 (Node.js 版本除外)。這個 RuntimeOptions 物件是函式執行階段選項的資訊來源，並會覆寫透過任何其他方法 (例如透過 Google Cloud 控制台或 gcloud CLI) 設定的選項。
如果開發工作流程涉及透過 Google Cloud 主控台或 gcloud CLI 手動設定執行階段選項，且您不希望這些值在每次部署時都遭到覆寫，請將 preserveExternalChanges 選項設為 true。將這個選項設為 true 後，Firebase 會將程式碼中設定的執行階段選項，與目前部署的函式版本設定合併，並以以下優先順序進行：
- 在函式程式碼中設定選項：覆寫外部變更。
- 在函式程式碼中將選項設為
RESET_VALUE：使用預設值覆寫外部變更。 - 選項未在函式程式碼中設定，而是在目前已部署的函式中設定：請使用已部署函式中指定的選項。
在大多數情況下，不建議使用 preserveExternalChanges: true 選項，因為您的程式碼將不再是函式執行階段選項的完整來源。如果您使用了這個功能，請查看 Google Cloud 控制台或使用 gcloud CLI 查看函式的完整設定。
設定 Node.js 版本
Cloud Functions 適用的 Firebase SDK 可讓您選取 Node.js 執行階段。您可以選擇在與下列支援的 Node.js 版本相對應的執行階段環境中，專門執行專案中的所有函式：
- Node.js 20 (預先發布版)
- Node.js 18
- Node.js 16
- Node.js 14
如要設定 Node.js 版本，請按照下列步驟操作：
您可以在初始化期間，在 functions/ 目錄中建立的 package.json 檔案中，設定 engines 欄位的版本。例如，如要只使用 18 版，請在 package.json 中編輯這行：
"engines": {"node": "18"}
如果您使用 Yarn 套件管理工具，或是對 engines 欄位有其他特定需求，可以改為在 firebase.json 中為 Cloud Functions 的 Firebase SDK 設定執行階段：
{
"functions": {
"runtime": "nodejs18" // or nodejs14, nodejs16 or nodejs20
}
}
CLI 會優先使用 firebase.json 中設定的值，而非您在 package.json 中個別設定的任何值或範圍。
升級 Node.js 執行階段
如要升級 Node.js 執行階段，請按照下列步驟操作：
- 請確認專案採用 Blaze 定價方案。
- 請確認您使用的是 Firebase CLI 11.18.0 以上版本。
- 在初始化期間，在
functions/目錄中建立的package.json檔案中變更engines值。舉例來說，如果您要從 16 版升級至 18 版，項目應如下所示："engines": {"node": "18"} - 您可以選擇使用 Firebase Local Emulator Suite 測試變更。
- 重新部署所有函式。
控制資源調度行為
根據預設，Cloud Functions for Firebase 會依據傳入要求的數量調整執行中的例項數量，在流量減少時，可能會縮減為零個例項。不過，如果應用程式需要縮短延遲時間，而您希望限制冷啟動次數，則可變更這項預設行為。僅須指定要保持暖機狀態、準備好處理要求的最低容器執行個體數量即可。
同樣地，您也可以設定數量上限，限制在回應傳入要求時，執行個體的調度作業。您可以使用這項設定來控管費用，或限制備用服務 (例如資料庫) 的連線數量。
減少冷啟動的次數
如要在原始碼中為函式設定最少的執行個體數量，請使用 runWith 方法。這個方法會接受符合 RuntimeOptions 介面的 JSON 物件，該介面會定義 minInstances 的值。舉例來說，這個函式會將最少 5 個執行個體設為保持暖機狀態：
exports.getAutocompleteResponse = functions
.runWith({
// Keep 5 instances warm for this latency-critical function
minInstances: 5,
})
.https.onCall((data, context) => {
// Autocomplete a user's search term
});
設定 minInstances 的值時，請考量以下幾點：
- 如果 Cloud Functions for Firebase 將應用程式縮放至超過
minInstances的設定，每個超出該門檻的執行個體都會發生冷啟動。 - 冷啟動對流量波動劇烈的應用程式影響最大。如果應用程式流量呈現尖峰現象，且您設定的
minInstances值足夠高，以便在流量增加時減少冷啟動，您就會發現延遲時間大幅縮短。對於流量穩定的應用程式，冷啟動不太可能嚴重影響效能。 設定最少的執行個體可能適合實際工作環境，但通常應避免在測試環境中設定。如要在測試專案中縮放至零，但仍要減少正式專案中的冷啟動次數，您可以根據
FIREBASE_CONFIG環境變數設定minInstances：// Get Firebase project id from `FIREBASE_CONFIG` environment variable const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId; exports.renderProfilePage = functions .runWith({ // Keep 5 instances warm for this latency-critical function // in production only. Default to 0 for test projects. minInstances: envProjectId === "my-production-project" ? 5 : 0, }) .https.onRequest((req, res) => { // render some html });
限制函式的執行個體數量上限
如要在函式原始碼中設定上限執行個體，請使用 runWith 方法。這個方法會接受符合 RuntimeOptions 介面的 JSON 物件，該介面會定義 maxInstances 的值。舉例來說，這個函式會設定 100 個執行個體的限制，以免讓假設的舊版資料庫不堪負荷：
exports.mirrorOrdersToLegacyDatabase = functions
.runWith({
// Legacy database only supports 100 simultaneous connections
maxInstances: 100,
})
.firestore.document("orders/{orderId}")
.onWrite((change, context) => {
// Connect to legacy database
});
如果 HTTP 函式擴充至 maxInstances 限制，新要求會排入佇列 30 秒，如果屆時沒有可用的執行個體，系統會拒絕要求並傳回 429 Too Many Requests 回應代碼。
如要進一步瞭解使用最大執行個體設定的最佳做法，請參閱這些使用 maxInstances 的最佳做法。
設定逾時和記憶體分配
在某些情況下，您的函式可能需要長的逾時值或大量的記憶體配置。您可以在 Google Cloud 控制台或函式原始碼中設定這些值 (僅限 Firebase)。
如要在函式原始碼中設定記憶體配置和逾時時間，請使用 Firebase SDK for Cloud Functions 2.0.0 中引進的 runWith 參數。這個執行階段選項會接受符合 RuntimeOptions 介面的 JSON 物件，該介面會定義 timeoutSeconds 和 memory 的值。舉例來說，這個儲存空間函式會使用 1 GB 記憶體，並在 300 秒後逾時：
exports.convertLargeFile = functions
.runWith({
// Ensure the function has enough memory and time
// to process large files
timeoutSeconds: 300,
memory: "1GB",
})
.storage.object()
.onFinalize((object) => {
// Do some complicated things that take a lot of memory and time
});
timeoutSeconds 的最大值為 540，即 9 分鐘。函式可使用的記憶體量會對應到為函式分配的 CPU，如 memory 有效值清單所示：
128MB- 200 MHz256MB- 400 MHz512MB- 800MHz1GB— 1.4 GHz2GB— 2.4 GHz4GB— 4.8 GHz8GB— 4.8 GHz
如要在 Google Cloud 主控台中設定記憶體分配和逾時時間，請按照下列步驟操作：
- 在 Google Google Cloud 控制台中，從左側選單中選取「Cloud Functions」。
- 在函式清單中按一下函式名稱，即可選取函式。
- 按一下頂端選單中的「編輯」圖示。
- 從「Memory allocated」下拉式選單中選取記憶體配置。
- 按一下「更多」顯示進階選項，然後在「逾時」文字方塊中輸入秒數。
- 按一下「儲存」即可更新函式。