Firebase-tools: Déploiement des fonctions extrêmement lent

Merci pour le dépôt ! Nous savons que le déploiement lent est un problème majeur pour l'expérience des fonctions, et c'est quelque chose que nous nous efforçons de résoudre grâce à diverses stratégies.

@laurenzlong
En tant que débutant dans Firebase, j'ai pensé à première vue que je gâchais quelque chose, car le déploiement s'arrêtait toujours à la partie _functions: préparation du répertoire des fonctions pour le téléchargement..._.
Donner quelques informations supplémentaires (comme : cela prend 3 à 5 minutes) serait vraiment bien, jusqu'à ce que le problème soit résolu.

En tant que débutant, j'ai passé plusieurs fois à annuler cela en pensant que je faisais quelque chose de mal.

Le problème est assez évident. La commande init a créé un dossier 'node modules' qui est énorme. Sur ma machine, c'est : 22 903 fichiers, 2 782 dossiers. Le code copie tout cela dans un dossier temporaire.

Voici ce que j'ai fait:

1. À l'aide des instructions d'impression de journal, j'ai identifié la ligne de code lente. C'est ici:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

Ligne 26 dans prepareFunctionsUpload.js :
fs.copySync(options.config.path(options.config.get('functions.source')), tmpdir.name);

1. J'ai imprimé les paramètres pour cet appel de copie de fichier. Sur ma machine c'est :
   C:\Users\thoma\StudioProjects\LSystemAndroid\firestorefunctions
   -> C:\Users\thoma\AppData\Local\Temp\fbfn_752624vejX0cv3GEJI

Le dossier de fonctions a été créé par la commande CLI init. Il ressemble à ceci :

• node_modules (taille énorme)
• .gitignore
• index.js
• package.json
• pacakge-lock.json

Il me semble que la commande CLI init n'aurait PAS dû créer ce dossier node_modules. Il fait 165 Mo de large. Cela semble déraisonnable d'ajouter à chaque projet.

@thomasfischersm

Ce n'est en fait pas le problème. Le node_modules n'est pas copié dans le dossier temporaire, comme vous pouvez le voir sur cette ligne ici : https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

Il est nécessaire pour firebase init d'installer tous les modules de nœud localement à l'intérieur du dossier source des fonctions, sinon le service local des fonctions ne fonctionnera pas et l'extraction du déclencheur ne fonctionnera pas (c'est ainsi que la CLI comprend quels événements déclenchent chaque fonctionner afin qu'il puisse les déployer correctement).

J'ai mis une ligne d'impression de débogage avant la ligne 26 et après. Cette ligne a pris quelques minutes.

Ensuite, j'ai ajouté un filtre pour imprimer quels fichiers étaient copiés. Il comprenait tous les fichiers node_modules.

Ensuite, j'ai changé le filtre pour exclure les fichiers node_module. Le déploiement a progressé rapidement maintenant. Cependant, un peu plus tard, il semblait que le script essayait d'évaluer l'exactitude des fonctions du cloud. Ce code a échoué car il manquait les dépendances de la bibliothèque.

La ligne de code source que vous pointez semble être une étape ultérieure. Il semble que les fichiers (moins les node_modules) soient archivés dans un fichier zip avant de les télécharger sur le cloud. Cette ligne ne semble pas fonctionner lentement sur ma machine.

Oui, vous avez raison, je me suis trompé, node_modules est copié. Je pense que c'est une idée valable de ne pas copier node_modules dans le répertoire temp. Ce qui complique un peu cela, c'est le fait que la CLI écrit un ".runtimeconfig.json" dans le dossier temporaire avant l'analyse du déclencheur, et ce fichier est téléchargé avec le reste du code source des fonctions, et nous ne voulions pas écrire ce fichier dans le répertoire du code source réel. Il existe donc probablement une bonne solution qui améliore à la fois la vitesse de déploiement et garantit qu'il n'y a pas d'effets secondaires involontaires, mais je devrais jouer un peu avec. Vous pouvez également vous sentir libre de faire une pull request.

J'ai le même problème. Il peut être judicieux d'imprimer plus de messages pendant les étapes de "répertoire de préparation..." afin que l'utilisateur ne pense pas que firebase-tools est suspendu.

Edit : C'était sur Ubuntu WSL. Sous Linux, la phase de "préparation" ne se bloque pas. L'étape de "création d'une fonction" peut être lente, mais pas autant que ce que j'ai vécu plus tôt.

Ce problème est un véritable casse-tête. Je pense qu'il faut lui donner la priorité :/

J'essaie d'implémenter des fonctions Firebase dans mon projet et à cause de cette erreur, j'ai dû la reporter.
Cette erreur m'a fait perdre beaucoup de temps.
j'espère que ce sera bientôt réparé !

Ce problème est un obstacle majeur. Principalement parce que j'utilise firestore et que dans ce domaine, les agrégats, les compteurs et la présence ne peuvent être gérés correctement que par les fonctions cloud et que cela ne dure que 5 minutes à chaque fois.

@PulpoEnPatineta Ce n'est pas une erreur. Il s'agit simplement d'un problème de temps de déploiement.

@McStuffins Si votre voiture met cinq minutes à s'allumer, est-ce une erreur ou simplement un problème d'heure de démarrage ?

y a-t-il un correctif pour cela? C'est vraiment extrêmement lent.

J'ai suivi ce problème depuis le début, mais cela n'a jamais été un problème pour moi depuis que j'ai un CD configuré et qu'il fait tout le travail pour moi. Je ne déploie jamais non plus de fonctions juste pour tester si elles fonctionnent. Donc, au fond, ça m'était égal.

Jusqu'à aujourd'hui, où je suis tombé sur une limitation inattendue : je ne peux plus déployer mes fonctions, car le déploiement en production dépasse le quota journalier (12 000 secondes). J'ai ~ 55 fonctions avec divers déclencheurs (pubsub, firestore, https). Est-ce trop difficile à gérer ?

Maintenant je dois déployer mon application pendant deux jours :rofl: :lollipop: :+1: :1st_place_medal: :coffin: :tada: :taco: :cactus: :dancer: :smiling_imp:

Parfois, lorsque je déploie, c'est extrêmement lent, puis il y a un avertissement dans le terminal qui dit "Erreur dans l'environnement de construction"

@srinurp Veuillez consulter la demande d'extraction que j'ai liée ci-dessus, elle résoudra une partie du problème. Et l'équipe backend travaille pour résoudre d'autres parties du problème (mais c'est une entreprise très compliquée, nous apprécions donc votre patience.)

@merlinnot Sauf si vous mettez à jour le code de toutes vos fonctions à chaque déploiement, je vous recommande d'utiliser la commande --only pour déployer des fonctions individuelles ou des groupes de fonctions. Voir https://firebase.google.com/docs/cli/#partial_deploys.

@McStuffins "Erreur dans l'environnement de construction" indique généralement un problème de production, dans ce cas, veuillez déposer un ticket d'assistance sur https://firebase.google.com/support/ , vous pouvez voir s'il y a des problèmes de production en cours en visitant le Tableau de bord d'état Firebase

@laurenzlong Je devrais configurer mon CI pour détecter automatiquement les changements dans chaque fonction entre les déploiements (y compris la résolution des dépendances). Et que se passe-t-il si je mets à jour des packages comme firebase-functions , firebase-admin , lodash etc., que j'utilise dans chaque fonction ?

@merlinnot C'est un cas d'utilisation très légitime. Les quotas de déploiement sont contrôlés par Google Cloud Functions, je vous recommande de déposer une demande sur leur outil de suivi des problèmes publics : https://cloud.google.com/functions/docs/support

Pour toutes les personnes intéressées : https://issuetracker.google.com/issues/71385193

@laurenzlong Le dossier node_modules pourrait-il être ignoré lors de la copie de la source, puis faire un npm install --production ou yarn install --production ? Comme ces outils peuvent être plus rapides que de simplement copier et coller.

@horacehylee
Cela pourrait être un changement de rupture. Certaines personnes (moi y compris) peuvent toujours référencer les packages par un chemin relatif (comme "package-name": "./externs/package.tgz"), principalement à cause du problème ( maintenant résolu ) avec les référentiels privés. L'outil devrait prendre en compte tous ces cas particuliers.

L'autre chose est la mise en cache : si Google devait télécharger des packages en votre nom, ils devraient implémenter un mécanisme de mise en cache interne. Nous avons tous des caches locaux sur nos ordinateurs (npm et yarn ont des mécanismes de mise en cache), donc nous ne tuons pas les serveurs de npm ;)

Certaines personnes peuvent également vouloir simplement tester certaines modifications dans des bibliothèques externes. Il est beaucoup plus facile de simplement modifier un fichier et de déployer la fonction que de créer un fork, d'apporter des modifications, de modifier temporairement une référence au package, ...

Conclusion : ça marche très bien, laissez-le tel quel :+1 :

@horacehylee @merlinnot Merci pour les 2 centimes. Veuillez consulter https://github.com/firebase/firebase-tools/pull/578 , la prochaine version de la CLI ne copiera plus la période du dossier source des fonctions.

Je ne sais vraiment pas ce que Firebase pourrait faire qui prend MINUTES pour déployer une fonction 5 lignes, 1 Ko, sur une machine à six cœurs 4 GHz, assise sur une connexion fibre 1 Gbps.

Je sais que j'ai l'air de pisser dessus, mais je suis vraiment curieux de savoir ce qui se passe pendant la "préparation du répertoire pour le téléchargement". Quelqu'un sait-il réellement ?

Copiez votre répertoire de fonctions, y compris les modules de nœud, dans un répertoire tmp.

Notre prochaine version réglera ce problème et n'aura plus besoin de copier avant
déploiement.

Le dimanche 7 janvier 2018 à 17 h 05, hmexx [email protected] a écrit :

Je ne sais vraiment pas ce que Firebase pourrait faire qui prend MINUTES à
déployer une fonction 5 lignes, 1 Ko, sur une machine à six cœurs 4 GHz, assise sur un
Connexion fibre 1Gbps.

Je sais que j'ai l'air de pisser dessus, mais je suis vraiment curieux de savoir quoi
se passe pendant la "préparation du répertoire pour le téléchargement". Quelqu'un sait-il réellement ?

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

@mbleigh

Ah d'accord. Ceci explique cela. C'est un peu comique de voir un poste de travail devenir fou pendant une minute ou deux, seulement pour que la ligne suivante imprime "fonctions packagées ( 37,55 Ko !!!) avec succès pour le téléchargement" lol

Attendez-vous à la prochaine version. Merci d'avoir répondu.

H

Jour 19. Firebase est toujours en cours de déploiement. *attrape du pop-corn*

Ouais.

Quand la prochaine version est-elle prévue et à quel pourcentage d'amélioration des temps de déploiement devons-nous nous attendre ?

Juste pour savoir s'il faut continuer dans cette voie.

La sortie devrait avoir lieu cette semaine, et vous pouvez vous attendre à la "Préparation
répertoire de fonctions pour le déploiement" étape pour aller beaucoup plus vite (je ne
avoir des chiffres exacts). Les autres parties du déploiement resteront inchangées.

Le lundi 15 janvier 2018 à 12h42, hmexx [email protected] a écrit :

Ouais.

Quand est prévue la prochaine version et quel pourcentage d'amélioration du déploiement
fois devons-nous nous attendre?

Juste pour savoir s'il faut continuer dans cette voie.

—
Vous recevez ceci parce que vous avez été mentionné.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-357784792 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAD_vaj-WngS9dMj7j5Q2AesM0tNMvVks5tK7hBgaJpZM4QdF3g
.

C'est sorti !

@mbleigh Est-ce dans la version 3.17.4 ?

@jkossi v3.17.0

À partir des notes de version :

Si vous déployez des fonctions, vous devez mettre à jour le SDK firebase-functions au plus tard en exécutant « npm i --save firebase-functions@latest » dans votre répertoire de fonctions. Cela permet un déploiement plus rapide des fonctions.

de minutes en secondes : bravo !

Pour moi, cela prend encore quelques minutes.

J'ai [email protected] et [email protected] . Que puis-je faire pour aider à déboguer davantage ce problème ?

Voici la sortie chronométrée du déploiement de fonctions uniquement. J'ai changé les noms, mais il s'agit d'une combinaison de points de terminaison REST, de déclencheurs de base de données et d'authentification.

➜  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 le correctif concernait un temps excessif passé à preparing functions directory for uploading...

Les déploiements eux-mêmes peuvent encore prendre un temps assez long.

pile dans la même situation :

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

npm install -g npm@latest m'a donné une entrée légèrement différente, et la suppression firebase-cli a également semblé changer quelque chose.

mettre à jour:

d'accord, après avoir exécuté npm install -g firebase-tools , cela a finalement fonctionné. Bravo à https://stackoverflow.com/questions/48531993/firebase-config-variables-are-not-available-error-with-deploying-functions#comment84098334_48531993

Salut, j'ai un problème au même point ("préparation du répertoire des fonctions ..")
mais dans mon cas, il a fallu plus de 25/30 minutes pour terminer
J'ai 4 dépendances privées qui pèsent environ 2,20 Mo compressées
J'ai trouvé que c'était le seul moyen d'inclure des dépendances privées, sous forme de fichiers compressés.
Est-ce que je fais quelque chose de mal? ou est-ce la façon dont est censé fonctionner?

2018-5-9
firebase deploy toujours lent, je ne sais pas pourquoi

Avez-vous mis à jour la dernière version ? J'ai mis à jour la semaine dernière et maintenant mon déploiement prend 1 à 3 minutes (à partir du 25/30)

Je vois des temps de déploiement de plus de 4 minutes pour quelque chose d'aussi simple que :

const functions = require('firebase-functions')

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

i functions: updating function test... est la ligne qui se bloque.
Il n'a jamais été aussi lent !

@Robula Avez-vous mis à jour la dernière version de firebase-tools ?

Oui je crois bien. Rapports firebase —version 3.18.6.

tu es sur une version plus récente que moi. Je ne sais pas s'ils ont peut-être continué à transférer à nouveau le dossier node_modules en 3.18.6, mais pour le moment avec 3.18.4, tout semble bien fonctionner ...

Il n'y a pas eu de régression dans la stratégie de déploiement dans les versions récentes de firebase-tools (le dossier node_modules n'est pas copié), mais le temps de déploiement varie également d'une machine à l'autre et de temps en temps. Le déploiement initial d'une fonction est également plus lent que les mises à jour ultérieures.

Je vois que les temps de déploiement pendant l'étape preparing functions directory for uploading... prennent près de 7 minutes sur cette étape seule lors de l'exécution locale. L'étape de pré-déploiement pour la construction prend environ 5 secondes localement. Toutes les autres étapes du processus de déploiement sont exécutées à partir du débogage très rapidement. Je comprends que le déploiement peut être un peu lent, mais j'utilise également AWS lambda pour le travail et les déploiements lambda très volumineux sont beaucoup plus rapides que cela, de l'ordre de 2 deux 3 minutes, y compris les installations et les versions de packages python.

Même le déploiement à partir de google cloud build prend 2 à 3 minutes, contre 10 à 20 secondes dans aws lambda. Je veux juste demander si le cli comprime tout le dossier de fonctions avant de le télécharger ?

@laurenzlong , pourriez-vous préciser si les fonctions sont déjà déployées en parallèle, ou si cette optimisation est en cours ?

Les fonctions ont toujours été déployées en parallèle. Cependant, veuillez noter que le déploiement de 10 fonctions en parallèle est toujours plus lent que le déploiement d'une seule fonction.

+1 Que le déploiement d'une fonction est extrêmement lent. J'ai suivi le didacticiel du travail cron pour créer la fonction horaire, ma toute première tonalité, et le déploiement prend environ une minute à chaque fois.

@laurenzlong merci beaucoup d'avoir répondu et merci pour votre travail acharné sur Firebase !

Existe-t-il des plans actifs pour améliorer le temps de déploiement ? Je demande parce que même si nous aimons Firebase, nous envisageons en fait de nous en éloigner en raison des temps de déploiement lents. Nous avons environ 47 fonctions cloud et cela prend régulièrement 3 à 6 minutes pour nos déploiements. Comparez cela avec git push heroku master qui prendrait environ 20 à 30 secondes pour déployer le même volume de code sur Heroku. Et ce code serait alors exécuté instantanément sur Heroku. Avec Firebase, nous devons attendre encore 20 à 30 secondes (aléatoires) après le déploiement avant que les fonctions déployées ne s'exécutent réellement (pendant ce temps, un mélange de nouvelles et d'anciennes fonctions s'exécutent).

Alors comparez l'expérience de déploiement :

*** 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

Il est également difficile de faire des déploiements atomiques avec Firebase car après le déploiement, il y a une période de temps pendant laquelle certaines des nouvelles fonctions, appelez-les v_n+1 s'exécutent parallèlement à certaines des anciennes fonctions v_n . Ainsi, si vous effectuez une mise à jour majeure, vous avez un mélange de nouvelles et d'anciennes fonctions exécutées éventuellement en utilisant différents formats de données ou algorithmes. C'est beaucoup moins sûr qu'un déploiement Heroku où toutes les nouvelles fonctions sont déployées et seules les nouvelles fonctions sont en cours d'exécution ou aucune ne se déploie.

De plus, certaines de nos 47 fonctions échouent parfois à se déployer avec des erreurs telles que

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

Nous déployons sur Internet Gigabit symétrique hautement fiable, donc le problème n'est pas notre réseau.

Pensez donc aux déploiements d'Heroku comme à une transaction de base de données atomique (tout ou rien) alors que les déploiements de Firebase ressemblent davantage à des échecs partiels ... Cela rend les opérations de développement beaucoup plus difficiles, surtout si vous poussez un correctif de bogue dans au milieu de la nuit en réponse à une page.

Soyons francs, l'expérience de déploiement sur Firebase est objectivement plus lente et moins fiable que sur Heroku ou AWS... Ne vous méprenez pas, nous aimons Firebase et nous apprécions vraiment tout votre travail acharné. Je ne veux pas dire que cela ressemble à une attaque, ce n'est rien de personnel, mais nous avons besoin de Firebase pour faire mieux ici ou nous pensons aller ailleurs car les déploiements sont tout simplement trop pénibles.

Merci encore pour votre travail acharné sur Firebase. Nous apprécions votre aide :-).

Merci d'avoir partagé votre point de données ! Nous prévoyons d'améliorer cela, en particulier pour déployer de nombreuses fonctions en même temps (principalement en améliorant l'étape de construction côté serveur après l'appel de l'API pour créer/mettre à jour la fonction). Cependant, ce sont des changements d'infrastructure qui prendront du temps, nous apprécions donc vraiment votre patience en attendant.

Vous avez peut-être déjà envisagé cela, mais vous pouvez créer un script dans votre pipeline CI/CD qui détecte les fonctions qui ont été modifiées et ne déploie que celles-ci avec l'indicateur --only . Cela améliorera considérablement votre vitesse de déploiement. Voir cette vidéo pour un exemple : https://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong Merci pour l'info, Lauren. Cependant, je n'ai qu'une seule petite fonction cloud et il faut encore environ 1 minute pour se déployer même après avoir apporté la moindre modification. J'utilise également ce drapeau même si je n'ai qu'une seule fonction cloud. Il semble que quelque chose ne va pas ici.

Prenant encore littéralement des minutes en avril 2019 - Firebase version 6.6.0 - tout ce que je fais est de suivre le tutoriel ici : https://firebase.google.com/docs/functions/get-started

Je viens de télécharger et de prendre quelques minutes à chaque fois que je "déploye Firebase"

Les deux derniers jours, même le déploiement de l'hébergement a pris plusieurs minutes, alors qu'il a fallu environ 10 à 15 secondes il y a quelques semaines. Le déploiement des fonctions expire également.

Et la page d'état de Firebase est verte https://status.firebase.google.com/ .

Est-ce que quelqu'un sait pourquoi cela se produit?

Utiliser 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-

Cependant, ce sont des changements d'infrastructure qui prendront du temps, nous apprécions donc vraiment votre patience en attendant.

Des mises à jour côté infrastructure depuis votre dernière note il y a quelques trimestres ? Tant que ces modifications n'auront pas été apportées, est-il possible de rouvrir ce problème ? Fermé ne semble pas être l'état approprié à moins que le suivi ne soit passé à un problème différent/connexe.

Firebase functions est toujours super lent après que tout a été construit/téléchargé et que les fonctions sont créées/mises à jour côté serveur. Comme d'autres l'ont dit, il s'agit d'un amortisseur de vitesse de développement majeur.

firebase --version
7.1.0

Merci beaucoup d'avoir considéré!

@repentsinner le projet backend pour améliorer les temps de construction/déploiement est toujours en cours (et va bien !) mais il n'est toujours pas publié.

Avez-vous essayé d'utiliser l'émulateur (via firebase emulators:start ) pour accélérer votre processus de développement ? Si c'est le cas, nous serions ravis d'avoir vos commentaires !

Merci pour la mise à jour @samtstern.

Je n'ai pas encore essayé l'émulateur - j'utilise functions.https.onCall d'une application flutter ainsi que des données dans un firestore, et il semble (pour le moment en tout cas) tout rediriger dans les versions de test de l'application sur mon poste de travail de développement demande plus d'efforts que d'attendre les déploiements.

Je suppose que je peux utiliser le temps que j'attends pour examiner cela 🤨.

Bonne année à ce problème qui est toujours fermé et toujours pas résolu ! 🎉

Peut-être qu'un administrateur ou un OP peut renommer ce problème en "Préparation du répertoire des fonctions pour un déploiement extrêmement lent" car il semble avoir été fermé uniquement sur la base d'un correctif à cette étape du processus de déploiement global.

On peut alors ouvrir un nouveau ticket "Déploiement des fonctions extrêmement lent" puisque... le déploiement des fonctions est toujours extrêmement lent 😄

Ce problème a été résolu car nous ne pouvons rien faire de plus côté CLI pour améliorer les temps de déploiement. Pour le développement local, nous continuons d'investir dans l'émulateur, nous espérons que les utilisateurs n'auront à exécuter firebase deploy que lorsqu'ils se déploient en production et non dans le cadre de leur cycle de développement.

Les modifications du backend sont toujours en cours. Comme vous pouvez le constater, il y a eu des retards inattendus.

Merci pour la clarification @samtstern , donc je suppose que les problèmes/demandes contre firebase/firebase-tools ne s'appliquent qu'à la CLI ? Va chercher un repo/projet qui couvre le backend.

En ce qui concerne le développement local - du côté public des choses, il semble que Google encourage vraiment l'intégration de Firebase et Flutter qui semblent très bien fonctionner ensemble, mais dans la pratique, nous rencontrons des incohérences de temps de développement comme celle-ci. J'ai jeté un coup d'œil rapide à l'émulateur comme suggéré lors de la découverte de ce problème, mais il ne semblait vraiment pas prendre en charge un flux de travail de développement Firebase plus Flutter intégré, certainement pas aussi facilement que via le backend cloud. Je n'ai pas fait le tour pour voir si cela s'est amélioré ces derniers temps, mais cela semble peu probable.

@repentsinner ouais, ce référentiel ne suit que le travail CLI. Bien sûr, nous essayons de répondre à tout ce qui nous arrive, mais nous devons souvent fermer des problèmes alors que nous ne pouvons rien faire de productif ici. Nos backends ne sont pas open source, c'est pourquoi nous orientons généralement les utilisateurs vers l'assistance Firebase pour déposer des rapports de bogues ou des demandes de fonctionnalités concernant des éléments généraux de Firebase.

Quant à Flutter, nous l'adorons (voir : https://github.com/FirebaseExtended/flutterfire) mais il est important de noter qu'il ne s'agit pas d'une plate-forme Firebase officielle , ce qui signifie que nous ne pouvons pas offrir notre assistance complète pour des problèmes comme nous le faisons sur natif Android/iOS/Web. Peut-être que cela changera un jour mais pour l'instant c'est la situation.

Si vous avez des questions sur la façon de connecter votre application Flutter aux émulateurs Firebase, ouvrez un problème sur le référentiel FlutterFire et mettez-moi en copie, alors je peux également impliquer les bonnes personnes Flutter.

J'ai compris, merci pour la clarification @samtstern ! Je suis passé à d'autres projets pour le moment, mais je regarderai dans le dépôt FlutterFire quand je reviendrai dans ce genre de choses.

L'émulateur ne prend pas en charge le contexte d'authentification, il est donc 100% complètement inutile IMO.

J'ai fini par découvrir que mes déploiements ont gelé parce que j'essayais d'utiliser dotenv

J'insiste juste pour rappeler aux gens que c'est toujours un point douloureux ✌️

Pour les gens qui rencontrent encore cela - une chose que j'ai trouvée utile était d'utiliser functions.ignore pour éviter de télécharger des ballonnements inutiles. Je pense qu'un particulièrement bon à inclure est .git :
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

J'ai complètement abandonné les fonctions car le workflow de développement est plus que pénible.

Pour les gens qui rencontrent encore cela - une chose que j'ai trouvée utile était d'utiliser functions.ignore pour éviter de télécharger des ballonnements inutiles. Je pense qu'un particulièrement bon à inclure est .git :

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

Cela a effectivement donné quelques résultats. Courir dans environ 65 à 70% du temps maintenant. Merci!

Intéressant - par défaut, le sous-répertoire functions se trouve sous la racine du projet et n'aura donc pas de dossier .git . Les gens pour qui cela a aidé - à quoi ressemble votre structure de répertoires ?

@mbleigh Vrai. Ma meilleure hypothèse est que c'est intelligent à ce sujet et qu'il les applique au répertoire des fonctions.

@mbleigh J'ai un référentiel de fonctions uniquement, il semblait donc un peu idiot d'avoir un répertoire de fonctions. Tout est descendu dans la racine.

C'est un extrait de mon 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": "."
  },

Je le remplacerai volontiers par :
```
{
"include": ["lib", "package.json", "package-lock.json"]
}

FWIW Je crois que ces globs acceptent donc vous pourrez peut-être faire:

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

Les fonctions cloud viennent de démarrer et le temps de déploiement est pénible.

temps de déploiement douloureux :(

Notre application Firebase dispose de 60 fonctions cloud en cours d'exécution. Au début, nous avons commencé à avoir beaucoup d'échecs de déploiement en raison de quotas, nous l'avons donc divisé en lots, comme le suggèrent les documents. Il se déploie désormais de manière cohérente, mais chaque lot prend environ 3 minutes à déployer dans le cadre des actions GitHub CI sur les exécuteurs par défaut. Les lots sont d'environ 6 chacun, soit 10 lots au total, ce qui rend le temps de déploiement de notre fonction d'environ 30 minutes.

Les fonctions elles-mêmes sont de très petits morceaux de code avec des dépendances minimales. Je ne sais pas ce que nous pouvons faire d'autre pour accélérer le pipeline.

C'est vraiment triste à entendre. Une autre approche consiste à regrouper plusieurs points d'entrée/routes en une seule fonction. Ce n'est pas le meilleur de la séparation des préoccupations/taille/sécurité évidemment, mais c'est ce que nous avons fait avec tous nos points de terminaison API (point d'entrée unique qui utilise ensuite un routeur interne), et n'avons pas connu beaucoup de limites de quota depuis (mais cela arrive occasionnellement).

Pourtant, cette limite de quota semble vraiment faible, puisque la doc officielle répertorie "80 pour 100 secondes" pour les "Appels pour déployer ou supprimer des fonctions via l'API Cloud Functions". Je suppose que l'assistance Google ne pourrait pas augmenter encore plus cette limite ?

Pourtant, cette limite de quota semble vraiment faible, puisque la doc officielle répertorie "80 pour 100 secondes" pour les "Appels pour déployer ou supprimer des fonctions via l'API Cloud Functions". Je suppose que l'assistance Google ne pourrait pas augmenter encore plus cette limite ?

@dinvlad Je demandais à la fois aux ventes et au support technique d'augmenter cette limite d'API, elle est explicitement désactivée / grisée dans la section des quotas de la console GCP. Finalement, j'ai pu obtenir un ingénieur Google sur les hangouts qui m'a informé "Ce quota ne change pas"... donc je suppose que non.

Nous avons ajouté .git à la liste standard des ignorés dans la prochaine version :
https://github.com/firebase/firebase-tools/pull/2395

Cela devrait accélérer les sorties pour certains. Bien sûr, nous (l'équipe Firebase CLI) ne pouvons pas faire grand-chose à propos de la latence sur le backend Cloud Functions.

assurez-vous de faire firebase deploy --only hosting lorsque vous ne mettez pas à jour les fonctions

Ici, nous avons également regroupé les fonctionnalités associées dans une fonction, de sorte qu'elle finit par ressembler à "une fonction par zone de fonctionnalité" plutôt qu'à "une fonction par granule individuel de fonctionnalité".

Les caractéristiques de performance du déploiement déterminent fortement l'architecture de ce qui entre dans une fonction !

Quand et pourquoi ce problème a-t-il été fermé. Il a été ouvert en novembre 2017 et il semble que ce soit toujours autant un problème qu'à l'époque. Je ne vois pas de référence à "Fermé" ici et je serais intéressé de savoir pourquoi il a été fermé.

Je ne me plains pas, je me demande juste. Je suis sûr que cela est en cours d'élaboration, mais il serait bon de savoir tout progrès.

@chriscurnow , il a été fermé car la cause réelle est apparemment due au côté serveur (source fermée) et non aux outils CLI, même s'il se manifeste aux utilisateurs finaux comme un problème CLI (par @samtstern dans https://github.com /firebase/firebase-tools/issues/536#issuecomment-572830647).

Malheureusement, il n'y a pas de bon tracker public pour le back-end, nous obtenons donc des mises à jour ici :(

Comment pouvons-nous ouvrir ce bogue pour que Google le corrige dans son backend ?
C'est ridiculement lent

Par exemple, quel est même l'intérêt d'utiliser les fonctions Firebase si cela prend autant de temps

Hé les gars, peut-être que nous pourrions tous signaler ce problème à Google et peut-être qu'ils écouteront ?
https://firebase.google.com/support/troubleshooter/contact

Chaque fois que j'essaie d'utiliser quelque chose de Google pour quelque chose d'important, je me rappelle qu'il s'agit de l'une des entreprises les moins conviviales qui existent, mais bon, nous pourrions essayer.

@RenFontes Je viens de déposer le dossier 00075974 : le déploiement des fonctions Firebase est si lent qu'il est inutilisable avec le support Firebase. Je mettrai à jour ce message avec tout ce qu'ils reviendront.

Il est possible de déployer des fonctions spécifiques. La CLI ne pourrait-elle pas avoir un "tracker de somme de contrôle" pour chaque fonction et ne déployer que celles qui ont été modifiées (et aussi suivre tout ce qu'elle utilise : vars, packages, ...) ?

@SrBrahma bien sûr, mais le problème est toujours présent même si vous ne déployez qu'une seule fonction (par exemple, le déploiement d'une seule fonction peut toujours échouer en raison d'un délai d'attente).

Il ne devrait pas incomber à l'utilisateur de gérer le déploiement de la fonction de traitement par lots et, dans de nombreux cas, les mises à jour des fonctions sont nécessaires de manière atomique et ne peuvent donc pas être fractionnées/regroupées.

Appréciez les suggestions pour une solution de contournement, mais ce dont nous avons vraiment besoin ici, c'est d'un SLA de Google et de son adhésion.

IL est vrai que Firebase Functions Parfois? (peut-être souvent) est nul en termes de performances..C'est vraiment lent..Vous devriez plutôt prendre en charge Rust.. Go? est-il beaucoup plus rapide que Node ?

Vous attendez toujours que Google améliore le temps de déploiement des fonctions Google, n'est-ce pas ?
Passer de PWA à SSR m'a obligé à attendre 7 min de plus à chaque déploiement 😞