プロジェクトのデプロイ

リポジトリが接続されると、Orbitは本番ブランチへのすべてのプッシュにデプロイします。コミットをクローンし、依存関係をインストールし、ビルドを実行し、出力をパッケージ化して、配信を開始します。このガイドでは、完全なデプロイサイクル、手動でデプロイをトリガーする方法、および本番環境でのデプロイを許可するかどうかを決定するコントロールについて説明します。

自動デプロイの仕組み

SettingsのGitでProduction branchとして設定されたブランチへのすべてのプッシュがデプロイをトリガーします。Orbitは以下を実行します。

1. GitHub、GitLab、またはBitbucketからプッシュイベントを受信します。
2. デプロイをキューに入れ、ビルドスロットを割り当てます。
3. 正確なコミットでリポジトリをクローンします。
4. プランでビルドキャッシュが利用可能な場合、キャッシュされたnode_modulesを復元します。
5. インストールコマンド（npm ci、yarn install、またはpnpm install（ロックファイルから検出））を実行します。
6. ビルドコマンドを実行します。
7. 出力ディレクトリをデプロイメントアーティファクトにパッケージ化してアップロードします。
8. 環境を切り替えて新しいアーティファクトを配信します。

デプロイメント詳細ページでは、これらをBuild phasesとして表示します。Clone、Cache restore、Install、Cache save、Build、Upload、Doneです。ほとんどのプロジェクトは1～3分で完了します。

デプロイステータス

ビルド進行中の監視

プロジェクトのOverviewでは、Latest buildパネルにライブストリーミングログ付きの現在のビルドが表示されます。Full detailsをクリックするとデプロイメント詳細ページが開き、ビルド進捗バー、推定残り時間、キューの位置、およびフェーズごとに分類されたビルドタイムラインが表示されます。

プランで複数の同時ビルドが許可されていてすべてがビジー状態の場合、ページはそれを明確に表示します。同時ビルドスロットのうち何個が使用中かを表示し、1つが解放されるとデプロイメントを自動的に開始します。OrbitからQueueに進むと、すべてのプロジェクト全体で進行中のすべてのビルドを確認できます。

手動でデプロイをトリガーする

新しいコミットをプッシュせずにデプロイする方法は4つあります。

最新コミットを再デプロイする

1. プロジェクトを開きます。
2. Deploymentsタブを開きます。
3. デプロイをクリックして詳細ページを開きます。
4. Retry buildをクリックします。キャッシュされた古い依存関係が疑われる場合は、More retry options、Retry with cleared cacheを使用してください。

今すぐデプロイ

DeploymentsタブのDeploy nowボタンは、本番ブランチの現在のheadの新しいビルドをキューに入れます。

デプロイをスケジュール

デプロイメントは将来の時間にスケジュールできます。Orbitはスケジュール時点でコミットをスナップショットするため、後で実行されるビルドは、その間に入ったコードではなく、承認したコードです。

デプロイフック

デプロイフックは、何かがPOSTリクエストを送信したときにビルドをキューに入れる秘密URLです。ヘッドレスCMS、cronジョブ、またはCIパイプラインから再ビルドするときに使用します。プロジェクトのHooksタブで設定します。デプロイフックでデプロイをトリガーを参照してください。

ビルド設定

Orbitはほとんどのプロジェクトに適切なデフォルトを検出します。SettingsのBuild settingsで任意の設定をオーバーライドします。

フィールドを空白のままにすると、自動検出値が保持されます。フレームワーク別の値や最初のデプロイを失敗させるミスを含む完全な詳細については、ビルドコマンドと出力ディレクトリの設定を参照してください。

デプロイが許可される時期の決定

Orbitには複数の独立したゲートがあります。それらはすべてSettingsに配置されています。

デプロイロック

ロックを使用して、インシデント、メンテナンスウィンドウ、またはコード固定中に本番環境をロックします。

1. プロジェクトを開きます。
2. Lock deploysをクリックします。
3. オプションの理由を追加します。

ロック中、プッシュがトリガーされたデプロイメントはサイレントでスキップされ、バナーにProduction deploys are lockedと理由が表示されます。手動デプロイはまだ機能します。これは意図的です。ロックは偶発的なデプロイを停止しますが、配信しようとしている修正は停止しません。Unlock deploysをクリックしてロックを解除します。

本番環境の承認が必要

Deploy protectionの下のRequire approval for productionをオンにします。プッシュがトリガーされた本番環境デプロイメントは、誰かがデプロイメントを開いてApproveまたはRejectをクリックするまでAwaiting approvalで一時停止します。パネルデプロイメントとデプロイフックは影響を受けません。

ステージング成功が必須

Require staging success before productionは、ステージング環境が同じコミットを正常にデプロイするまで、プッシュがトリガーされた本番環境デプロイメントを保持します。誰かが待機をスキップするために手動で承認することはできます。

CI必須チェック

CI required checksの下で独自のCIでデプロイをゲートします。GitHubでは、コンマ区切りのActionsジョブ名を入力し、すべてが成功する必要があります。GitLabでは、空でない値はパイプライン全体の完了を待ちます。CIの失敗はOrbitデプロイメントを自動的にキャンセルします。

デプロイ凍結スケジュール

Deploy freeze scheduleは承認されたウィンドウ外でのプッシュがトリガーされたデプロイメントをブロックします。週末ブロック、許可された時間範囲、またはその両方です。すべての時間はUTCです。手動デプロイメントとデプロイフックは影響を受けません。

不要なビルドをスキップ

• Ignored paths: コンマ区切りのglobパターン。プッシュのすべてのファイルが一致する場合、ビルドはスキップされます。*.md,docs/**はドキュメンテーションコミットがデプロイメントをトリガーするのを防ぎます。
• Branch ignore patterns: 一致するブランチからのプッシュは完全にスキップされます。dependabot/*,renovate/*は一般的なケースです。
• Git tag deploys: v*のようなglobを使用して一致するタグがプッシュされたときに本番環境にデプロイします。

ビルドキャッシュ

OrbitはLiftoffおよびApexプランでnode_modulesをビルド間でキャッシュします。キャッシュされたインストールが使用される場合、デプロイメントはCache hitバッジを表示し、インストールフェーズは劇的に短くなります。コールドビルドはCold buildを代わりに表示します。

完全な再インストールを強制するには、Settingsを開き、Clear build cacheを開いて確認します。各環境の次のデプロイメントはゼロから完全なインストールを実行します。

デプロイがうまくいかない場合

Orbitは本番環境に不正なデプロイを放置するのではなく、キャッチできます。

• Auto-rollback on failureは本番環境デプロイメントが失敗した場合、最後の正常なデプロイメントを自動的に復元します。
• Health checkはすべての本番環境デプロイメント後に選択したパスをフェッチします。15秒以内の非2xx応答は前の正常なデプロイメントを復元します。
• Smoke testsは各成功したデプロイメント後に最大10個のパスに対してGETリクエストを実行し、成功または失敗を記録します。オートロールバックと組み合わせると、失敗するスモークテストはデプロイメントをロールバックします。

デプロイメント自体を元に戻すには、デプロイメントをロールバックを参照してください。ビルドが失敗した理由を理解するには、失敗したビルドのトラブルシューティングを参照してください。