Nommer les environnements de développement
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les projets logiciels basés sur le cloud doivent employer plusieurs environnements, lesquels portent généralement des noms tels que dev, qa, staging et prod.
Il est essentiel que ces environnements soient complètement isolés les uns des autres. Par ailleurs, ils disposent généralement d'autorisations d'accès très différentes pour les opérateurs.
Par exemple, l'équipe de développement peut disposer d'un accès complet à l'environnement dev, mais seulement d'un accès limité à l'environnement prod, l'intégralité du déploiement de code n'étant régie que par des scripts automatisés. De plus, il est absolument essentiel que les données des différents environnements restent isolées.
L'emploi de plusieurs projetsGoogle Cloud répond parfaitement à ces exigences, car les projets assurent une isolation complète du code et des données, tandis que les autorisations des opérateurs peuvent être gérées séparément. Étant donné qu'App Engine assure un scaling automatique de ses instances de diffusion, vous ne payez qu'à hauteur de ce que vous consommez. Par exemple, si votre environnement de préproduction n'est requis qu'une semaine sur quatre, vous ne paierez aucune instance de diffusion pour les trois autres semaines. Cependant, gardez à l'esprit que toute donnée stockée dans ces projets vous sera facturée.
Nommer les environnements
Si vous choisissez de créer votre application de microservices en n'utilisant que les services multiples, vous pouvez créer un seul projet Google Cloud pour chacun de vos environnements et les nommer en conséquence, tels que web-app-dev, web-app-qa et web-app-prod.
Autrement, si vous choisissez de créer votre application de microservices en définissant plusieurs projets, vous pouvez obtenir la même séparation entre les environnements, mais vous devrez employer davantage de projets, par exemple web-app-dev, web-app-prod, user-service-dev et user-service-prod.
Vous devez utiliser des formats de code pour vous assurer que les projets dev n'appellent que d'autres projets dev et que les projets prod n'appellent que d'autres projets prod.
Étape suivante
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eCloud-based software 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 operator-access permissions.\u003c/p\u003e\n"],["\u003cp\u003eEmploying multiple Google Cloud projects provides complete isolation of code and data across different environments, allowing for separate management of operator permissions.\u003c/p\u003e\n"],["\u003cp\u003eUsing App Engine's automatic scaling ensures you only pay for serving instances when they're in use, but data storage costs still apply.\u003c/p\u003e\n"],["\u003cp\u003eMicroservice applications can create separate Google Cloud projects for each environment, such as \u003ccode\u003eweb-app-dev\u003c/code\u003e, \u003ccode\u003eweb-app-qa\u003c/code\u003e, and \u003ccode\u003eweb-app-prod\u003c/code\u003e, or they can use multiple projects for multiple services, like \u003ccode\u003euser-service-dev\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eCode patterns are required to ensure \u003ccode\u003edev\u003c/code\u003e and \u003ccode\u003eprod\u003c/code\u003e projects call other projects in the same environment.\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/java/microservices-on-app-engine).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/java/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/java/microservice-performance).\n- Learn how to [Migrate an existing monolithic application to one with microservices](/appengine/docs/legacy/standard/java/microservice-migration)."]]
