構成ファイルをデプロイし、バックエンドを再デプロイします。これにより、バックエンドは両方のバージョンのメソッドを持つことになります。バージョニングをご覧ください。つのバックエンドに実装します。この推奨事項には次の効果があります。前述の例のように、特定のバージョンへのリクエストはパスに基づくので、ルーティングが簡素化されます。構成とデプロイが簡素化されます。すべてのバージョンを同時にデプロイします。余分なバックエンドの実行を防ぎ、コストを低く抑えます。詳しくは、サービスのステージングをご覧ください。バージョニングの定義に対応しています。バージョン番号を増やして構成をデプロイすることは必須ではありません。必要に応じて増やすこともできます。プロジェクトとバックエンドで同時に管理するための機能が備わっています。例:http://echo-api.endpoints.my-project.cloud.goog/v1/echohttp://echo-api.endpoints.my-project.cloud.goog/v2/echo顧客ユーザーはこの機能を利用して、使用するバージョンを選択したり、新しいバージョンに移行するタイミングを管理したりすることができます。バックエンドの該当するメソッドにリクエストをルーティングする前に、各リクエストにバージョン番号がタグ付けされます。各リクエストにバージョン番号がタグ付けされることによって、以下のことが可能になります。バージョンごとのリクエスト数と全バージョンのリクエストの合計が表示されます。特定のバージョンで表示をフィルタリングできます。これにより、バージョンごとのトラフィック量を明確に把握できます。このログでは、どのクライアントがどのバージョンを使用しているかも確認できます。再デプロイすると、それ以降、グラフとログに表示されるアクティビティには、新しいバージョン番号がラベル付けされます。これによって、デプロイのラベル付き履歴を確認できます。アクティブだった期間のデータが引き続き表示されます。ライフサイクルの例このセクションでは、サービスの一般的なライフサイクルについて説明します。