Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Para apps de produção, é necessário configurar um fluxo de trabalho de desenvolvimento claro, principalmente
se houver mais de uma pessoa trabalhando no app. Um fluxo de trabalho de desenvolvimento
normalmente envolve a configuração e o gerenciamento de vários ambientes.
O Firebase tem níveis variados de suporte aos fluxos de trabalho do desenvolvedor e aos
ambientes que os constituem. Quando você estiver familiarizado com os termos
e suposições do fluxo de trabalho do desenvolvedor nesta página, confira nossas
práticas recomendadas gerais
e
diretrizes gerais de segurança
para configurar um projeto do Firebase e seus apps.
Sobre os ambientes
Em desenvolvimento de software, um ambiente é todo o hardware e o software
necessários para executar uma instância de um aplicativo ou sistema de
aplicativos.
Vários ambientes oferecem isolamento para desenvolvimento e teste de software
sem afetar os usuários. Conforme é mostrado no diagrama abaixo, os ambientes em um
nível alto são considerados em pré-produção ou em produção, sendo possível
ter o máximo de ambientes de pré-produção que for necessário. O diagrama também descreve
práticas comuns e recursos associados a cada
tipo de ambiente.
O processo de adiantar um recurso ou uma versão nesses ambientes para
a produção é chamado de pipeline de implantação.
Tipos de ambientes
Um ambiente é composto pela infraestrutura que precisa ser executada
e compatível com o aplicativo, o código e respectivos dados. Expanda cada um dos
termos a seguir para ver descrições de alguns ambientes comuns, incluindo
dicas sobre os tipos de dados usados em cada tipo de ambiente.
Ambientes de desenvolvimento (dev)
Todo desenvolvedor precisa de um ambiente de desenvolvimento, um local seguro e isolado para testar
as alterações à medida que são compiladas. O ideal é que todos os desenvolvedores da equipe tenham acesso
ao próprio ambiente de desenvolvimento. Além disso, se o ambiente de desenvolvimento for uma instância local,
um desenvolvedor poderá fazer iterações muito mais rápidas.
Em um ambiente de desenvolvimento, os dados propagados geralmente se assemelham aos
de produção, mas nunca devem conter dados reais do usuário. Também é possível que
haja dados, como strings muito longas, que no passado causaram bugs.
Ambientes de teste e controle de qualidade
Se tiver testes automatizados, você vai precisar de um ambiente para executá-los e de
redefini-los cada vez que ativar o
ambiente de teste.
Se você tiver engenheiros de controle de qualidade, talvez eles precisem de um ambiente que todos usam ou
de ambientes individuais para testar um novo candidato a lançamento.
Em ambientes de teste e controle de qualidade, os dados propagados são de qualidade,
representativos dos dados de produção, junto com dados que representam
casos extremos e exemplos de dados que causaram bugs no passado.
Ambientes de preparo
Para testes realistas de como uma versão funcionará na produção, você precisa de um ambiente
de preparo que tenha a máxima semelhança possível com a infraestrutura de produção. É
comum ter várias instâncias de preparo, se você precisar testar integrações
específicas de forma isolada.
Veja as diferenças comuns entre preparo e produção:
É possível que o preparo não tenha alguns recursos ou integrações que podem causar efeitos
colaterais. Por exemplo, o preparo pode ser definido para não enviar e-mails.
O preparo pode ter dados anônimos. Os dados podem ser falsos, mas precisam ser
realistas. Como o preparo é um lugar para depurar problemas com segurança, é possível dar à
equipe mais acesso a dados de preparo do que a dados de produção. Portanto, para proteger a privacidade
do usuário, não use dados reais do usuário no preparo.
Ambientes de produção (prod)
É preciso ter um ambiente de produção único para cada aplicativo que você
mantém. Essa é a instância com que os usuários interagem.
Há ambientes em que os dados podem ser alterados, excluídos e/ou recriados, e
isso não é possível no ambiente de produção devido à importância dos dados e ao fato de que
a perda ou alteração afetam diretamente os usuários.
No Console do Firebase, recomendamos marcar o projeto do Firebase associado
ao seu ambiente de produção como um
tipo de ambiente de "produção". Essa tag
ajuda a lembrar você e seus colegas de equipe de que qualquer mudança pode afetar seus
apps de produção associados e os respectivos dados.
Próximas etapas
Consulte nossas práticas recomendadas gerais
para configurar projetos do Firebase. Neste guia, respondemos às perguntas sobre a hierarquia
de projetos do Firebase, como registrar as variantes do seu app e a multilocação.
Veja as diretrizes gerais de segurança
para diferentes ambientes. Você quer garantir segurança a cada ambiente e aos
dados dele.
[null,null,["Última atualização 2025-08-04 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)."]]
