デプロイメントの管理（RailwayのパブリックGraphQL APIを介してデプロイメントを管理する...）

RailwayのパブリックGraphQL APIを介してデプロイメントを管理する方法を学びます。

デプロイメントアクション

「サービス」→「デプロイメント」タブ内で、以前のデプロイメントの最後にある3つの点をクリックすることで、デプロイメントに対してさまざまなアクションを実行できます。

間違いがあった場合に備えて、以前のデプロイメントにロールバックします。ロールバックを実行するには、以前のデプロイメントの最後にある3つの点をクリックし、ロールバックの確認を求められます。

デプロイメントのロールバックは、以前に成功したデプロイメントに戻します。ロールバックプロセス中に、Dockerイメージとカスタム変数の両方が復元されます。

注：プランの保持ポリシーより古いデプロイメントはロールバックで復元できず、したがってロールバックオプションは表示されません。

成功、失敗、またはクラッシュしたデプロイメントは、以前のデプロイメントの最後にある3つの点をクリックすることで再デプロイできます。

これにより、まったく同じコードとビルド/デプロイ構成で新しいデプロイメントが作成されます。

注：最新のコミットからデプロイメントをトリガーするには、コマンドパレットを使用します：CMD + K → "Deploy Latest Commit"。これにより、GitHubのデフォルトブランチから最新のコミットがデプロイされます。

現在、サービス設定で接続せずにデフォルト以外のブランチから強制的にデプロイする方法はありません。

ユーザーは、デプロイメントタブの最後にある3つの点をクリックし、「デプロイメントを中止」を選択することで、進行中のデプロイメントをキャンセルできます。これにより、進行中のデプロイメントがキャンセルされます。

デプロイメントが完了した場合、デプロイメントタブの最後にある3つの点をクリックし、「削除」を選択することで削除できます。これにより、デプロイメントが削除され、それ以上のプロジェクトの使用が停止します。

デプロイメントが Crashed 状態の場合、基になるプロセスがゼロ以外の終了コードで終了したため、実行されていません。デプロイメントが正常に終了した場合（終了コード0）、ステータスは Success のままです。

Railwayは、クラッシュしたデプロイメントを最大10回自動的に再起動します（再起動ポリシーによって異なります）。この制限に達すると、デプロイメントのステータスは Crashed に変更され、プロジェクトのメンバーに通知のWebhookとメールが送信されます。

デプロイメントにインラインで表示される「再起動」ボタンをクリックして、Crashed したデプロイメントを再起動します。

クラッシュしたデプロイメントを再起動すると、元のビルドのコードと構成を含むまったく同じイメージが復元されます。デプロイメントがオンラインに戻ると、そのステータスは Success に戻ります。

デプロイメント内をクリックし、コマンドパレットを使用して、任意の状態でデプロイメントを再起動することもできます。

参照変数を使用して、サービスの起動順序を制御できます。あるサービスが別のサービスを参照している場合、ステージングされた変更を適用したり、環境を複製したりするときに、参照しているサービスの後にデプロイされます。

循環依存関係を持つサービスは、それらを無視して通常どおりデプロイします。

たとえば、PostgreSQLデータベースに依存するAPIサービスをデプロイしているとします。

次のような参照変数を持つサービスがある場合：

APIサービスには、同じプロジェクトのPostgresサービスで定義されている DATABASE_URL=${{Postgres.DATABASE_URL}} があります。

Railwayは次のようになります。