Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En las apps de producción, debes configurar un flujo de trabajo de desarrollo claro, en especial
si hay más de una persona trabajando en ellas. Por lo general, un flujo de trabajo de desarrollo
implica configurar y administrar múltiples entornos.
Firebase tiene distintos niveles de compatibilidad con los flujos de trabajo para desarrolladores y los
entornos constituyentes. Una vez que te familiarices con los términos
del flujo de trabajo para desarrolladores y las suposiciones en esta página, consulta las
prácticas recomendadas generales y los
lineamientos generales de seguridad
para configurar un proyecto de Firebase y tus apps.
Acerca de los entornos
En el desarrollo de software, un entorno corresponde a todo el hardware y software
necesarios para ejecutar una instancia de una aplicación o de un sistema de
aplicaciones.
Una serie de entornos proporciona aislamiento para desarrollar y probar software
sin afectar a los usuarios. Como se muestra en el siguiente diagrama, en un nivel global,
los entornos se consideran de preproducción o producción, y puedes
tener tantos entornos de preproducción como sean necesarios. En el diagrama, también se describen
prácticas y funciones comunes asociadas con cada
tipo de entorno.
El proceso de traspasar una función o versión a través de estos entornos hasta la
producción se denomina canalización de implementación.
Tipos de entornos
Un entorno se compone de la infraestructura subyacente que necesitas para ejecutar
y admitir las aplicaciones, su código y sus datos. Expande cada uno de los
siguientes términos para revisar las descripciones de algunos entornos comunes, así como
sugerencias sobre los tipos de datos que se usan en cada clase de entorno.
Entornos de desarrollo (dev)
Todos los desarrolladores necesitan un entorno de desarrollo, es decir, un lugar seguro y aislado para probar
cambios mientras los crean Lo ideal es que cada desarrollador de tu equipo tenga acceso
a su propio entorno dev. Además, si el entorno dev es una instancia local,
el profesional puede realizar iteraciones mucho más rápido.
Los datos de un entorno de desarrollo se inicializan con datos que, por lo general, se parecen a los
datos de producción, pero nunca deben contener datos de usuarios reales. También pueden
contener datos que causaron errores en el pasado, como strings muy largas.
Entornos de prueba y control de calidad
Si tienes pruebas automatizadas, necesitas un entorno para ejecutarlas
y restablecer los datos cada vez que inicies el entorno
de pruebas.
Si tienes ingenieros de control de calidad, es posible que necesiten un entorno que todos usen o
que requieran entornos individuales para probar una nueva versión potencial.
Los datos de los entornos de prueba y control de calidad se inicializan con datos de calidad que,
generalmente, representan los datos de producción, junto con datos que representan
situaciones limítrofes y ejemplos de datos que causaron errores en el pasado.
Entornos de etapa de pruebas
Para probar de forma realista cómo funcionará una versión en producción, necesitas un entorno de etapa de pruebas
que imite la infraestructura de producción de la manera más parecida posible. Es
común tener varias instancias de etapa de pruebas si necesitas probar integraciones específicas
de forma aislada.
Aquí encontrarás las diferencias comunes entre la etapa de pruebas y la de producción:
Es posible que algunas etapas de pruebas no tengan funciones o integraciones específicas que podrían causar efectos
secundarios. Por ejemplo, la etapa de pruebas puede configurarse para no enviar correos electrónicos.
Las etapas de pruebas pueden tener datos anónimos que, si bien pueden ser falsos, deben ser lo más
realistas posible. Debido a que la etapa de pruebas es un lugar para depurar problemas de forma segura, puedes otorgar
a un equipo más acceso a los datos de etapa de pruebas que a los de producción. Por lo tanto, para proteger la privacidad
de los usuarios, no debes usar datos reales de ellos en esta etapa.
Entornos de producción (prod)
Para cada aplicación que mantengas, necesitas un solo entorno de
producción. Esta es la instancia con la que interactúan tus usuarios.
A diferencia de los otros entornos en los que puedes cambiar, borrar o volver a crear datos,
los datos en tu entorno prod son muy importantes. La pérdida o alteración
de los datos de producción afectará directamente a los usuarios.
En Firebase console, recomendamos etiquetar el proyecto de Firebase asociado
con tu entorno de producción como un
tipo de entorno de "producción". Esta etiqueta
puede ayudarte a recordar a ti y a tus colegas que cualquier cambio podría afectar a las
apps de producción asociadas y sus datos.
Próximos pasos
Revisa nuestras prácticas recomendadas generales
para configurar proyectos de Firebase. En esta guía, se responden preguntas sobre la jerarquía de proyectos de Firebase,
cómo registrar las variantes de tus apps y la arquitectura multiusuario.
[null,null,["Última actualización: 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)."]]
