Como nomear ambientes para desenvolvedores
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Os projetos de software baseados em nuvem utilizam diversos ambientes. Os nomes desses ambientes geralmente são dev
, qa
, staging
e prod
.
É fundamental que esses ambientes estejam totalmente isolados um do outro, e eles geralmente têm permissões de acesso ao operador bem diferentes.
Por exemplo, a equipe de desenvolvimento pode ter acesso total ao ambiente dev
, mas acesso limitado ao ambiente prod
, com toda a implantação de código orientada apenas por scripts automatizados. Além disso, é essencial que os dados nos diferentes ambientes permaneçam isolados.
O uso de vários projetosGoogle Cloud atende a esses requisitos perfeitamente,
já que os projetos fornecem isolamento completo de código e dados, e as permissões
do operador podem ser gerenciadas separadamente. Como o App Engine faz o escalonamento automático das instâncias de serviço, você só paga pelo que usar. Por exemplo, se o ambiente de preparo exigir apenas uma de cada quatro semanas, não haverá custo referente à veiculação de instâncias para as outras três semanas. No entanto, haverá cobrança pelos dados armazenados nesses projetos.
Como nomear ambientes
Se você quiser criar seu aplicativo de microsserviços usando apenas vários
serviços, crie um único projeto Google Cloud para cada um dos
ambientes e nomeie-os de acordo, como web-app-dev
, web-app-qa
e web-app-prod
.
Ou, se preferir criar seu aplicativo de microsserviços usando vários projetos, separe os ambientes usando mais projetos, como web-app-dev
, web-app-prod
, user-service-dev
e user-service-prod
.
É necessário usar padrões de código para garantir que os projetos dev
chamem apenas outros projetos dev
e os projetos prod
chamem apenas outros projetos prod
.

A seguir
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-08-19 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-19 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)."]]