Cloud プロジェクトの計画

このページでは、本番環境のバックエンド用以外の目的で Cloud プロジェクトを作成する必要が生じた場合を含めて、Cloud プロジェクトの命名規則に関する推奨事項を示します。

環境の目的または API ライフサイクルのステージに応じて、次の作業が必要になる場合があります。

  • API 名または Cloud Endpoints サービス名を変更する。詳細については、Endpoints を構成するをご覧ください。
  • 別のプロジェクトを作成する。
  • API の提供に使用するパスを変更する。

使用可能な一般的なパターンをいくつか紹介します。

  • API のバージョニング: 下位互換性のない変更が将来的に必要になりそうな場合は、事前に計画を立て、API の提供に使用するパスにバージョン番号を追加します。例:

    • my-api.endpoints.my‐project.cloud.goog/v1/echo

  • 開発 / テスト インスタンス: デベロッパーがそれぞれ個別のプロジェクトで独自のバージョンのサービスを立ち上げます。たとえば、Dan は次のような名前を使用します。

    • my-api.endpoints.dan-dev-project.cloud.goog/v1/echo

  • ステージング: 本番環境にデプロイする前に、独自のプロジェクト内にあるステージング バックエンドで API をテストします。例:

    • my-api.endpoints.my‐project-staging.cloud.goog/v1/echo

  • 限定公開アルファ版の実行: すべてのユーザーではなく、一部のユーザーを対象に新しいバージョンのサービスをテストする場合は、そのアルファ版を独自のプロジェクト内に配置して（本番環境から可能な限り分離して）テストするのが特に簡単な方法です。例:

    • my-api.endpoints.my‐project-alpha.cloud.goog/v2alpha/echo

    あるいは、アルファ版を同じプロジェクトに入れて、個別のサービスとして構成することもできます。個別のサービスであれば、アルファ版のユーザーのみにアクセスを制限できます。例:

    • my-api-alpha.endpoints.my-project.cloud.goog/v2alpha/echo

  • 公開アルファ版の実行: すべてのユーザーを対象としたアルファ版をリリースする場合は、既存のバージョンと同じサービスおよびプロジェクト内にアルファ版を配置し、パスを変更します。次に例を示します。

    • my-api.endpoints.my-project.cloud.goog/v2alpha/echo