Java 8 はサポートが終了しており、2026 年 1 月 31 日に
非推奨になります。非推奨になると、過去に組織のポリシーを使用して以前のランタイムのデプロイを再度有効にしていた場合でも、Java 8 アプリケーションをデプロイできなくなります。既存の Java 8 アプリケーションは、
非推奨になる日付以降も引き続き実行され、トラフィックを受信します。
サポートされている最新バージョンの Java に移行することをおすすめします。
開発環境に名前を付ける
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
クラウドベースのソフトウェア プロジェクトには複数の環境が必要です。これらの環境には、dev、qa、staging、prod などの名前を付けるのが一般的です。これらの環境を互いに完全に分離することが重要です。通常、これらの環境には、まったく異なるオペレータ アクセス権限を付与します。たとえば、開発チームに dev 環境に対する完全アクセス権を付与する一方で、prod 環境に対しては限定的なアクセス権だけを付与し、この環境へのコードデプロイがすべて自動スクリプトのみで行われるようにします。また、環境ごとにデータを分離することも極めて重要になります。
上記の要件を満たす最適な方法は、複数の Google Cloud プロジェクトを使用することです。複数のプロジェクトを使用してコードとデータを完全に分離すれば、オペレータ権限をプロジェクトごとに管理できるためです。App Engine は稼働インスタンスを自動的にスケーリングするため、使用した分にのみ課金されます。たとえば、4 週間のうち 1 週間だけステージング環境が必要な場合に、残りの 3 週間分のインスタンス稼働費をお支払いいただく必要はありません。ただし、そのプロジェクトで保管されているデータについては費用が発生する点にご注意ください。
環境に名前を付ける
複数のサービスだけを使用してマイクロサービス アプリケーションを作成する場合は、各環境に Google Cloud プロジェクトを 1 つずつ作成し、環境に応じた名前（web-app-dev、web-app-qa、web-app-prod など）を付けることができます。
また、複数のプロジェクトを使用してマイクロサービス アプリケーションを作成する場合でも、同じように環境を分離できます。ただし、web-app-dev、web-app-prod、user-service-dev、user-service-prod などのように、使用するプロジェクト数が多くなります。dev プロジェクトは dev プロジェクト同士でのみ通信し、prod プロジェクトは prod プロジェクト同士でのみ通信するようにするために、コード上のパターンを使用する必要があります。
次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-09-04 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 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)."]]
