Java 8 ha raggiunto la fine del supporto
e verrà
ritirato
il 31 gennaio 2026. Dopo il ritiro, non potrai eseguire il deployment di applicazioni Java 8, anche se la tua organizzazione ha utilizzato in precedenza un criterio dell'organizzazione per riattivare i deployment di runtime legacy. Le tue applicazioni Java 8 esistenti continueranno a essere eseguite e a ricevere traffico dopo la
data di ritiro. Ti consigliamo di
eseguire la migrazione all'ultima versione supportata di Java.
Denominazione degli ambienti di sviluppo
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
I progetti software basati su cloud devono utilizzare più ambienti. Questi ambienti in genere hanno nomi come dev, qa, staging e prod.
È fondamentale che questi ambienti siano completamente isolati l'uno dall'altro e in genere abbiano autorizzazioni di accesso dell'operatore molto diverse.
Ad esempio, il team di sviluppo potrebbe avere accesso completo all'ambiente dev, ma solo accesso limitato all'ambiente prod, con il deployment di tutto il codice gestito solo da script automatici. Inoltre, è assolutamente essenziale che i dati nei diversi ambienti rimangano isolati.
L'utilizzo di più Google Cloud progetti soddisfa perfettamente questi requisiti, poiché i progetti forniscono un isolamento completo di codice e dati e le autorizzazioni dell'operatore possono essere gestite separatamente. Poiché App Engine scala automaticamente le sue istanze di pubblicazione, paghi solo per ciò che utilizzi. Ad esempio, se il tuo ambiente di staging è necessario solo una settimana su quattro, non pagherai i costi delle istanze di pubblicazione per le altre tre. Tuttavia, tieni presente che ti verrà addebitato il costo di tutti i dati archiviati in questi progetti.
Denominazione degli ambienti
Se scegli di creare l'applicazione di microservizi utilizzando solo più servizi, puoi creare un singolo progetto per ciascuno dei tuoi ambienti e rinominarli di conseguenza, ad esempio web-app-dev, web-app-qa e web-app-prod. Google Cloud
In alternativa, se scegli di creare l'applicazione di microservizi utilizzando più progetti, puoi ottenere la stessa separazione tra ambienti, ma dovrai utilizzare più progetti, ad esempio web-app-dev, web-app-prod, user-service-dev e user-service-prod.
Dovrai utilizzare pattern di codice per assicurarti che i progetti dev chiamino solo altri progetti dev e che i progetti prod chiamino solo altri progetti prod.
Passaggi successivi
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-09-04 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
