Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Per le app di produzione, devi configurare un flusso di lavoro di sviluppo chiaro, soprattutto se più persone lavorano alla tua app. Un flusso di lavoro di sviluppo solitamente prevede la configurazione e la gestione di più ambienti.
Firebase offre diversi livelli di supporto per i flussi di lavoro degli sviluppatori e
ambienti costitutivi. Dopo aver acquisito familiarità con i termini del flusso di lavoro per sviluppatori
su questa pagina, dai un'occhiata al nostro
best practice generali
e
linee guida generali sulla sicurezza
per configurare un progetto Firebase e le tue app.
Informazioni sugli ambienti
Nello sviluppo software, per ambiente si intende tutto l'hardware e il software
necessari per eseguire un'istanza di un'applicazione o un sistema
diverse applicazioni.
Una serie di ambienti fornisce l'isolamento per lo sviluppo e il test del software
senza influire sugli utenti. Come mostrato nel diagramma seguente, gli ambienti
sono considerate pre-produzione o produzione e puoi
disporre di tutti gli ambienti di pre-produzione necessario. Il diagramma descrive anche
funzioni e pratiche comuni associate a ogni
tipo di ambiente.
Il processo di avanzamento di una funzionalità o rilascio attraverso questi ambienti per
è detta pipeline di deployment.
Tipi di ambienti
Un ambiente è composto dall'infrastruttura sottostante che devi eseguire
e supportare la tua applicazione, il relativo codice e i dati. Espandi ciascuno dei seguenti termini per esaminare le descrizioni di alcuni ambienti comuni, inclusi suggerimenti sui tipi di dati utilizzati in ogni tipo di ambiente.
Ambienti di sviluppo (sviluppo)
Ogni sviluppatore ha bisogno di un ambiente di sviluppo, un luogo sicuro e isolato in cui eseguire test
modifiche durante la loro creazione. Idealmente, ogni sviluppatore del tuo team ha accesso
al proprio ambiente di sviluppo. Inoltre, se l'ambiente di sviluppo è un'istanza locale,
uno sviluppatore può eseguire l'iterazione molto più velocemente.
I dati in un ambiente di sviluppo vengono inizializzati con dati che in genere assomigliano ai dati di produzione, ma non devono mai contenere dati di utenti reali. Potrebbe anche contenere dati che hanno causato bug in passato, ad esempio stringhe molto lunghe.
Ambienti di test e QA
Se esegui test automatici, ti serve un ambiente in cui eseguirli
e dovrai reimpostare i dati ogni volta che avvii il test
completamente gestito di Google Cloud.
I tecnici addetti al QA potrebbero aver bisogno di un ambiente che tutti utilizzano oppure
potrebbero essere necessari singoli ambienti per testare un nuovo candidato di release.
I dati negli ambienti di test e QA vengono sottoposti a seeding con dati di qualità che sono generalmente rappresentativi dei dati di produzione, insieme a dati che rappresentano casi limite ed esempi di dati che hanno causato bug in passato.
Ambienti di gestione temporanea
Per eseguire test realistici sul funzionamento di una release in produzione, è necessaria una gestione temporanea
che imita l'infrastruttura di produzione il più fedelmente possibile. È
è comune avere più istanze di gestione temporanea se è necessario testare specifiche
integrazioni in modo isolato.
Ecco le differenze più comuni tra gestione temporanea e produzione:
Nella gestione temporanea potrebbero mancare alcune funzionalità o integrazioni che potrebbero
e gli effetti sonori. Ad esempio, la gestione temporanea potrebbe essere impostata in modo da non inviare email.
La gestione temporanea potrebbe avere dati anonimizzati. i dati possono essere falsi, ma dovrebbero esserlo
realistico. Poiché la gestione temporanea è uno spazio per eseguire in sicurezza il debug dei problemi, puoi concedere
un accesso del team più ampio ai dati di gestione temporanea rispetto a quelli di produzione. Quindi, per proteggere gli utenti
di privacy, non devi utilizzare dati utente reali nella gestione temporanea.
Ambienti di produzione (produzione)
Per ogni applicazione che gestisci, è necessaria una singola
completamente gestito di Google Cloud. Questa è l'istanza con cui interagiscono gli utenti.
A differenza degli altri ambienti in cui puoi modificare, eliminare e/o ricreare
i dati nel tuo ambiente di produzione sono molto importanti; perdita o alterazione
i dati di produzione influenzeranno direttamente i tuoi utenti.
Nella console Firebase, ti consigliamo di eseguire il tagging del progetto Firebase associato
con il tuo ambiente di produzione
"produzione" tipo di ambiente. Questo tag
può aiutare a ricordare a te e ai tuoi colleghi che eventuali modifiche potrebbero incidere
le app di produzione associate e i relativi dati.
Passaggi successivi
Consulta le nostre best practice generali
per l'impostazione di progetti Firebase. Questa guida risponde alle domande su Firebase
la gerarchia dei progetti, come registrare le varianti dell'app e la multitenancy.
[null,null,["Ultimo aggiornamento 2025-07-25 UTC."],[],[],null,["For production apps, you need to set up a clear development workflow, especially\nif you have more than one person working on your app. A development workflow\nusually involves setting up and managing multiple environments.\n\nFirebase has varying levels of support for developer workflows and the\nconstituent environments. Once you're familiar with the developer workflow terms\nand assumptions on this page, check out our\n[general best practices](/docs/projects/dev-workflows/general-best-practices)\nand\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\nfor setting up a Firebase project and your apps.\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\nAbout environments\n\nIn software development, an ***environment*** is all the hardware and software\nthat are required to run an instance of an application or system of\napplications.\n\nA series of environments provides isolation for developing and testing software\nwithout impacting users. As shown in the diagram below, environments at a\nhigh-level are considered either *pre-production* or *production* , and you can\nhave as many pre-production environments as needed. The diagram also describes\ncommon practices and features associated with each\n[type of environment](#types).\n\nThe process of progressing a feature or release through these environments to\nproduction is called a ***deployment pipeline***.\n\nTypes of environments\n\nAn environment is composed of the underlying infrastructure that you need to run\nand support your application, its code, and its data. Expand each of the\nfollowing terms to review descriptions of some common environments, including\ntips on the types of data used in each environment type.\n| **Key Point:** Every app should have at least one *pre-production* environment that's isolated from production data and resources.\n\n\u003cbr /\u003e\n\n**Development (dev) environments**\n\n\u003cbr /\u003e\n\nEvery developer needs a development environment --- a safe, isolated place to test\nchanges as they're being built. Ideally, every developer on your team has access\nto their own dev environment. Also, if the dev environment is a local instance,\na developer can iterate much faster.\n\nThe data in a dev environment is seeded with data that generally resembles the\nproduction data, but should never contain any real users' data. It may also\ncontain data that has caused bugs in the past, like very long strings.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Test and QA environments**\n\n\u003cbr /\u003e\n\nIf you have automated tests, you need an environment in which to run those\ntests, and you need to reset the data each time you spin up the test\nenvironment.\n\nIf you have QA engineers, they may need one environment that they all use, or\nthey may need individual environments to test a new release candidate.\n\nThe data in test and QA environments is seeded with quality data that's\ngenerally representative of the production data, along with data that represents\ncorner cases and examples of data that have caused bugs in the past.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Staging environments**\n\n\u003cbr /\u003e\n\nFor realistic tests of how a release will work in production, you need a staging\nenvironment that mimics production infrastructure as closely as possible. It's\ncommon to have multiple staging instances if you need to test specific\nintegrations in isolation.\n\nHere are common differences between staging and prod:\n\n- Staging may be missing some features or integrations that could cause side\n effects. For example, staging may be set to not send email.\n\n- Staging may have anonymized data; the data can be fake, but it should be\n realistic. Because staging is a place to safely debug problems, you might give\n broader team access to staging data than production data. So, to protect user\n privacy, you shouldn't use actual user data in staging.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Production (prod) environments**\n\n\u003cbr /\u003e\n\nFor each application that you maintain, you need a single production\nenvironment. This is the instance with which your users interact.\n\nUnlike the other environments where you can change, delete, and/or recreate\ndata, the data in your prod environment is very important; losing or altering\nyour prod data will directly affect your users.\n\nIn the Firebase console, we recommend tagging the Firebase project associated\nwith your production environment as a\n[\"production\" environment type](/support/faq#set-environment-type). This tag\ncan help remind you and your teammates that any changes could affect your\nassociated production apps and their data.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n| **Tip** : Integrations with analytics services, including Google Analytics, often require special attention when you're setting up a new environment. You also don't want your tests from pre-production environments to impact production analytics.\n|\n| We recommend not setting up analytics for most pre-production environments,\n| unless you want to specifically test analytics integrations, like making\n| sure the right parameters are being sent to your analytics service.\n\nNext steps\n\n- Review our [general best practices](/docs/projects/dev-workflows/general-best-practices)\n for setting up Firebase projects. This guide answers questions about Firebase\n project hierarchy, how to register your app variants, and multi-tenancy.\n\n- Review the [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)."]]
