Asigna el nombre de los entornos de desarrollador
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Los proyectos de software basados en la nube deben emplear varios entornos. Esos entornos suelen tener nombres como dev, qa, staging y prod.
Es fundamental que cada uno de ellos esté completamente aislado de los otros. Por lo general, los entornos tienen permisos de acceso del operador muy diferentes.
Por ejemplo, puede suceder que el equipo de desarrollo tenga acceso total al entorno dev
environment, pero acceso limitado al entorno prod, y que toda la implementación del código se lleve a cabo exclusivamente mediante secuencias de comandos automatizadas. Además, es esencial que los datos de los distintos entornos permanezcan aislados.
El uso de varios proyectos deGoogle Cloud se adapta a estos requisitos a la perfección, ya que los proyectos proporcionan un aislamiento completo del código y los datos, y los permisos del operador se pueden administrar por separado. Debido a que App Engine escala de forma automática sus instancias de entrega, solo pagas por lo que utilizas. Por ejemplo, si tu entorno de etapa de pruebas solo se necesita una de cada cuatro semanas, no pagarás ningún costo de instancias de entrega por las otras tres. Sin embargo, ten en cuenta que se te aplicarán cargos por los datos almacenados en estos proyectos.
Asigna el nombre de los entornos
Si decides crear tu aplicación de microservicios mediante el uso de varios servicios, puedes crear un único proyecto Google Cloud para cada uno de los entornos y asignarles un nombre correspondiente, como web-app-dev, web-app-qa y web-app-prod.
De lo contrario, si decides crear tu aplicación de microservicios mediante el uso de varios proyectos, puedes lograr la misma separación entre los entornos, pero necesitarás usar más proyectos, comoweb-app-dev, web-app-prod, user-service-dev y user-service-prod.
Deberás usar patrones de código para asegurarte de que los proyectos dev solo llamen a otros proyectos dev y los proyectos prod solo llamen a los proyectos prod.
¿Qué sigue?
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-09-04 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eCloud-based projects should utilize multiple, isolated environments like \u003ccode\u003edev\u003c/code\u003e, \u003ccode\u003eqa\u003c/code\u003e, \u003ccode\u003estaging\u003c/code\u003e, and \u003ccode\u003eprod\u003c/code\u003e, each with distinct access permissions.\u003c/p\u003e\n"],["\u003cp\u003eData within these environments must remain completely isolated, which is a critical aspect of environment management.\u003c/p\u003e\n"],["\u003cp\u003eUsing multiple Google Cloud projects can effectively meet these isolation requirements, offering complete code and data separation with separately managed operator permissions.\u003c/p\u003e\n"],["\u003cp\u003eApp Engine's automatic scaling feature ensures you're only billed for active resources, although data storage costs still apply.\u003c/p\u003e\n"],["\u003cp\u003eMicroservice applications can use either multiple services within a project or multiple projects to segregate environments, but project-level separation requires coding patterns to ensure environment-specific communications.\u003c/p\u003e\n"]]],[],null,["# Naming Developer Environments\n\nCloud-based software projects should employ multiple environments. These\nenvironments typically have names like `dev`, `qa`, `staging`, and `prod`.\nIt's vital that these environments be completely isolated from one another,\nand they typically have very different operator-access permissions.\nFor example, the development team might have full access to the `dev`\nenvironment, but only limited access to the `prod` environment, with all\ncode deployment driven only by automated scripts. Further, it's\nabsolutely essential that the data in the different environments stay isolated.\n\nUsing multiple [Google Cloud projects](/resource-manager/docs/creating-managing-projects) suits these requirements perfectly\nas the projects provide complete isolation of code and data, and operator\npermissions can be managed separately. Because App Engine automatically scales\nits serving instances, you only pay for what you use. For example, if your\nstaging environment is only required one week out of every four, you won't pay\nfor any serving instance costs for the other three. However, keep in mind that\nyou will be billed for any data stored in these projects.\n\nNaming environments\n-------------------\n\nIf you choose to create your microservices application by using only multiple\nservices, you can create a single Google Cloud project for each of your\nenvironments and name them accordingly, such as `web-app-dev`, `web-app-qa`,\nand `web-app-prod`.\n\nAlternatively, if you choose to create your microservices application by\nusing multiple projects, you can achieve the same separation between\nenvironments, but you'll need to use more projects, such as\n`web-app-dev`, `web-app-prod`, `user-service-dev`, and `user-service-prod`.\nYou will need to use code patterns to ensure that the `dev` projects only\ncall other `dev` projects and the `prod` projects only call\nother `prod` projects.\n\nWhat's next\n-----------\n\n- Get an overview of [microservice architecture on App Engine](/appengine/docs/legacy/standard/php/microservices-on-app-engine).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/php/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/php/microservice-performance).\n- Learn how to [Migrate an existing monolithic application to one with microservices](/appengine/docs/legacy/standard/php/microservice-migration)."]]
