1.1ユーザーから新機能の要望を受け、新しいメソッドを追加します。バージョン番号を増分します。ステージング環境に変更をデプロイしてテストし、動作を確認します。バックエンドを本番環境にデプロイします。提供されますが、呼び出し元は新しいメソッドに対するリクエストを発行できるようになります。古いメソッドに対するインターフェースを変更していないので、顧客ユーザーはクライアントを変更して再デプロイする必要がありません。クライアントは以前と同様に、古いメソッドにリクエストを送信できます。以前の期間の表示を選択すると、グラフとログに旧バージョンが表示され、デプロイのラベル付き履歴を確認できます。2.0既存のメソッドに、下位互換性のない変更を加えることが必要になりました。維持することにしました。古いメソッドはそのまま残し、新しいバージョンのメソッドを実装します。構成ファイルを作成します。提供されるように構成します。構成ファイルは新しいバージョンのメソッドを指すようになります。構成ファイルを同時にデプロイし、バックエンドを再デプロイします。バージョニングをご覧ください。示され、各バージョンのトラフィック量を確認できます。呼び出して新しいバージョンのメソッドを使うこともできます。フレームワークによって異なります。サンプルをご覧ください。提供を終了することができます。構成ファイルのみをデプロイし、バックエンドを再デプロイします。実装したコードをバックエンドから安全に削除できるようになります。履歴データが維持されます。プラクティスとしておすすめします。プロジェクトを作成して、本番環境から隔離することもおすすめします。つのプロジェクト内のリソース間で共有されます。サービスを含めると、ループエラーなどがあった場合に本番環境のサービスが停止する可能性があります。プロジェクトには、その用途を明確に示す名前を付けることをおすすめします。付けることができます。付けると、本番環境サービス用であることが見分けやすくなります。サービス名は一意である必要があります。用意し、デプロイ先プロジェクトの名前に一致するようにサービス名を変更する処理を考え出す必要があります。