デプロイメント
概要と用語
このページでは、GitLab.com へのアプリケーション変更のデプロイに関わる個々のステップを説明します。デプロイメントプロセスの遵守方法についてのガイダンスも記載されています。デプロイメントとリリースアプローチ全体の高レベルなビューについては、デプロイメントとリリースのハンドブックページをご覧ください。
Release Manager による自動デプロイのツアー
GitLab.com のデプロイメントプロセス
GitLab.com は 1 日に複数回更新を受け取ります。
release-toolsプロジェクトには、パッケージをビルドしてデプロイする自動タスクが設定されています。
パッケージのビルド
- デプロイメント用の新しいブランチが月曜日から金曜日の間、毎時間作成されます。ブランチは CI テストを通過した（「グリーンビルド」の）最新コミットから作成されます。つまり、
gitlab-org/gitlabでスペックが失敗している場合、デプロイメントはそれ以上進めません。 - その後、最新コミットに新しいバージョンがタグ付けされ、新しいパッケージのビルドが開始されます。
- ブランチが作成される際、パッケージがタグ付けされる前に
~"Pick into auto-deploy"ラベル付きのマージリクエストがブランチにチェリーピックされます（重要なラベルを参照）。 さらに、15 分ごとにタスクが実行され、~"Pick into auto-deploy"ラベル付きのマージリクエストが最新のデプロイメントブランチにチェリーピックされます。1 つ以上の MR がチェリーピックされた場合、新しいパッケージがタグ付けされます。
新しいコミットと成功した CI パイプラインがある場合、パッケージは（新しい自動デプロイブランチごとに）約 1 時間ごとに作成されます。
パッケージがタグ付けされ、ビルドプロセスが開始できます
2a. タグから Omnibus パッケージがビルドされます。
2b. 並行して Cloud Native GitLab パッケージがビルドされます。
パッケージのデプロイ
- 15 分ごとに、自動タスクがビルド完了した最新パッケージを選択し、デプロイメントプロセスを開始します。
パッケージは GitLab.com に以下の手順でデプロイされます。
定期的な間隔で、release-tools の自動タスクがビルド完了した最新の利用可能なパッケージを検索します。
1a. ビルド済みパッケージが見つかると、それは自動的に gstg-cny（staging.gitlab.com のカナリアステージ）にデプロイされます。
1b. 並行して、同じパッケージが Staging-ref 環境 gstg-ref にデプロイされます
自動化された QA エンドツーエンド/統合テストが実行されます。gstg-cny を対象とするものと staging（gstg）を対象とする 2 セットのブロッキング QA テストが実行されます。これは、データベースなどのサービスを共有する複数のバージョンの GitLab コンポーネントがデプロイされた混在デプロイメント環境で発生する問題を露出させるために設計されています
テスト通過後、パッケージは自動的に gprd-cny（gitlab.com のカナリアステージ）にデプロイされ、カナリアステージの概要と使用方法を確認できます。これにより、特定のプロジェクト（
gitlab-org/gitlabなど）と少量のエンドユーザートラフィックが新しいパッケージを使用することになりますステージングカナリアへのデプロイメントと同様に、2 セットの自動 QA エンドツーエンド/統合テストが実行されます。1 セットは本番カナリーステージを対象とし、もう 1 セットはメインステージを対象とします（新旧のコードがまだ機能していることを確認するため）。本番カナリー（gprd-cny）を対象とする
smokeおよびreliableテストはブロッキングですgitlab.com のカナリアステージで 30 分経過し、新しい例外やアラートが報告されていない場合、パッケージは gitlab.com および staging.gitlab.com へのデプロイメントの準備が完了したと見なされます
gitlab.com および staging.gitlab.com へのプロモーションは Release Managers によって手動でトリガーされます。
blocks deploymentsラベル付きの進行中のインシデントや変更リクエストにより、パッケージが gstg（ステージング）と gprd（本番）にデプロイされることが妨げられます。カナリー（gstg-cny と gprd-cny の両方）へのデプロイメントはブロックされません。マイグレーションはカナリーデプロイメント中に実行されるため、ブロックされません。ただし、デプロイ後マイグレーションはブロックされますステージング環境へのデプロイメント
環境の健全性を評価するための本番チェックが実行されます。健全と判断された場合、パイプラインは自動的に継続します
本番環境へのデプロイメントはステージングより遅延して実行されます 各デプロイメントは Slack チャンネル #announcements に通知を送信します。 デプロイメントの一部として、release/tasks Issue トラッカーに QA Issue が作成され、変更が環境を通過していることをプロセスに関与する人々に通知します
デプロイ後マイグレーション（PDM）の実行
GitLab.com パッケージをロールバック可能にするために、デプロイ後マイグレーションは GitLab.com デプロイメントプロセスから独立しています。これらのマイグレーションは、デプロイ後マイグレーション（PDM）パイプラインを通じてステージングと本番環境で実行されます。PDM は Release Managers が標準的な運用手順の一部として手動で実行します。本番インシデントのリスクを最小化しつつ、自然流入のトラフィックが最小限となるように、Release Managers は APAC 営業終了と EMEA 営業開始の間の移行期間（おおよそ UTC 06:00 から 09:00 の間）に PDM 実行をスケジュールします。
標準的なサイクルでは毎日の実行を目指しますが、PDM の実行は裁量で判断され、毎日実行される保証はありません。本番環境で PDM を実行すると、そのデプロイメントはロールバックできなくなります。そのため、Release Managers はロールバックの選択肢を残しておく必要がある場合や、チームがほかの作業に注力する必要がある場合に PDM を延期します。以下の場合、PDM は実行されません。
- パッチリリースの準備、タグ付け、公開を行う期間であるパッチウィンドウ中。
- 月次リリースのウィンドウ中。
blocks deploymentsラベルが付いたインシデントや変更リクエストがアクティブな間（デプロイメントブロッカーを参照）。- 本番変更ロック期間中や、ほかのリリース管理作業を行っている間。
PDM は通常、ウィンドウ終了後の次の適切な実行時間に再開します。最も早い場合でも AMER の終業間際や APAC の始業時となるため、延期によって 1 日以上遅れる場合があります。
PDM が保留中か実行済みかを確認するには、Delivery：リリース情報ダッシュボード（内部）とデプロイ後マイグレーションパイプラインのドキュメントを参照してください。質問がある場合は、Release Managers に連絡してください。
Release Managers がデプロイ後マイグレーションパイプラインを実行する際の手順:
- ステージングでデプロイ後マイグレーションスクリプトが実行されます
- ステージングに対して QA テストが実行されます
- QA 検証が成功した後、本番でデプロイ後マイグレーションスクリプトが実行されます。
このパイプラインの詳細はデプロイ後マイグレーションパイプラインのドキュメントにあります。
デプロイ後マイグレーションが実行されたかどうかを確認するには、このガイドをご覧ください。
デプロイメントロールバック
ロールバックはインシデントを軽減するための迅速かつ安全な方法です。以前のパッケージにロールバックすることでインシデントの原因を取り除きますが、修正がマージされ、パッケージ化され、デプロイ準備が整うまで以降のすべてのデプロイメントがブロックされます。リリースプロセスへの潜在的な混乱があるため、ロールバックを実行する権限を持つのはRelease Managersのみです。
ロールバックを決定する前に考慮すべき要素:
- ロールバックは利用可能ですか？デプロイ後マイグレーションの最後の実行のパッケージにのみロールバックできます。適合性をテストするための chatops コマンドが利用可能です。
- インシデントはフィーチャーフラグで緩和できますか？多くの新しい変更にはフィーチャーフラグが含まれています。フィーチャーフラグを特定してオフにすることが通常最も速い緩和策です。
- パッケージには数百の変更が含まれている可能性があり、ロールバックするとすべてが取り消され、特に月次リリース期限が近い場合は複数のチームに影響を与える可能性があることに注意してください。
ロールバックが引き起こす混乱のレベルのため、通常は S1 または S2 インシデントの場合にのみロールバックをオプションとして検討します。インシデント緩和オプションの評価に関するより詳細な情報はインシデントランブックにあります。
ロールバックを進めることを決定した場合、Release Managers はロールバックランブックに従ってください。
ロールバックパイプライン
ロールバックは本質的に以前にデプロイされたパッケージの新しいデプロイメントです。以前にデプロイされたパッケージとして既に安定していることがわかっているため、ロールアウト全体のテストに費やす時間を安全に削減できます。
Gitaly と Praefect は GitLab Rails バージョンへの依存関係があるため、デプロイの逆順でロールバックする必要があります。これを実現するために、単純にデプロイメントパイプラインを再実行するのではなく、別のロールバックパイプラインを使用します。
ステージング環境のロールバックパイプラインの例:
デプロイメントブロッカー
インシデントによるデプロイメントのブロック
警告:
blocks deploymentsフラグがアクティブな場合、マイグレーション（デプロイ後マイグレーション以外）は引き続き実行されます。詳細はblocks deploymentsフラグは何をするのか？をご覧ください。
誰でも本番へのデプロイメントを停止またはブロックできます。方法は以下のとおりです。
インシデントを宣言する（インシデントとして）:
- severity1 または severity2 インシデントを宣言すると、デフォルトで デプロイメントがブロックされます。
- severity3 および severity4 を宣言すると、「Blocks Deployments」 はデフォルトで 「no」 になります。
- severity3 以下から severity2 以上へ変更すると、手動で変更されていない限り、「Blocks Deployments」 フラグが設定されます。
- severity2 未満に重大度を下げると、手動で変更されていない限り、フラグが解除されてデプロイメントが許可されます。
インシデント Slack チャンネルから
/incident fieldコマンドを実行してカスタムフィールドを更新し、Block Deployments で 「Yes」 を選択します。#releases チャンネルで Release Managers に通知します。
blocks deployments フラグは何をするのか？
blocks deployments フラグが設定されている場合:
- カナリーデプロイメントは継続: ステージングカナリー（gstg-cny）および本番カナリー（gprd-cny）へのデプロイメントはブロックされません
- マイグレーションはブロックされません: データベースマイグレーションはカナリーデプロイメントの一部として実行されます。マイグレーションをブロックしたい場合は、Release Managers に連絡してください
- メイン環境へのプロモーションはブロック: ステージング（gstg）と本番（gprd）へのプロモーションが防がれます
- デプロイ後マイグレーションはブロック: デプロイ後マイグレーションパイプラインがブロックされます
この設計により、メイン環境へのプロモーションにのみデプロイプレッシャーを生じさせながら、コード変更とマイグレーションの継続的な検証が確保されます。
変更ロック期間中のデプロイメントのブロック
さらに、すべての本番環境（[canary]を含む）への自動デプロイメントは、変更ロック期間中に停止されます。現在、変更ロック期間は毎週金曜日 23:00 UTC から月曜日 06:00 UTC の間と、スケジュールされた本番変更期間中です。
変更ロック期間中は、デプロイメントが severity::1 の可用性またはセキュリティの Issue を修正する場合、GitLab ChatOps を通じて手動デプロイメントをトリガーできます。
以下のイベントにより本番へのデプロイメントがブロックされます。
blocks deploymentラベル付きのアクティブなインシデントblocks deploymentラベル付きの進行中の変更 Issue- ステージングカナリー（gstg-cny）、ステージング（gstg）、本番カナリー（gprd-cny）、本番（gprd）を対象とするブロッキング（
smokeおよびreliable）の自動エンドツーエンドテストの失敗
Release Managers は EOC からの意見を得て、ブロックを上書きしてデプロイメントを継続することを決定できます。
重要なラベル
GitLab.com ピックラベル
通常のサイクルよりも高い優先度で GitLab.com にデプロイする必要があるコードには、~"Pick into auto-deploy" ラベルがあります。ブランチは 1 日を通じて定期的に作成されるため、スケジュールされたデプロイメントに含めるためにこのラベルは必要ありません。
新しい GitLab.com リリースを作成する自動化システムはこのラベルを特別に探しており、このラベルと severity::1/severity::2 の重大度ラベルが付いたマージリクエストは、アクティブな自動デプロイブランチに自動的にチェリーピックされます。マージリクエストがピックできない場合（ピックするファイルに競合がある場合など）、著者に現在のアクティブなリリースブランチを対象とする新しいマージリクエストを作成するよう求めるメッセージがマージリクエストに投稿されます。
このラベルは、マージリクエストが特に緊急な場合、以下の状況でのみ使用してください。例えば:
- severity::1/severity::2 インシデントを解決または緩和する
- severity::1/severity::2 の問題につながる可能性のあるリグレッションを解決する
- GitLab.com の安定性を改善できる緊急なパフォーマンスまたは可用性の修正
高重大度のバグが見つかった場合は、イベントと対応を追跡するためにインシデントを報告してください。
このラベルがマージリクエストが後続のデプロイをブロックしているために追加された場合は、ステータスへの認知を高めるために #releases Slack チャンネルにメモを残すことを検討してください。
新機能や緊急でない修正の場合、新しいリリースは数日または数時間後にあるため、このラベルは使用しないでください。
MR が GitLab.com にデプロイされているかどうかを確認する方法については release/docs をご覧ください。
よくある質問
マージリクエストはいつデプロイされますか？
現在、特定のタイムラインで自動デプロイブランチを作成しています。現在の Mean Time To Production の時間と目標については、インフラストラクチャパフォーマンス指標ページで確認できます。
ピックラベル付きのマージリクエストの場合、プロセスは異なります。
マージリクエストが現在どの環境にあるかを確認するにはどうすればよいですか？
release tools は MR の workflow:: ラベルを使用して、マージリクエストがデプロイメントプロセスのどのステージにあるかを示します。例えば、マージリクエストに workflow::production ラベルがあれば、本番環境にデプロイされたことを示します。
詳細についてはこのガイドをご覧ください。
リグレッションが見つかりました。次は何をすればよいですか？
高い重大度の可能性があるリグレッションが見つかった場合は、すぐにデプロイメントブロッカーの手順に従ってデプロイメントを停止してください。
月次リリース前の高重大度のバグについては、#releases で Release Managers にも通知してください。
デプロイ後マイグレーションの問題が見つかりました。次は何をすればよいですか？
デプロイ後マイグレーションが GitLab.com で実行されないようにするには、すぐにデプロイメントブロッカーの手順に従い、Release Managers に通知してください。月次リリースに含まれないように、デプロイ後マイグレーションを元に戻す作業を進めてください。
リソース
| 説明 | 場所 |
|---|---|
| デプロイメントオーケストレーション | リンク |
| デプロイメントドキュメント | リンク |
| リリース関連タスクの Issue トラッカー | リンク |
| Delivery グループの Issue トラッカー | リンク |
| Release Managers スケジュール | リンク |
| メンテナンスポリシー | リンク |
5d840611)