Entwicklerumgebungen benennen
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Bei cloudbasierten Softwareprojekten sollten mehrere Umgebungen zum Einsatz kommen. Diese Umgebungen haben normalerweise Namen wie dev, qa, staging und prod.
Es ist wichtig, dass diese Umgebungen vollständig voneinander getrennt sind. In der Regel haben sie auch sehr unterschiedliche Bedienerzugriffsberechtigungen.
Das Entwicklungsteam kann beispielsweise vollen Zugriff auf die dev-Umgebung haben, aber nur eingeschränkten Zugriff auf die prod-Umgebung. Alle Code-Deployments erfolgen dann nur über automatisierte Skripts. Außerdem müssen die Daten in den verschiedenen Umgebungen unbedingt voneinander getrennt bleiben.
Die Verwendung mehrerer Google Cloud -Projekte erfüllt diese Anforderungen perfekt, da die Projekte eine vollständige Isolierung von Code und Daten bieten und die Bedienerberechtigungen getrennt verwaltet werden können. Da App Engine die Bereitstellungsinstanzen automatisch skaliert, zahlen Sie nur für das, was Sie auch nutzen. Ein Beispiel: Wenn Ihre Staging-Umgebung immer nur eine von vier Wochen benötigt wird, bezahlen Sie in den übrigen drei Wochen nicht für eine Bereitstellungsinstanz. Beachten Sie jedoch, dass Ihnen in diesen Projekten gespeicherte Daten in Rechnung gestellt werden.
Umgebungen benennen
Wenn Sie Ihre Mikrodienstanwendung unter ausschließlicher Verwendung mehrerer Dienste erstellen, können Sie für jede Ihrer Umgebungen ein einzelnes Google Cloud Projekt erstellen und die Umgebungen entsprechend benennen, z. B. web-app-dev, web-app-qa und web-app-prod.
Wenn Sie Ihre Mikrodienstanwendung dagegen mit mehreren Projekten erstellen, können Sie die gleiche Trennung zwischen den Umgebungen erreichen, benötigen dafür jedoch mehr Projekte, z. B. web-app-dev, web-app-prod, user-service-dev und user-service-prod.
Sie müssen Codemuster verwenden, um dafür zu sorgen, dass die dev-Projekte nur andere dev-Projekte aufrufen und die prod-Projekte nur andere prod-Projekte aufrufen.
Nächste Schritte
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-09-04 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
