Orbit
デプロイメントのロールバック
If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…
デプロイメントのロールバック
本番環境が破損した場合、何も再構築することなく、以前のビルドを数秒で前面のトラフィックに戻すことができます。このガイドでは、ロールバックのしくみ、適切なデプロイメントの選択方法、Orbitが実行できる自動ロールバック、およびロールバック後の対応方法について説明します。
ロールバックのしくみ
Orbitはすべての成功したビルドのパッケージされたアーティファクトを保持しています。ロールバックはインストールコマンドやビルドコマンドを再実行しません。既に存在し、既に配信されているアーティファクトを昇格させるため、数秒で完了し、ビルドが失敗する理由のいずれでも失敗することはありません。
これが最初に手を付ける理由のすべてです。ロールバックは高速で、サイトが破損している間に前方へ修正しようとするより予測可能です。
以前のデプロイメントへのロールバック
- Orbitでプロジェクトを開きます。
- Deploymentsタブを開きます。
- 最後に正常に機能していたデプロイメントを見つけます。
- そのロー上のRoll backをクリックして確認します。
確認にはまさに何が起こるかが記載されています。トラフィックは古いビルドから即座に配信され、現在のデプロイメントが置き換えられます。
デプロイメント自体の詳細ページからもロールバックでき、ボタンにはコミットハッシュ短縮版へのRollback toと記載されます。
復元されたデプロイメントはCURRENTバッジを取得します。ロールバックされたデプロイメントは履歴にRolled backステータスで残ります。
ロールバックは破壊的ではなく、取り消す必要もありません。削除されるものはなく、履歴は書き換えられず、リポジトリは変更されません。本番ブランチへの次の成功したプッシュは、通常の方法で単に新しいライブバージョンになります。
適切なデプロイメントの特定
Deploymentsタブの各ロームはコミットメッセージと短縮ハッシュ、ブランチ、ステータス、デプロイされた時刻、プッシュ者を表示します。ライブのものはCURRENTバッジが付きます。
通常は問題を引き起こしたもののすぐ前のデプロイメントを希望します。これを確認するのに役立つ2つのことがあります。
- **Compare。**疑わしいデプロイメントを開き、Compareをクリックして前のものとの差分を表示します。ビルド時間、アーティファクトサイズ、キャッシュ状態、フレームワーク、ファイルレベルのアーティファクト差分です。
- **Deployment notes。**任意のデプロイメントには最大500文字のノートを付けることができます。時に「payment bugのhotfix」または「feature flag Xオン」を追加するのはタダで、数か月後の履歴を読みやすくします。これはまさに必要になる時です。
アーティファクトへのロールバックは、環境変数、リダイレクトルール、レスポンスヘッダーをロールバックしません。これらはリクエスト時またはビルド時に読み込まれ、アーティファクトに焼き込まれていません。インシデントがコード変更ではなく設定変更によって引き起こされた場合、コードをロールバックしても修正されません。デプロイメント詳細ページはビルド時に注入された変数を現在の設定と比較し、これが2つを区別する最速の方法です。
自動ロールバック
Orbitはあなたが気付く前にこれを実行できます。3つの設定はすべてSettingsにあります。
失敗時の自動ロールバック
Runtimeで、Auto-rollback on failureをオンにします。本番デプロイが失敗すると、最後の正常なデプロイメントが自動的に復元され、訪問者はダウンタイムを見ません。Stagingには独自の同等のトグルがあります。
ヘルスチェック
Health checkで、Health check pathを設定します（例：/または/api/health）。本番デプロイメントのたびに、Orbitはそのパスをフェッチします。15秒以内に2xx応答を返さない場合、前の正常なデプロイメントが復元されます。
スモークテスト
Smoke testsで、最大10個のカンマ区切りパスをリストしてください（例：/,/blog,/api/health）。各デプロイメント成功後、Orbitは各パスにGETを送信し、成功または失敗を記録します。いずれかが失敗し、自動ロールバックが有効な場合、前のデプロイメントが復元されます。結果はデプロイメントページにSmoke tests passedまたは失敗カウントとして表示され、原因になった場合はTriggered rollbackと記載されます。
実際にデータベースを実行するルート上のヘルスチェックは、ホームページ上のチェックよりもはるかに価値があります。キャッシュされたホームページを依然として配信する破損したデプロイメントは/チェックに成功し、本当のものに失敗します。
ロールバック対デプロイロック
ロールバックの準備ができていないが、調査中に新しいものがライブに行くのを防ぎたい場合は、代わりにデプロイをロックしてください:
- プロジェクトを開きます。
- Lock deploysをクリックします。
- 理由を追加します（例：「production issueを調査中」）。
プッシュによってトリガーされるデプロイメントはその後スキップされ、バナーはProduction deploys are lockedと理由を読みます。マニュアルデプロイメントは引き続き機能します。これは意図的です。ロックはアクシデンタルなデプロイメントを防ぎますが、あなたが発送する修正ではありません。Unlock deploysをクリックして解除します。
ロックとロールバックはよく一緒に機能します。最初にロールバックしてサービスを復元し、その後ロックして、診断中に誰かの日常的なマージがそれを取り消すのを防ぎます。
ステージングの本番環境へのプロモーション
ステージング環境を実行している場合、何もプッシュせずにテストされたステージングビルドを本番環境に入れることができます。
- プロジェクト概要を開き、Stagingセクションを見つけます。
- ステージングが本番環境より先にある場合、Promote to productionが表示されます。
- それをクリックして確認します。
確認を注意深く読んでください。Orbitにはプロモーション動作が2つあり、これらは相互運用可能ではありません。プロジェクト概要からのプロモーションは同じコミットで本番環境ビルド新規実行をトリガーし、本番環境変数と本番環境ビルドコマンドを使用します。ステージングアーティファクトは再利用されません。詳細ページから特定のステージングデプロイメントをプロモートすると、ステージングビルドが再構築なしで即座にライブに移ることが明確に記載されます。ステージングと本番環境の環境変数が異なる場合、最初のパスはテストしたものとは異なるアーティファクトを生成します。
Orbitは自動的にプロモートすることもできます。SettingsのAuto-promote stagingは、スモークテストが成功して段階的に正常な段階が数時間後に本番環境にプロモートされます。15分ごとにチェックされます。
ロールバック後
リポジトリの根本的な問題を修正し、新しいコミットをプッシュしてください。これにより、通常のビルドがトリガーされ、新しいライブバージョンになります。デプロイをロックした場合は、最初にロック解除するか、プッシュがスキップされます。
プロジェクトActivityタブはロールバックを他のすべての発生事項と一緒に記録するため、誰が何をロールバックしたか、そしていつするかの監査証跡があります。
ロールバック距離を制限するもの
ロールバックには、アーティファクトが依然として存在する必要があります。2つの設定がそれを制御します:
- プランのデプロイメント履歴ウィンドウ: Launchで7日間、Liftoffで30日間、Apexで90日間。
- プロジェクトのArtifact retention設定。環境ごとに成功したアーティファクトの数を保持し、10から500まで、デフォルトは50です。
現在ライブなデプロイメントのアーティファクトは、どちらに関わらず常に保持されます。
1日に何度もデプロイする場合、アーティファクト数が、日数ではなく最初にヒットする制限です。50回のデプロイは単一週間である可能性があります。インシデント中に上限を発見するのではなく、Artifact retentionを上げてください。