Firebase-tools: 関数のデプロイが非常に遅い

提出してくれてありがとう！ 展開が遅いことが機能エクスペリエンスの大きな問題点であることはわかっており、さまざまな戦略を通じて解決に取り組んでいます。

@laurenzlong
Firebaseの初心者として、私は何かを台無しにしていると思いました。デプロイは常に_functions：アップロード用のfunctionsディレクトリの準備..._の部分で停止したためです。
問題が解決するまで、いくつかの追加情報（完了までに3〜5分かかるなど）を提供すると非常に便利です。

初心者として、私は自分が何か間違ったことをしていると思って、これをキャンセルすることに何度も費やしました。

問題は明らかです。 initコマンドは、巨大な「ノードモジュール」フォルダを作成しました。 私のマシンでは、22,903ファイル、2,782フォルダーです。 このコードは、そのすべてを一時フォルダーにコピーします。

これが私がしたことです：

1. ログ印刷ステートメントを使用して、コードの遅い行を特定しました。 ここにあるよ：
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

prepareFunctionsUpload.jsの26行目：
fs.copySync（options.config.path（options.config.get（'functions.source'））、tmpdir.name）;

1. そのファイルコピー呼び出しのパラメーターを印刷しました。 私のマシンでは、次のようになります。
   C：\ Users \ thoma \ StudioProjects \ LSystemAndroid \ firestorefunctions
   -> C：\ Users \ thoma \ AppData \ Local \ Temp \ fbfn_752624vejX0cv3GEJI

関数フォルダーは、CLIコマンドinitによって作成されました。 次のようになります。

• node_modules（巨大なサイズ）
• .gitignore
• index.js
• package.json
• pacakge-lock.json

CLIコマンドinitがそのnode_modulesフォルダーを作成するべきではなかったように私には思えます。 165MBの大きさです。 それをすべてのプロジェクトに追加するのは不合理に思えます。

@thomasfischersm

それは実際には問題ではありません。 次の行からわかるように、node_modulesは一時フォルダーにコピーされません： https ：//github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

firebase initは、すべてのノードモジュールを関数ソースフォルダー内にローカルにインストールする必要があります。そうしないと、関数をローカルで提供できず、トリガー抽出が機能しません（これにより、CLIはどのイベントがそれぞれをトリガーするかを理解します）それらを適切に展開できるように機能します）。

26行目以降にデバッグ印刷行を配置しました。 その行は数分かかりました。

次に、コピーされているファイルを印刷するためのフィルターを追加しました。 すべてのnode_modulesファイルが含まれていました。

次に、node_moduleファイルを除外するようにフィルターを変更しました。 展開は急速に進みました。 しかし、少し後、スクリプトがクラウド機能の正しさを評価しようとしているように見えました。 ライブラリの依存関係が欠落しているため、そのコードは失敗しました。

あなたが指しているソースコード行は後のステップのようです。 クラウドにアップロードする前に、ファイル（node_modulesを除く）がzipファイルにアーカイブされているようです。 その行は私のマシンでは遅くはないようです。

はい、その通りです。私は間違っていました。node_modulesはコピーされます。 node_modulesをtempディレクトリにコピーしないのは有効な考えだと思います。 これを少し複雑にしているのは、CLIがトリガー解析の前にtempフォルダーに「.runtimeconfig.json」を書き込み、このファイルが残りの関数のソースコードとともにアップロードされるため、書きたくなかったという事実です。このファイルを実際のソースコードディレクトリに入れます。 したがって、展開速度を向上させ、意図しない副作用が発生しないようにするための優れたソリューションがおそらくありますが、少し試してみる必要があります。 プルリクエストもお気軽にどうぞ。

私は同じ問題を抱えています。 ユーザーがfirebase-toolsがハングしていると思わないように、「ディレクトリの準備中...」の手順でさらにメッセージを出力することをお勧めします。

編集：これはUbuntuWSLにありました。 Linuxでは、「準備」フェーズはハングしません。 「関数の作成」のステップは遅くなる可能性がありますが、以前に経験したほどではありません。

この問題はお尻の本当の痛みです。 優先度を高くすべきだと思います：/

プロジェクトにFirebase関数を実装しようとしていますが、このエラーのために延期する必要がありました。
このエラーは私に多くの時間を無駄にしました。
すぐに修正されることを願っています！

この問題は大きな障害です。 主に私がfirestoreを使用しているため、アグリゲート、カウンター、プレゼンスなどはクラウド機能によってのみ適切に処理でき、毎回5分間ハングします。

@PulpoEnPatinetaこれはエラーではありません。 これは単にデプロイ時間の問題です。

@McStuffins車の電源を入れるのに5分かかる場合、それはエラーですか、それとも単に開始時間の問題ですか？

これに対する修正はありますか？ 本当にとても遅いです。

私は最初からこの問題を追跡していましたが、CDをセットアップしていて、すべての作業を行ってくれるので、問題になることはありませんでした。 また、機能するかどうかをテストするためだけに関数をデプロイすることもありません。 だから基本的には私には関係ありませんでした。

今日まで、予期しない制限に遭遇したとき：関数をデプロイできなくなったため、本番環境へのデプロイメントが1日のクォータ（12,000秒）を超えました。 さまざまなトリガー（pubsub、firestore、https）を備えた最大55個の関数があります。 扱うには多すぎますか？

ここで、アプリケーションを2日間デプロイする必要があります：rofl：：lollipop：：+ 1：：1st_place_medal：：coffin：：tada：：taco：：cactus：：dancer：：smiling_imp：

時々、私が展開しているとき、それは非常に遅いです、そしてそれから「ビルド環境のエラー」と言う警告がターミナルにあります

@srinurp上記でリンクしたプルリクエストをご覧ください。問題の一部に対処します。 また、バックエンドチームは、問題の他の部分に対処するために取り組んでいます（ただし、これは非常に複雑な作業なので、しばらくお待ちください）。

@merlinnotデプロイごとにすべての関数のコードを更新する場合を除いて、-onlyコマンドを使用して個々の関数または関数のグループをデプロイすることをお勧めします。 https://firebase.google.com/docs/cli/#partial_deploysをご覧ください。

@McStuffins 「ビルド環境のエラー」は通常、本番環境の問題を示します。その場合は、 https： //firebase.google.com/support/でサポートチケットを提出してください。進行中の本番環境の問題があるかどうかは、 Firebaseステータスダッシュボード

@laurenzlongデプロイメント間の各機能の変更（依存関係の解決を含む）を自動的に検出するようにCIを構成する必要があります。 また、すべての関数で使用するfirebase-functions 、 firebase-admin 、 lodashなどのパッケージを更新するとどうなりますか？

@merlinnotこれは非常に正当なユースケースです。 デプロイの割り当てはGoogleCloudFunctionsによって制御されます。公開されている問題のトラッカーにリクエストを提出することをお勧めします： https ：//cloud.google.com/functions/docs/support

興味のあるすべての人のために： https ：//issuetracker.google.com/issues/71385193

@laurenzlongソースをコピーするときにnode_modulesフォルダーを無視して、 npm install --productionまたはyarn install --production実行できますか？ これらのツールは、単にコピーして貼り付けるよりも高速な場合があるためです。

@horacehylee
これは重大な変更である可能性があります。 一部の人々（私自身を含む）は、相対パス（ "package-name"： "./externs/package.tgz"など）でパッケージを参照する場合があります。これは主に、プライベートリポジトリの（現在は修正されている）問題が原因です。 ツールは、これらすべてのコーナーケースを考慮に入れる必要があります。

もう1つはキャッシュです。Googleがユーザーに代わってパッケージをダウンロードする場合、内部キャッシュメカニズムを実装する必要があります。 私たち全員がコンピューター上にローカルキャッシュを持っているので（npmとyarnの両方にキャッシュメカニズムがあります）、したがってnpmのサーバーを強制終了しません;）

一部の人々はまた、外部ライブラリのいくつかの変更を単にテストしたいと思うかもしれません。 フォークを作成し、変更を加え、パッケージへの参照を一時的に変更するよりも、ファイルを変更して関数をデプロイする方がはるかに簡単です...

結論：それはうまく機能します、今のままにしておきます：+1：

@horacehylee@ merlinnot2セントありがとうございます。 https://github.com/firebase/firebase-tools/pull/578を参照してください。CLIの次のリリースでは、関数のソースフォルダーの期間がコピーされなくなります。

1Gbpsのファイバー接続上にある6つの4GHzコアマシンに5回線、1kbの機能を展開するのに数分かかるFirebaseで何ができるのかよくわかりません。

私は小便を取っているように聞こえますが、「アップロード用のディレクトリの準備」中に何が起こっているのか本当に興味があります。 誰かが実際に知っていますか？

ノードモジュールを含む関数ディレクトリをtmpディレクトリにコピーします。

次のリリースではこれに対処し、以前にコピーする必要がなくなります
展開。

2018年1月7日、午後5時5分に[email protected]は次のように書いています。

Firebaseで何ができるのか、数分でわかりません。
6つの4GHzコアマシンに5回線、1kbの機能を導入し、
1Gbpsファイバー接続。

私は小便を取っているように聞こえますが、私は本当に何に興味があります
「アップロード用のディレクトリの準備」中に進行中です。 誰かが実際に知っていますか？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
。

@mbleigh

そうだね。 なるほどね。 ワークステーションが1、2分狂ってしまうのを見るのは一種のコメディですが、次の行に「パッケージ化された関数（ 37.55kb !!!）をアップロードするために正常に」を出力させるだけです。

次のリリースを楽しみにしています。 応答するためのThx。

H。

19日目。Firebaseはまだデプロイ中です。 *ポップコーンをつかむ*

うん。

次のリリースはいつ予定されており、展開時間の何％の改善が期待できますか？

この道を進み続けるかどうかを知るためだけに。

リリースは今週行われる予定であり、「準備中
デプロイするための関数ディレクトリ」の手順を大幅に高速化します（私はしません
正確な数があります）。 デプロイの他の部分は変更されません。

2018年1月15日月曜日12:42PMに[email protected]は次のように書いています：

うん。

次のリリースはいつ予定されており、展開は何％改善されますか
何回期待すべきですか？

この道を進み続けるかどうかを知るためだけに。

—
あなたが言及されたので、あなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/firebase/firebase-tools/issues/536#issuecomment-357784792 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAD_vaj-WngS9dMj7j5Q2AesM0tNMvVks5tK7hBgaJpZM4QdF3g
。

これがリリースされました！

@mbleighこれはリリース3.17.4にありますか？

@jkossis v3.17.0

リリースノートから：

関数をデプロイする場合は、関数ディレクトリ内で「npm i --save firebase-functions @ latest 」を実行して、firebase-functionsSDKを最新のものに更新する必要があります。 これにより、機能の展開が高速化されます。

分から秒まで：お疲れ様でした！

私にとって、これはまだ数分かかります。

[email protected]と[email protected]があります。 この問題をさらにデバッグするために何ができますか？

これは、関数のみをデプロイしたときの出力です。 名前を変更しましたが、RESTエンドポイント、データベース、認証トリガーの組み合わせです。

➜  functions git:(master) ✗ firebase --version
3.17.4
➜  functions git:(master) ✗ time firebase deploy --only functions

=== Deploying to 'XXX'...

i  deploying functions
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (123.07 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: updating function 1...
i  functions: updating function 2...
i  functions: updating function 3...
i  functions: updating function 4...
i  functions: updating function 5...
i  functions: updating function 6...
✔  functions[1]: Successful update operation.
Function URL (1): https://us-central1-XXX.cloudfunctions.net/1
✔  functions[3]: Successful update operation.
✔  functions[4]: Successful update operation.
✔  functions[5]: Successful update operation.
✔  functions[6]: Successful update operation.
✔  functions[2]: Successful update operation.
Function URL (2): https://us-central1-XXX.cloudfunctions.net/2

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/XXX/overview
firebase deploy --only functions  4.59s user 1.07s system 1% cpu 6:09.26 total

@adamduren修正は、 preparing functions directory for uploading...で費やされた過度の時間に対するものでした

デプロイ自体はまだかなり長い時間がかかる可能性があります。

同じ状況でスタックします。

"firebase-admin": "^5.8.2",
"firebase-functions": "^0.8.1",

npm install -g npm@latestは私にわずかに異なる入力を与えました、そしてfirebase-cliを削除することも何かを変えるようでした。

アップデート：

さて、 npm install -g firebase-toolsを実行した後、それはついに機能しました。 https://stackoverflow.com/questions/48531993/firebase-config-variables-are-not-available-error-with-deploying-functions#comment84098334_48531993への称賛

こんにちは、同じ時点で問題が発生しています（「関数ディレクトリの準備..」）
しかし私の場合、完了するのに25/30分以上かかりました
約2.20MBの圧縮された4つのプライベート依存関係があります
圧縮ファイルとしてプライベート依存関係を含める唯一の方法であることがわかりました。
私は何か間違ったことをしていますか？ それとも、これが機能するはずですか？

2018-5-9
firebase deployまだ遅い、理由はわからない

最後のバージョンに更新しましたか？ 先週更新しましたが、デプロイには1〜3分かかります（25/30から）

次のような単純なものの場合、デプロイ時間は4分以上になります。

const functions = require('firebase-functions')

exports.test = functions.https.onRequest((req, res) => {
  res.send('Hello World')
})

i functions: updating function test...はぶら下がっている線です。
かつてはこんなに遅いことはありませんでした！

@Robula最新バージョンのfirebase-toolsにアップデートしましたか？

はい、そう思います。 firebase —versionは3.18.6を報告します。

あなたは私よりも新しいバージョンを使用しています。 3.18.6でnode_modulesフォルダーを再度転送し続けたかどうかはわかりませんが、3.18.4では、すべてが正常に実行されているようです...

最近のfirebase-toolsバージョンではデプロイ戦略に回帰はありませんでした（node_modulesフォルダーはコピーされません）が、デプロイ時間もマシンごとに、また時々異なります。 関数の最初のデプロイも、その後の更新よりも遅くなります。

preparing functions directory for uploading...ステップ中のデプロイ時間は、ローカルで実行している場合、このステップだけで7分近くかかることがわかります。 ビルドの事前デプロイ手順は、ローカルで約5秒かかります。 デプロイプロセスの他のすべてのステップは、デバッグから非常に迅速に実行されます。 デプロイはやや遅くなる可能性がありますが、作業にはAWS lambdaも使用しており、Pythonパッケージのインストールとビルドを含め、非常に大規模なラムダデプロイはこれよりもはるかに高速で、2〜2〜3分程度です。

Google Cloud Buildからデプロイする場合でも、aws lambdaでは10〜20秒であるのに対し、2〜3分かかります。 アップロードする前に、CLIが関数フォルダー全体を圧縮するのかどうかを尋ねたいだけです。

@laurenzlong 、関数がすでに並列にデプロイされているかどうか、またはこの最適化が進行中であるかどうかを詳しく説明していただけますか？

関数は常に並行して展開されてきました。 ただし、10個の関数を並行してデプロイする方が、単一の関数をデプロイするよりも遅いことに注意してください。

+1関数のデプロイは非常に遅いです。 cronジョブのチュートリアルに従って、最初のトーンである毎時ティック関数を作成しました。毎回デプロイするのに1分ほどかかります。

@laurenzlongの返信に感謝し、Firebaseでのハードワークに感謝します。

展開時間を改善するためのアクティブな計画はありますか？ 私たちはFirebaseが好きですが、デプロイ時間が遅いため、実際にはFirebaseから離れることを考えているので質問します。 約47のクラウド機能があり、デプロイには通常3〜6分かかります。 これをgit push heroku masterと比較してください。これは、同じボリュームのコードをHerokuにデプロイするのに約20〜30秒かかります。 そして、そのコードはHerokuで即座に実行されます。 Firebaseでは、デプロイ後、デプロイされた関数が実際に実行されるまでにさらに20〜30秒（ランダム）の時間を待つ必要があります（この間、新旧の関数が混在して実行されます）。

したがって、展開エクスペリエンスを比較します。

*** Heroku:

git push heroku master

20-30s later ...

All newly-deployed functions are now running in a consistent/atomic way

*** Firebase:

firebase deploy --only functions

180-360s later ...

Functions are deployed but only some of the new ones are running, some old ones are still running

20-30s later ... 

All new functions running

また、Firebaseを使用してアトミックデプロイを行うことは困難です。デプロイ後、いくつかの新しい関数（ v_n+1と呼ばれる）が古い関数v_nと一緒に実行されている期間があるためです。 したがって、メジャーアップデートを行う場合は、異なるデータ形式またはアルゴリズムを使用して実行されている新旧の関数が混在しています。 これは、すべての新しい関数がデプロイされ、新しい関数のみが実行されているか、まったくデプロイされていないHerokuデプロイよりもはるかに安全性が低くなります。

さらに、47の関数のいくつかが、次のようなエラーでデプロイに失敗することがあります。

⚠  functions[retrieveFavorites(us-central1)]: Deployment error.
Server Error. getaddrinfo ENOTFOUND cloudfunctions.googleapis.com cloudfunctions.googleapis.com:443

信頼性の高い対称ギガビットインターネットに展開しているため、問題はネットワークではありません。

したがって、HerokuのデプロイはアトミックDBトランザクション（オールオアナッシング）のようなものと考えてください。一方、Firebaseのデプロイは、結果整合性のある部分的な障害に似ています...これにより、特にバグ修正をプッシュする場合、開発オペレーションがはるかに困難になります。ページに応じて真夜中。

率直に言って、Firebaseでのデプロイエクスペリエンスは、HerokuやAWSよりも客観的に遅く、信頼性が低くなります...誤解しないでください。Firebaseが好きです。皆さんの懸命な努力に心から感謝しています。 これが攻撃のように聞こえるという意味ではありません。個人的なことではありませんが、ここでFirebaseを改善する必要があります。または、展開が非常に苦痛であるため、他の場所に移動することを検討しています。

Firebaseにご協力いただきありがとうございます。 私たちはあなたの助けに感謝します:-)。

データポイントを共有していただきありがとうございます。 特に同時に多くの関数をデプロイするために、これを改善する計画がいくつかあります（主に、関数を作成/更新するためのAPI呼び出しが行われた後のサーバー側のビルドステップを改善します）。 ただし、これらは4分の1かかるインフラストラクチャの変更であるため、しばらくお待ちいただきますようお願いいたします。

すでにこれを検討しているかもしれませんが、CI / CDパイプラインで、編集された関数を検出するスクリプトを作成し、 --onlyフラグが付いた関数のみをデプロイできます。 これにより、展開速度が劇的に向上します。 例については、このビデオを参照してください： https ://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong情報をありがとう、ローレン。 ただし、小さなクラウド機能は1つしかないため、最小限の変更を加えた後でも、デプロイには約1分かかります。 クラウド機能が1つしかないのに、そのフラグも使用します。 ここで何か問題が発生しているようです。

2019年4月の時点でまだ文字通り数分かかります-Firebaseバージョン6.6.0-私がしているのは、 https ：//firebase.google.com/docs/functions/get-startedのチュートリアルに従うことだけです。

ダウンロードして、「firebasedeploy」を実行するたびに数分かかります

数週間前は10〜15秒かかっていたのに、ここ数日はホスティングでさえ展開するのに数分かかります。 関数のデプロイもタイムアウトします。

また、Firebaseのステータスページは緑色のhttps://status.firebase.google.com/です。

なぜこれが起こるのか誰かが知っていますか？

firebase-tools 7.0.0を使用する

$ firebase deploy --only=hosting --token xxx

=== Deploying to 'xxx'...

i  deploying hosting
i  hosting[xxx]: beginning deploy...
i  hosting[xxx]: found 1959 files in public
✔  hosting[xxx]: file upload complete
i  hosting[xxx]: finalizing version...
✔  hosting[xxx]: version finalized
i  hosting[xxx]: releasing new version...
✔  hosting[xxx]: release complete
✔  hosting: Finished running postdeploy script.

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/xxx/overview
Hosting URL: https://xxx.firebaseapp.com
✨  Done in 181.75s

@ laurenzlong-

ただし、これらは4分の1かかるインフラストラクチャの変更であるため、しばらくお待ちいただきますようお願いいたします。

数四半期前の最後のメモ以降のインフラストラクチャ側の更新はありますか？ これらの変更が行われるまで、この問題を再開することは可能ですか？ 追跡が別の/関連する問題に移動しない限り、クローズは適切な状態ではないようです。

Firebase functionsは、すべてがビルド/アップロードされ、サーバー側で関数が作成/更新された後も、非常に低速です。 他の人が言っているように、これは主要な開発速度ダンパーです。

firebase --version
7.1.0

検討していただきありがとうございます！

@repentsinnerは、ビルド/デプロイ時間を改善するためのバックエンドプロジェクトをまだ進行中です（そして順調に進んでいます！）が、まだリリースされていません。

開発プロセスをスピードアップするためにエミュレーターを（ firebase emulators:startを介して）使用してみましたか？ もしそうなら、私たちはあなたのフィードバックを得たいです！

@samtsternを更新していただきありがとうございます。

エミュレーターはまだ試していません-フラッターアプリのfunctions.https.onCallとファイヤーストアのデータを使用していますが、（現時点では）アプリのテストビルドのすべてをリダイレクトしているようです私の開発ワークステーションでは、デプロイを待つよりも手間がかかります。

私はこれを調べるのを待っている時間を使うことができると思います🤨。

まだ閉じられており、まだ修正されていないこの問題への新年あけましておめでとうございます！ 🎉

おそらく、管理者またはOPは、この問題の名前を「非常に遅い展開のための関数ディレクトリの準備」に変更できます。これは、展開プロセス全体のその段階への修正のみに基づいて閉じられたように見えるためです。

次に、新しい「関数のデプロイが非常に遅い」問題を開くことができます。これは、関数のデプロイがまだ非常に遅いためです😄

デプロイ時間を改善するためにCLI側でできることはこれ以上ないため、この問題は解決されました。 ローカル開発では、エミュレーターへの投資を継続しています。開発ライフサイクルの一部としてではなく、prodにデプロイする場合にのみ、 firebase deployを実行する必要があることを願っています。

バックエンドの変更はまだ進行中です。 お分かりのように、予期しない遅延が発生しました。

明確化@samtsternに感謝します。それで、firebase / firebase-toolsに対する問題/リクエストはCLIにのみ適用できると思いますか？ バックエンドをカバーするリポジトリ/プロジェクトを探します。

ローカル開発に関しては、パブリックサイドから見ると、GoogleはFirebaseとFlutterの統合を本当に奨励しているようです。これは、非常にうまく機能しているように見えますが、実際には、このような開発時の不整合に遭遇します。 この問題を発見したときに提案されたエミュレーターをざっと見てみましたが、統合されたFirebaseとFlutterの開発ワークフローをまったくサポートしていないようで、クラウドバックエンドを介した場合ほどスムーズではありませんでした。 私はこれが最近改善されたかどうかを確認するために戻って回っていませんが、それはありそうもないようです。

@repentsinnerええ、このリポジトリはCLI作業のみを追跡します。 もちろん、私たちは入ってくるものすべてに答えようとしますが、ここで生産的なことができない場合は、問題を解決しなければならないことがよくあります。 私たちのバックエンドはオープンソースではないため、一般的にFirebaseのサポートを利用して、バグレポートやFirebaseに関する一般的な機能のリクエストを提出するように指示しています。

Flutterについては、気に入っています（https://github.com/FirebaseExtended/flutterfireを参照）が、公式のFirebaseプラットフォームではないため、私たちのように問題を完全にサポートすることはできません。ネイティブAndroid/iOS/Web。 多分それはいつか変わるでしょう、しかし今のところそれは状況です。

FlutterアプリをFirebaseEmulatorsに接続する方法について質問がある場合は、FlutterFireリポジトリで問題を開いて、私をccしてください。そうすれば、適切なFlutterの人々も参加できます。

了解しました。@samtsternの説明に感謝します。 今のところ他のプロジェクトに移っていますが、このプロジェクトに戻ったら、FlutterFireリポジトリを調べます。

エミュレーターは認証コンテキストをサポートしていないため、100％完全に役に立たないIMOです。

dotenvを使おうとしていたため、デプロイメントがフリーズしたことに気づきました。

頭を突っ込んで、これがまだ問題点であることを人々に思い出させます✌️

まだこれに遭遇している人々にとって、私が役に立ったと思ったのは、不要な肥大化をアップロードしないようにfunctions.ignoreを利用することでした。 含めるのに特に良いのは.gitだと思います：
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

開発ワークフローが面倒なので、関数を完全に削除しました。

まだこれに遭遇している人々にとって、私が役に立ったと思ったのは、不要な肥大化をアップロードしないようにfunctions.ignoreを利用することでした。 含めるのに特に良いのは.gitだと思います：

"functions": {
    "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"]
  }

これは実際にいくつかの結果をもたらしました。 現在、約65〜70％の時間で実行されています。 ありがとう！

興味深い-デフォルトでは、 functionsサブディレクトリはプロジェクトルートの下にあるため、 .gitフォルダはありません。 これが役に立った人々-あなたのディレクトリ構造はどのように見えますか？

@mbleighTrue 。 私の最善の推測は、これについて賢明であり、これらを関数ディレクトリに適用することです。

@mbleigh私は関数のみのリポジトリを持っているので、関数ディレクトリを持つのは少しばかげているように見えました。 すべてがルートにシフトダウンしました。

それは私のfirebase.jsonからの抜粋です：

  "functions": {
    "ignore": [
      "__mocks__",
      ".cache",
      ".commitlintrc.yaml",
      ".dependabot",
      ".editorconfig",
      ".eslintrc.yaml",
      ".firebase",
      ".firebaserc",
      ".git",
      ".gitattributes",
      ".github",
      ".gitignore",
      ".lintstagedrc.js",
      ".nvmrc",
      ".prettierignore",
      ".prettierrc.yaml",
      ".vscode",
      "CHANGELOG.md",
      "cloudbuild.yaml",
      "codecov.yml",
      "CONTRIBUTING.md",
      "coverage",
      "cSpell.json",
      "decisions",
      "firebase.json",
      "firestore.indexes.json",
      "jest.config.js",
      "node_modules",
      "README.md",
      "rfcs",
      "scripts",
      "src",
      "test",
      "tsconfig.json",
      "tsconfig.production.json"
    ],
    "source": "."
  },

喜んで次のように置き換えます。
`` `
{{
"include"：["lib"、 "package.json"、 "package-lock.json"]
}

FWIWこれらはグロブを受け入れるので、次のことができると思います。

{
  "exclude": ["!{lib,package.json,package-lock.json}"]
}

クラウド機能を開始したばかりで、デプロイ時間は苦痛です。

苦痛な展開時間:(

現在、Firebaseアプリには60のクラウド機能が実行されています。 最初は、クォータが原因で多くの展開の失敗が発生し始めたため、ドキュメントが示すように、それをバッチに分割しました。 現在は一貫してデプロイされていますが、デフォルトのランナーでGitHubアクションCIの一部としてデプロイするには、各バッチに最大3分かかります。 バッチはそれぞれ約6であるため、合計10バッチで、関数のデプロイ時間は約30分になります。

関数自体は、依存関係が最小限の非常に小さなコードです。 パイプラインを高速化するために他に何ができるかわからない。

それを聞いて本当に悲しいです。 別のアプローチは、複数のエントリポイント/ルートを単一の関数にバンドルすることです。 これは、関心の分離/サイズ/セキュリティからは明らかに最善ではありませんが、これはすべてのAPIエンドポイント（内部ルーターを使用する単一のエントリポイント）で行ったことであり、それ以来、多くのクォータ制限を経験していません（しかしそれらは時々起こります）。

それでも、公式ドキュメントには「Cloud Functions APIを介して関数をデプロイまたは削除するための呼び出し」について「100秒あたり80」と記載されているため、この割り当て制限は非常に低いようです。 Googleサポートはこの制限をさらに引き上げることができなかったと思いますか？

それでも、公式ドキュメントには「Cloud Functions APIを介して関数をデプロイまたは削除するための呼び出し」について「100秒あたり80」と記載されているため、この割り当て制限は非常に低いようです。 Googleサポートはこの制限をさらに引き上げることができなかったと思いますか？

@dinvlad API制限を引き上げることについて、販売とサポートの両方に問い合わせていました。GCPコンソールの割り当てセクションで明示的に無効化/グレー表示されています。 最終的には、「その割り当ては変更されない」と通知されたハングアウトでGoogleのエンジニアを雇うことができました。

次のリリースでは、標準の無視リストに.gitを追加しました。
https://github.com/firebase/firebase-tools/pull/2395

これにより、一部のリリースがスピードアップするはずです。 もちろん、Cloud Functionsバックエンドのレイテンシについて私たち（Firebase CLIチーム）ができることはあまりありません。

関数を更新しないときは、必ずfirebase deploy --only hostingを実行してください

ここでは、関連する機能を1つの機能にグループ化しているため、「機能の個々の粒度ごとに1つの機能」ではなく、「機能領域ごとに1つの機能」のように見えます。

デプロイメントのパフォーマンス特性は、1つの機能に含まれるもののアーキテクチャーを強力に推進しています。

この問題はいつ、なぜ解決されましたか。 2017年11月にオープンしましたが、当時と同じくらい問題があるようです。 ここに「クローズ」への参照が表示されないので、なぜクローズされたのか知りたいと思います。

私は文句を言っているのではなく、ただ疑問に思っています。 作業中だと思いますが、進捗状況を知っておくとよいでしょう。

@chriscurnowは、CLIの問題としてエンドユーザーに表示されますが（https://github.comの@samtsternによる）、本当の原因はCLIツールではなく（クローズドソース）サーバー側にあると思われるため、クローズされました。 / firebase / firebase-tools / issues / 536＃issuecomment-572830647）。

残念ながら、バックエンドに適したパブリックトラッカーがないため、ここで更新を取得します:(

どうすればグーグルのこのバグを開いてバックエンドで修正できますか？
ばかばかしいほど遅い

たとえば、これほど時間がかかる場合は、Firebase関数を使用する意味さえあります。

やあみんな、多分私達全員がこの問題をグーグルに報告することができて、多分彼らは聞くだろうか？
https://firebase.google.com/support/troubleshooter/contact

グーグルの何かを重要なものに使おうとするたびに、彼らは存在する中で最も消費者に優しい会社の1つであることを思い出しますが、ちょっと、私たちは試すことができます。

@RenFontesケース00075974を提出しました：Firebase関数のデプロイは非常に遅いため、Firebaseサポートでは使用できません。 私は彼らが戻ってきたものでこのメッセージを更新します。

特定の機能を展開することが可能です。 CLIに各関数の「チェックサムトラッカー」を設定し、変更された関数のみをデプロイすることはできませんでしたか（また、使用するすべてのものを追跡します：変数、パッケージなど）？

@SrBrahmaは確かですが、単一の関数のみをデプロイした場合でも、問題は引き続き存在します（たとえば、単一関数のデプロイはタイムアウトが原因で失敗する可能性があります）。

バッチ機能のデプロイを管理するためにユーザーに負担をかける必要はありません。多くの場合、機能の更新はアトミックに必要であるため、分割/バッチ処理することはできません。

回避策の提案に感謝しますが、ここで本当に必要なのは、GoogleのSLAとそれへの準拠です。

Firebaseが機能することがあるのは事実ですか？（おそらく頻繁に）パフォーマンスが低下します..本当に遅いです..Rustをサポートする必要があります..行きますか？ Nodeよりもはるかに高速ですか？

グーグルがグーグル機能の展開時間を改善するのをまだ待っていますか？
PWAからSSRに移行すると、デプロイごとにさらに7分待つ必要がありました😞