デプロイメント

概要と用語

このページでは、GitLab.com へのアプリケーション変更のデプロイに関わる個々のステップを説明します。デプロイメントプロセスの遵守方法についてのガイダンスも記載されています。デプロイメントとリリースアプローチ全体の高レベルなビューについては、デプロイメントとリリースのハンドブックページをご覧ください。

リリースマネージャーによる自動デプロイのツアー

GitLab.com のデプロイメントプロセス

GitLab.com は 1 日に複数回更新を受け取ります。

release-tools プロジェクトの自動タスクがパッケージのビルドとデプロイを設定しています。

パッケージのビルド

• デプロイメント用の新しいブランチが月曜日から金曜日の間、毎時間作成されます。ブランチは CI テストを通過した（「グリーンビルド」の）最新コミットから作成されます。つまり、gitlab-org/gitlab でスペックが失敗している場合、デプロイメントはそれ以上進めません。
• その後、最新コミットに新しいバージョンがタグ付けされ、新しいパッケージのビルドが開始されます。
• ブランチが作成される際、パッケージがタグ付けされる前に ~"Pick into auto-deploy" ラベル付きのマージリクエストがブランチにチェリーピックされます（重要なラベルを参照）。 さらに、15 分ごとにタスクが実行され、~"Pick into auto-deploy" ラベル付きのマージリクエストが最新のデプロイメントブランチにチェリーピックされます。1 つ以上の MR がチェリーピックされた場合、新しいパッケージがタグ付けされます。

• ソース

新しいコミットと成功した CI パイプラインがある場合、パッケージは（新しい自動デプロイブランチごとに）約 1 時間ごとに作成されます。

1. パッケージがタグ付けされ、ビルドプロセスが開始できます

2. 2a. タグから Omnibus パッケージがビルドされます。

   2b. 並行してクラウドネイティブ GitLab パッケージがビルドされます。

パッケージのデプロイ

• 15 分ごとに、自動タスクがビルド完了した最新パッケージを選択し、デプロイメントプロセスを開始します。

• ソース

パッケージは GitLab.com に以下の手順でデプロイされます。

1. 定期的な間隔で、release-tools の自動タスクがビルド完了した最新の利用可能なパッケージを検索します。

   1a. ビルド済みパッケージが見つかると、それは自動的に gstg-cny（staging.gitlab.com のカナリアステージ）にデプロイされます。

   1b. 並行して、同じパッケージが Staging-ref 環境 gstg-ref にデプロイされます

2. 自動化された QA エンドツーエンド/統合テストが実行されます。gstg-cny を対象とするものと staging（gstg）を対象とする 2 セットのブロッキング QA テストが実行されます。これは、データベースなどのサービスを共有する複数のバージョンの GitLab コンポーネントがデプロイされた混在デプロイメント環境で発生する問題を露出させるために設計されています

3. テスト通過後、パッケージは自動的に gprd-cny（gitlab.com のカナリアステージ）にデプロイされます。これにより、特定のプロジェクト（gitlab-org/gitlab など）と少量のエンドユーザートラフィックが新しいパッケージを使用することになります

4. ステージングカナリアへのデプロイメントと同様に、2 セットの自動 QA エンドツーエンド/統合テストが実行されます。1 セットは本番カナリーステージを対象とし、もう 1 セットはメインステージを対象とします（新旧のコードがまだ機能していることを確認するため）。本番カナリー（gprd-cny）を対象とする smoke および reliable テストはブロッキングです

5. gitlab.com のカナリアステージで 30 分経過し、新しい例外やアラートが報告されていない場合、パッケージは gitlab.com および staging.gitlab.com へのデプロイメントの準備が完了したと見なされます

6. gitlab.com および staging.gitlab.com へのプロモーションはリリースマネージャーによって手動でトリガーされます。blocks deployments ラベル付きの進行中のインシデントや変更リクエストにより、パッケージが gstg（ステージング）と gprd（本番）にデプロイされることが妨げられます。カナリー（gstg-cny と gprd-cny の両方）へのデプロイメントはブロックされません。マイグレーションはカナリーデプロイメント中に実行されるため、ブロックされません。ただし、デプロイ後マイグレーションはブロックされます

7. ステージング環境へのデプロイメント

8. 環境の健全性を評価するための本番チェックが実行されます。健全と判断された場合、パイプラインは自動的に継続します

9. 本番環境へのデプロイメントはステージングより遅延して実行されます 各デプロイメントは Slack チャンネル #announcements に通知を送信します。 デプロイメントの一部として、release/tasks Issue トラッカーに QA Issue が作成され、変更が環境を通過していることをプロセスに関与する人々に通知します

デプロイ後マイグレーション（PDM）の実行

GitLab.com パッケージをロールバック可能にするために、デプロイ後マイグレーションは GitLab.com デプロイメントプロセスから独立しています。これらのマイグレーションは、デプロイ後マイグレーション（PDM）パイプラインを通じてステージングと本番環境で実行されます。PDM はリリースマネージャーが標準的な運用手順の一部として手動で実行します。本番インシデントのリスクを最小化しつつ、最小限のオーガニックトラフィックを確保するために、リリースマネージャーは APAC 営業終了と EMEA 営業開始の間の移行期間（おおよそ UTC 06:00 から 09:00 の間）に PDM 実行をスケジュールします。

標準的なサイクルは毎日実行ですが、実際の PDM 実行は GitLab.com の可用性に依存しており、重要なリリース管理プロセスに対応するために延期される場合があります。

• ソース

リリースマネージャーがデプロイ後マイグレーションパイプラインを実行する際の手順:

1. ステージングでデプロイ後マイグレーションスクリプトが実行されます
2. ステージングに対して QA テストが実行されます
3. QA 検証が成功した後、本番でデプロイ後マイグレーションスクリプトが実行されます。

このパイプラインの詳細はデプロイ後マイグレーションパイプラインのドキュメントにあります。

デプロイ後マイグレーションが実行されたかどうかを確認するには、このガイドをご覧ください。

デプロイメントロールバック

ロールバックはインシデントを軽減するための迅速かつ安全な方法です。以前のパッケージにロールバックすることでインシデントの原因を取り除きますが、修正がマージされ、パッケージ化され、デプロイ準備が整うまで以降のすべてのデプロイメントがブロックされます。リリースプロセスへの潜在的な混乱があるため、ロールバックを実行する権限を持つのはリリースマネージャーのみです。

ロールバックを決定する前に考慮すべき要素:

1. ロールバックは利用可能ですか？デプロイ後マイグレーションの最後の実行のパッケージにのみロールバックできます。適合性をテストするための chatops コマンドが利用可能です。
2. インシデントは機能フラグで緩和できますか？多くの新しい変更には機能フラグが含まれています。機能フラグを特定してオフにすることが通常最も速い緩和策です。
3. パッケージには数百の変更が含まれている可能性があり、ロールバックするとすべてが取り消され、特に月次リリース期限が近い場合は複数のチームに影響を与える可能性があることに注意してください。

ロールバックが引き起こす混乱のレベルのため、通常は S1 または S2 インシデントの場合にのみロールバックをオプションとして検討します。インシデント緩和オプションの評価に関するより詳細な情報はインシデントランブックにあります。

ロールバックを進めることを決定した場合、リリースマネージャーはロールバックランブックに従ってください。

ロールバックパイプライン

ロールバックは本質的に以前にデプロイされたパッケージの新しいデプロイメントです。以前にデプロイされたパッケージとして既に安定していることがわかっているため、ロールアウト全体のテストに費やす時間を安全に削減できます。

Gitaly と Praefect は GitLab Rails バージョンへの依存関係があるため、デプロイの逆順でロールバックする必要があります。これを実現するために、単純にデプロイメントパイプラインを再実行するのではなく、別のロールバックパイプラインを使用します。

ステージング環境のロールバックパイプラインの例:

デプロイメントブロッカー

インシデントによるデプロイメントのブロック

警告: blocks deployments フラグがアクティブな場合、マイグレーション（デプロイ後マイグレーション以外）は引き続き実行されます。詳細は blocks deployments フラグは何をするのか？をご覧ください。

誰でも本番へのデプロイメントを停止またはブロックできます。方法は以下のとおりです。

1. インシデントを宣言する（インシデントとして）:

   • severity1 または severity2 インシデントを宣言すると、デフォルトで デプロイメントがブロックされます。
   • severity3 および severity4 を宣言すると、「Blocks Deployments」 はデフォルトで 「no」 になります。
   • severity3 以下から severity2 以上へ変更すると、手動で変更されていない限り、「Blocks Deployments」 フラグが設定されます。
   • severity2 未満に重大度を下げると、手動で変更されていない限り、フラグが解除されてデプロイメントが許可されます。

2. インシデント Slack チャンネルから /incident field コマンドを実行してカスタムフィールドを更新し、Block Deployments で 「Yes」 を選択します。

3. #releases チャンネルでリリースマネージャーに通知します。

blocks deployments フラグは何をするのか？

blocks deployments フラグが設定されている場合:

• カナリーデプロイメントは継続: ステージングカナリー（gstg-cny）および本番カナリー（gprd-cny）へのデプロイメントはブロックされません
• マイグレーションはブロックされません: データベースマイグレーションはカナリーデプロイメントの一部として実行されます。マイグレーションをブロックしたい場合は、リリースマネージャーに連絡してください
• メイン環境へのプロモーションはブロック: ステージング（gstg）と本番（gprd）へのプロモーションが防がれます
• デプロイ後マイグレーションはブロック: デプロイ後マイグレーションパイプラインがブロックされます

この設計により、メイン環境へのプロモーションにのみデプロイプレッシャーを生じさせながら、コード変更とマイグレーションの継続的な検証が確保されます。

変更ロック期間中のデプロイメントのブロック

さらに、すべての本番環境（[カナリー]を含む）への自動デプロイメントは、変更ロック期間中に停止されます。現在、変更ロック期間は毎週金曜日 23:00 UTC から月曜日 06:00 UTC の間と、スケジュールされた本番変更期間中です。

変更ロック期間中は、デプロイメントが severity::1 の可用性またはセキュリティの Issue を修正する場合、GitLab ChatOps を通じて手動デプロイメントをトリガーできます。

以下のイベントにより本番へのデプロイメントがブロックされます。

1. blocks deployment ラベル付きのアクティブなインシデント
2. blocks deployment ラベル付きの進行中の変更 Issue
3. ステージングカナリー（gstg-cny）、ステージング（gstg）、本番カナリー（gprd-cny）、本番（gprd）を対象とするブロッキング（smoke および reliable）の自動エンドツーエンドテストの失敗

リリースマネージャーは 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 でリリースマネージャーにも通知してください。

デプロイ後マイグレーションの問題が見つかりました。次は何をすればよいですか？

デプロイ後マイグレーションが GitLab.com で実行されないようにするには、すぐにデプロイメントブロッカーの手順に従い、リリースマネージャーに通知してください。月次リリースに含まれないように、デプロイ後マイグレーションを元に戻す作業を進めてください。

リソース

ページのソースコードを見る - ページの編集 - please contribute.