Best practice generali per la configurazione dei progetti Firebase
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina fornisce best practice generali di alto livello per configurare i progetti Firebase e registrare le app in un progetto, in modo da avere un flusso di lavoro di sviluppo chiaro che utilizzi ambienti distinti. Dopo aver preso familiarità con le best practice riportate in questa pagina, consulta le nostre linee guida generali sulla sicurezza.
Informazioni sulla gerarchia dei progetti Firebase
Questo diagramma mostra la gerarchia di base di un progetto Firebase. Ecco le relazioni principali:
Un progetto Firebase è come un contenitore per tutte le tue app e per eventuali risorse e servizi di cui è stato eseguito il provisioning per il progetto.
Un progetto Firebase può avere una o più app Firebase registrate (ad esempio, sia le versioni per iOS sia quelle per Android di un'app o sia le versioni senza costi sia quelle a pagamento di un'app).
Tutte le app Firebase registrate nello stesso progetto Firebase condividono e hanno accesso a tutte le stesse risorse e a tutti gli stessi servizi di cui è stato eseguito il provisioning per il progetto.
Ecco alcuni esempi:
Tutte le app Firebase registrate nello stesso progetto Firebase condividono gli stessi backend, ad esempio Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,
Cloud Storage e Cloud Functions.
Tutte le app Firebase registrate nello stesso progetto Firebase sono associate alla stessa proprietà Google Analytics, in cui ogni app Firebase è uno stream di dati distinto.
Dove si inserisce un progetto Google Cloud in questa gerarchia?
Un aspetto della gerarchia dei progetti Firebase non mostrato nel diagramma sopra è la relazione con un progetto Google Cloud. Un progetto Firebase è in realtà solo un progetto Google Cloud per il quale sono abilitati configurazioni e servizi specifici di Firebase.
Tieni presente che tutte le app registrate nello stesso progetto Firebase condividono e hanno accesso anche a tutte le stesse risorse e a tutti gli stessi servizi Google Cloud.
Registrazione delle varianti di app con i progetti Firebase
Ecco alcuni suggerimenti importanti per registrare le varianti dell'app con un progetto Firebase:
Assicurati che tutte le app registrate in un progetto Firebase siano varianti della piattaforma
della stessa applicazione dal punto di vista dell'utente finale. Registra le versioni per iOS, Android e web della stessa app o dello stesso gioco con lo stesso progetto Firebase.
Se hai più varianti di build che potrebbero condividere le stesse risorse Firebase, registra le varianti con lo stesso progetto Firebase. Alcuni esempi sono un blog e un'app web nello stesso progetto oppure le versioni sia senza costi che a pagamento della stessa app nello stesso progetto.
Se hai più varianti di build basate sullo stato di rilascio
(anziché sull'attività o sull'accesso degli utenti finali comuni, come sopra), registra ogni
variazione con un progetto Firebase separato. Un esempio è la build di debug rispetto alla build di release: registra ciascuna di queste build nel proprio progetto Firebase.
Le build basate sullo stato di rilascio non devono condividere le stesse risorse Firebase
perché i dati di debug rischiano di inquinare o addirittura di sostituire i dati di produzione.
Le varianti platform di ciascuna di queste varianti di build devono trovarsi nello
stesso progetto Firebase. Ad esempio, registra le build di debug sia per iOS sia per Android in un progetto Firebase "dev" perché entrambe possono interagire con gli stessi dati e le stesse risorse non di produzione.
Evitare la multitenancy
La multitenancy può comportare gravi problemi di configurazione e privacy dei dati, tra cui problemi indesiderati di aggregazione di dati e analisi, autenticazione condivisa, strutture di database eccessivamente complesse e difficoltà con le regole di sicurezza.
In genere, se un insieme di app non condivide gli stessi dati e le stesse configurazioni,
consigliamo vivamente di registrare ogni app con un progetto Firebase diverso.
Ad esempio, se sviluppi un'applicazione white-label, ogni app con un'etichetta indipendente deve avere un proprio progetto Firebase e le versioni per iOS e Android di quell'etichetta devono trovarsi nello stesso progetto Firebase. Ogni
app con etichetta indipendente non deve (per motivi di privacy) condividere dati con altre.
[null,null,["Ultimo aggiornamento 2025-07-25 UTC."],[],[],null,["This page provides general, high-level best practices for setting up Firebase\nprojects and registering your apps with a project so that you have a clear\n[development workflow](/docs/projects/dev-workflows/overview-environments) that\nuse distinct environments. Once you're familiar with the best practices on this\npage, check out our\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines).\n| **Key Point:** We recommend reading our guides thoroughly, but here's the top takeaway about development workflows: \n| **Firebase recommends using a *separate* Firebase project for *each* environment\n| in your development workflow.**\n\nUnderstanding the hierarchy of Firebase projects\n\n\nThis diagram shows the basic hierarchy of a Firebase project. Here are the key\nrelationships:\n\n- A **Firebase project** is like a container for all your apps and any resources\n and services provisioned for the project.\n\n- A Firebase project can have one or more **Firebase Apps** registered to it\n (for example, both the iOS and Android versions of an app, or both the free\n and paid versions of an app).\n\n- All Firebase Apps registered to the same Firebase project **share and have\n access to all the same resources and services provisioned for the project**.\n Here are some examples:\n\n - All the Firebase Apps registered to the same Firebase project share the same\n backends, like Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,\n Cloud Storage, and Cloud Functions.\n\n - All Firebase Apps registered to the same Firebase project are associated\n with the same Google Analytics property, where each Firebase App is a\n separate data stream in that property.\n\nWhere does a Google Cloud project fit into this hierarchy?\n\nOne aspect of the Firebase project hierarchy that's not shown in the diagram\nabove is the relationship with a Google Cloud project. **A Firebase project is\nactually just a Google Cloud project that has additional *Firebase-specific*\nconfigurations and services enabled for it.**\nNote that all the apps registered to the same Firebase project also share and\nhave access to all the same Google Cloud resources and services, too.\n\nLearn more about the Firebase and Google Cloud relationship in\n[Understand Firebase projects](/docs/projects/learn-more#firebase-cloud-relationship)\n\nRegistering app variants with Firebase projects **Key Point:** All the apps registered to a Firebase project share and can access the same data as well as the resources and services provisioned for the project, which includes database instances, storage buckets, functions, etc.\n\nHere are some important tips for registering your app variants with a Firebase\nproject:\n\n- Ensure that all apps registered to a Firebase project are **platform variants\n of the same application** from an end-user perspective. Register the iOS,\n Android, and web versions of the same app or game with the *same* Firebase\n project.\n\n- If you have **multiple build variants that could *share the same Firebase\n resources*** , register the variants with the *same* Firebase project. Some\n examples are a blog and a web app in the same project, or both the free and\n paid versions of the same app in the same project.\n\n- If you have **multiple build variants that are *based on release status***\n (rather than on common end-user activity or access, like above), register each\n variant with a *separate* Firebase project. An example is your debug vs\n release build -- register each of these builds in its own Firebase project.\n\n - Builds based on release status should not share the same Firebase resources\n because that risks your debug data polluting or even overriding your prod\n data.\n\n - The *platform* -variants of each of these build variants should be in the\n *same* Firebase project. For example, register both the iOS and the Android\n debug builds in a \"dev\" Firebase project because they can both interact with\n the same non-prod data and resources.\n\n| **Note:** For each Android app, if you provide a SHA-1 key for the app, you need to provide a package name and SHA-1 key combination that is globally unique across all of Google Cloud.\n\nAvoiding multi-tenancy **Key Point:** Connecting several different logically independent apps and/or web sites to a single Firebase project (often called \"multi-tenancy\") is not recommended.\n\nMulti-tenancy can lead to serious configuration and data privacy concerns,\nincluding unintended issues with analytics aggregation, shared authentication,\noverly-complex database structures, and difficulties with security rules.\n\nGenerally, **if a set of apps don't share the same data and configurations,\nstrongly consider registering each app with a different Firebase project.**\n\nFor example, if you develop a white-label application, each independently\nlabeled app should have its own Firebase project, and the iOS and Android\nversions of that label should be in the same Firebase project. Each\nindependently labeled app shouldn't (for privacy reasons) share data with the\nothers.\n\nNext steps\n\n- Review the\n [general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\n for different environments. You want to make sure each environment and its\n data are secure.\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]
Questo diagramma mostra la gerarchia di base di un progetto Firebase. Ecco le relazioni principali: