マンスリーリリース
マンスリーリリースポリシー
マンスリーリリースは、セルフマネージドのお客様に新機能、バグ修正、パフォーマンス改善を提供するための手段です。パッチリリースや内部リリースとは異なり、マンスリーリリースには新しい機能を含めることができます。
所有権、例外プロセス、エスカレーションパスを含む一般的なリリースポリシーのフレームワークについては、リリースポリシーセクションを参照してください。
マンスリーリリースの概要
マンスリーリリースは、GitLab.comへの多数のデプロイからの変更を含むsemverバージョン管理パッケージです。したがって、GitLab.comのユーザーは、セルフマネージドインストールのユーザーよりも早く機能とバグ修正を受け取ります。
デプロイとリリースページでは、2つのプロセスがどのように連携して機能するかを詳しく説明しています。
他のリリースタイプとの関係
マンスリーリリースはすべての他のリリースタイプの基盤を作成します。
- ステーブルブランチはリリース候補がタグ付けされるときに作成され、パッチリリースと内部リリースの基盤となります
- パッチリリース はこれらのステーブルブランチからカットされ、セルフマネージドのお客様にバグとセキュリティ修正を提供します
- 内部リリース は同じステーブルブランチを使用して、公開前にGitLab Dedicatedにクリティカルな修正を提供します
マンスリーリリーススケジュール
リリーススケジュールは 原文 (英語) を参照してください。
マンスリーリリースプロセス
マンスリーリリースのタイムラインはリリース日を中心に集中しています。
マンスリーリリースプロセスに関わる手順の概要：
エンドツーエンドのプロセスは以下の段階で構成されています。
- 最初のステップ - マンスリーリリースのセットアップ、リリーススケジュールとデプロイケイデンスの設定を含む初期ステップ。
- GitLab.comへのデプロイ - マイルストーンの開始からリリース日の1週間前まで、GitLab.comは1日に複数回デプロイを受け取ります。アプリケーションの変更がマンスリーリリースに含まれるためには、GitLab.comに正常にデプロイされる必要があります。
- リリース候補 - テスト用リリース候補（RC）が作成され、対象とするsemverバージョンのステーブルブランチとともに作成されます。リリース候補パッケージがビルドされ、テストされ、pre環境にデプロイされます。成功した結果は、このパッケージが最終バージョンとして使用できることを示します。この時点でリリースマネージャーがリリースに含まれる最終コミットをアナウンスします。
- タグ付け - リリースマネージャーがリリース候補に基づいて最終バージョンにタグを付けます。リリースがビルドされ、リリース環境にデプロイされます。
- リリース - リリース日に、リリースパッケージが公開されます。
リリース手順
リリース準備（リリース週の火曜日まで）
これは変更を検証し、バグに対処し、リリースされる予定のものの安定性を確保するためのウィンドウを提供します。 最初のRCをカットすることが、そのバージョンのステーブルブランチが作成されるタイミングです。 発生するバグに対処するために多くのRCが作成されることがあります。 最初のRCが作成されると、バグはステーブルブランチに直接ポートする必要があることに注意してください。 この段階では新しい機能は含まれません。
| ステップ | 目的 |
|---|---|
| オートデプロイ | リリース週の火曜日まで1日に複数回実行されます。リリース前の問題を検証し、修正する機会を提供します。 |
| RC作成 | お客様が受け取るパッケージに似たパッケージをビルドします。ビルド手順の検証、タグビルド時と同様の手順。受信インスタンスでQAが実行され、さらに検証が行われます。 |
タグ付け日（第3水曜日）
この日が引き返せない地点です。 タグが作成されると、それは不変です。 リリースのためにすべての変更が確定されます。
| ステップ | 目的 |
|---|---|
| バージョンタグ付け | 公式バージョンタグの作成（例：18.8.0） |
| パッケージビルド | すべてのプラットフォーム向けOmnibusパッケージのビルド |
| コンテナイメージビルド | CE、EE、UBI、FIPSコンテナイメージのビルド |
| QAアップデートシナリオ | 以前のバージョンからのアップグレードパスのテスト |
| プレリリース検証 | すべてのパッケージの最終検証 |
リリース日（第3木曜日）
| ステップ | 目的 |
|---|---|
| リリース公開 | パッケージの公開とリリースのアナウンス（13:00 UTC） |
| リリース後の検証 | パブリックリポジトリでのパッケージの可用性確認 |
| リリースの確定 | トラッキングシステムの更新とリリースのクローズ |
タイムライン
リリースサイクル全体を通じて保証される唯一の日付はリリース日です。この日に、マンスリーリリースはリリースアナウンスとともに公開されます。
その他の日付はすべて、ガイドラインのみであり、いかなるタイプのリリースに含まれるものに関して期限とは見なせません。これには開発月とそこで定義された日付、および顧客への約束も含まれます。これは厳密には、セキュリティ関連の問題を含む最優先度および最高重大度の問題に取り組むことを含め、リリースの準備に考慮すべき多くの要素があるためです。
特定のバージョンに特定の機能が絶対に必要な場合は、開発サイクルの早い段階で機能をマージしてください。
リリース日の近くでのマージは、その特定のマンスリーリリースに含まれることは絶対に保証されません。
マージリクエストがマンスリーリリースに含まれるかどうかをどのように判断できますか？
マージリクエストが次のマンスリーリリースに含まれるかどうかを判断するために、複数のツールが利用可能です。このセクションでは、参照しやすいよう利用可能なすべてのツールをまとめています。
利用可能なツール
次回のマンスリーリリースへの包含を示すラベル
リリース候補（RC）に含まれたマージリクエストはマンスリーリリースの一部になります。リリース候補に関する詳細は“リリース候補とは何ですか？いつ作成されますか？”を参照してください。マージリクエストはRCへの包含を示すためにreleased::candidateラベルを受け取ります。
マージリクエストは13.6.0や13.5.2などの最終リリースに含まれ、release.gitlab.netにデプロイされると、released::candidateラベルを置き換えるreleased::publishedラベルを受け取ります。
マージリクエストウィジェット
マージリクエストウィジェットは、すべてのマージリクエストの環境とデプロイ時間を表示します。 これにより、マージリクエストがリリースプロセスのどこにあるかを理解するための情報が提供されます。
releaseはセルフマネージドユーザーに公開される最終バージョンのためです。MRがrelease.gitlab.netインスタンスにデプロイされると、次のマンスリーリリースに含まれることを示すためにreleased::publishedラベルがMRに適用されます。preはリリース候補とセルフマネージドユーザーへの最終リリースの準備に使用されるバージョンのためです。MRがリリース候補に含まれると、次のマンスリーリリースに含まれることを示すためにreleased::candidateラベルがMRに適用されます。
マージリクエストウィジェットは、デプロイプロセスのどこにあるかを参照するためにも使用できます。
gstg-cnyはGitLab SaaSステージング環境のカナリアステージですgprd-cnyはGitLab SaaS本番環境のカナリアステージですgstgはGitLab SaaSのステージング環境です - staging.gitlab.comgprdはGitLab SaaSの本番環境です - GitLab.comdb/gstgはマージリクエストに含まれるポストマイグレーションがステージング環境で実行されたことを示します。db/gprdはマージリクエストに含まれるポストマイグレーションが本番環境で実行されたことを示します。
ウィジェットに環境が表示されない場合、MRはまだいずれの環境にもデプロイされていません。
ChatOpsコマンド
GitLabチームメンバーはSlackの#releasesチャンネルでChatOpsコマンドを使用して、マージリクエストのステータスを確認できます。
マンスリーリリースに関するMRステータスの確認
マンスリーリリースに関するMRのステータスを確認するために使用できるChatOpsコマンドがあります。
/chatops run release check <MR URL> <次回リリースバージョン（オプション）>
例: /chatops run release check https://gitlab.com/gitlab-org/gitlab/-/merge_requests/12345 14.4
gitlab-org/gitlab、gitlab-org/security/gitlab、gitlab-org/omnibus-gitlabおよびgitlab-org/security/omnibus-gitlabプロジェクトのMRがこのコマンドでサポートされています。
このコマンドが役立つ2つのシナリオ:
MRが最初にリリースされたバージョンを確認する:
/chatops run release check <MR URL>（バージョンが省略された場合、MRがすでにリリースされているかどうかのみ確認します）次回のマンスリーリリースにMRが含まれる可能性を確認する:
/chatops run release check <MR URL> <次回リリースバージョン>
マンスリーリリース情報ダッシュボード
GitLabチームメンバーは内部Grafanaダッシュボード「リリース情報」で以下の情報を確認できます。
- 次回のマンスリーリリースバージョン
- 次回のマンスリーリリース日
- 次回のマンスリーリリースの期日
- 次回のマンスリーリリースの現在のステータス
マンスリーリリースにMRを含めるための期日は、最初のリリース候補とステーブルブランチが作成されるタイミングに設定されています。その時点以降、マンスリーリリースにはこれ以上の機能は含まれません。
マンスリーリリースダッシュボードには、デプロイされたMRを受け入れているオープン状態か、すでにクローズされて新しい機能を追加できないかを示す現在のステータスを説明するパネルも含まれています。
この情報を表示するために使用されるメトリクスは、マンスリーリリースプロセス全体を通じて自動的に更新されます。
Slackの#releasesチャンネルのアナウンス
リリース日の直前に、リリースマネージャーはリリースに含まれる最終コミットをアナウンスします。このような通知はSlackの#releasesチャンネルで共有され、次のようになります（フォーマットはrelease-toolsマンスリーテンプレートで定義されています）。
📣 ステーブルブランチが作成され、リリース候補にタグが付けられました。重大な問題がなければ、これが21日にリリースされる最終コミットです。https://gitlab.com/gitlab-org/security/gitlab/-/commits/18-3-stable-ee
マンスリーリリースに含まれたマージリクエストは包含を示すラベルを受け取ります。
よくある質問
リリースXのリリースマネージャーは誰ですか？
GitLab リリースマネージャースケジュールを確認することで分かります。
リリース候補とは何ですか？いつ作成されますか？
リリース候補（RC）とは、変更がリバートされる必要があるまれなケースを除いて、最終マンスリーリリースに含まれる変更を含むGitLabパッケージです。RCはマンスリーリリースにのみ作成され、パッチリリースには作成されません。通常、リリースごとに1つのRCが作成されますが、GitLab.comの状態に基づいてさらにRCが作成される場合があります。
リリース候補はリリース日の2日前の最終リリースの直前に作成されます。必要な場合は、より早くリリース候補を作成することもあります。これは以下のような要因に依存します。
- GitLab.comで進行中または進行していたインシデント（リリース直前の場合）。
- リリースマネージャーの注意を必要とするパッチリリース（クリティカルなもの）。
- オートデプロイパイプラインの問題。
- リリース候補の作成を遅延または妨げる可能性のある他のリリース関連作業。
つまり、リリース候補がいつ作成されるかを知りたい場合は、以下のSlackチャンネルのいずれかに参加することが最善の方法です。
リリース候補は、自動テストと手動テストの両方のためにpre.gitlab.comにデプロイされます。
リリースマネージャーに依頼すれば、より早くリリース候補を作成してもらえますか？
リリース候補をいつ作成するかは、デプロイメントとGitLab.comの状態を考慮した上で、リリースマネージャーが決定します。
リリース関連の質問やリクエストについて、リリースマネージャーに個人的にメッセージを送らないでください。代わりに、#releasesチャンネルにリクエスト/質問を投稿してください。
マンスリーリリースに含まれるためにMRをいつマージする必要がありますか？
[!WARNING] ⚠️ MRがマンスリーサイクルの早い段階でマージされるほど、そのMRがそのマンスリーリリースに含まれる可能性が高くなります。
マンスリーリリースにMRを含めるための目標期日: リリース手順が始まる日の前日の16:00 UTC（通常はリリース日の2日前）。
全員が提供するものの品質と安定性が、マンスリーリリースに含まれるMRの最終リストを決定します。GitLab.comが安定している場合、リリースの2日前にマージされたMRが含まれる可能性があります。いずれかのチームの変更によって安定性が低下している場合、リリースの1週間前にマージされたMRでも含まれない可能性があります。
期日前にMRが正常にデプロイされた場合でも、以下の理由でリリースに含まれない可能性があります。
- GitLab.comでいずれかの変更がインシデントやロールバックを引き起こす
- 他のMRによるGitLab.comの安定性の問題
- 問題のある変更とともにあなたの変更がロールバックされる
MRがリリースに含まれるためには、以下が必要です。
- デフォルトブランチにマージされている
- GitLab.com本番環境に正常にデプロイされている
- ロールバックされずにデプロイされ続けている
MRのリアルタイムのステータスについては、利用可能なツールを使用してください。
高重大度のバグ修正をリリースするにはどうすればよいですか？
高重大度の Issue は、適切なバグと重大度ラベルを付けた Issue から始める必要があります。
バグの詳細に応じて、以下のいずれかのプロセスに従ってください。
- 高重大度のセキュリティバグの場合
- セルフマネージドユーザーに影響する高重大度のバグの場合。バグがリリース月のリリース日の近くに発見された場合は、#releasesのリリースマネージャーにも通知してください。
- GitLab.comに影響する高重大度のバグの場合
- セキュリティマージリクエストによって引き起こされる高重大度のバグの場合
- Dedicatedに影響する高重大度のバグの場合
