マンスリーリリース

マンスリーリリースポリシー

マンスリーリリースは、セルフマネージドのお客様に新機能、バグ修正、パフォーマンス改善を提供するための手段です。パッチリリースや内部リリースとは異なり、マンスリーリリースには新しい機能を含めることができます。

所有権、例外プロセス、エスカレーションパスを含む一般的なリリースポリシーのフレームワークについては、リリースポリシーセクションを参照してください。

マンスリーリリースの概要

マンスリーリリースは、GitLab.com への多数のデプロイからの変更を含む semver バージョン管理されたパッケージです。したがって GitLab.com のユーザーは、セルフマネージドのインストールのユーザーよりも早く機能とバグ修正を受け取ります。

デプロイとリリースのページ では、2 つのプロセスがどのように連携して機能するかを詳しく説明しています。

他のリリースタイプとの関係

マンスリーリリースは、他のすべてのリリースタイプの基盤を作成します。

• ステーブルブランチ はリリース候補がタグ付けされるときに作成され、パッチリリースおよび内部リリースの基盤となります
• パッチリリース はこれらのステーブルブランチからカットされ、セルフマネージドのお客様にバグおよびセキュリティ修正を提供します
• 内部リリース は同じステーブルブランチを使用して、公開前に GitLab Dedicated にクリティカルな修正を提供します

マンスリーリリーススケジュール

マンスリーリリースプロセス

マンスリーリリースのタイムラインは リリース日 を中心に集中しています。

マンスリーリリースプロセスに含まれる手順の概要:

• ダイアグラムソース

エンドツーエンドのプロセスは以下のステージで構成されています。

1. 最初のステップ - マンスリーリリースのセットアップを行う初期ステップ。リリーススケジュールとデプロイケイデンスの設定を含みます。
2. GitLab.com へのデプロイ - マイルストーンの開始からリリース日の 1 週間前まで、GitLab.com は 1 日に複数回のデプロイを受けます。アプリケーションの変更がマンスリーリリースに含まれるためには、GitLab.com に正常にデプロイされる必要があります。
3. リリース候補 - テスト用 リリース候補 (RC) が、対象とする semver バージョンのステーブルブランチとともに作成されます。リリース候補パッケージがビルド、テストされ、pre 環境 にデプロイされます。成功した結果は、このパッケージが最終バージョンとして使用できることを示します。この時点で リリースマネージャー がリリースに含まれる最終コミットをアナウンスします。
4. タグ - リリースマネージャーがリリース候補に基づいて最終バージョンにタグを付けます。
5. リリース - リリース日に、リリースパッケージが公開されます。

リリース手順

リリース準備 (リリース週の火曜日まで含む)

これは変更を検証し、バグに対処し、リリースされる予定のものの安定性を確保するためのウィンドウを提供します。 最初の RC をカットすることが、そのバージョンのステーブルブランチが作成されるタイミングです。 発生するバグに対処するために多くの RC が作成されることがあります。 最初の RC が作成されると、バグはステーブルブランチに直接ポートする必要があることに注意してください。 この段階では新しい機能は含まれません。

タグ付け日 (第 3 水曜日)

この日が引き返せない地点です。 タグが作成されると、それは不変です。 リリースのためのすべての変更が確定されます。

リリース日 (第 3 木曜日)

タイムライン

リリースサイクル全体を通じて保証される唯一の日付は リリース日 です。この日に、マンスリーリリース がリリースアナウンスとともに公開されます。

その他の日付はすべて、ガイドラインのみ であり、いかなるタイプのリリースに含まれるものに関して期限とは見なせません。これには 開発月 とそこで定義された日付、および顧客への約束も含まれます。これは厳密には、セキュリティ関連の Issue を含む最優先度かつ最高重大度の Issue への対応など、リリースの準備に考慮すべき多くの要素があるためです。

特定のバージョンに特定の機能を絶対に間に合わせる必要がある場合は、開発サイクルの早い段階で機能をマージしてください。 リリース日の近くでのマージは、その特定の マンスリーリリース に含まれることは絶対に保証されません。

マージリクエストがマンスリーリリースに含まれるかどうかをどのように判断できますか？

マージリクエストが次のマンスリーリリースに含まれるかどうかを判断するために、複数のツールが利用可能です。このセクションでは、参照しやすいよう利用可能なすべてのツールをまとめています。

利用可能なツール

1. マージリクエストのラベル
2. マージリクエストウィジェット
3. ChatOps コマンド
4. リリースダッシュボード
5. Slack の #releases チャンネルのアナウンス

次回マンスリーリリースへの包含を示すラベル

リリース候補 (RC) に含まれたマージリクエストは、マンスリーリリースの一部になります。リリース候補の詳細については 「リリース候補とは何ですか？ いつ作成されますか？」 を参照してください。マージリクエストは、RC への包含を示すために released::candidate ラベルを受け取ります。

マージリクエストが 13.6.0 や 13.5.2 などの最終リリースに含まれると、released::candidate ラベルを置き換える released::published ラベルを受け取ります。

マージリクエストウィジェット

マージリクエストウィジェットは、すべてのマージリクエストの環境とデプロイ時間を表示します。 これにより、マージリクエストがリリースプロセスのどこにあるかを理解するための情報が提供されます。

• release はセルフマネージドユーザーに公開される最終バージョン用です。MR が最終リリースに含まれると、次のマンスリーリリースに含まれることを示すために released::published ラベルが MR に適用されます。
• pre はリリース候補、およびセルフマネージドユーザー向け最終リリースの準備として使用されるバージョン用です。MR がリリース候補に含まれると、次のマンスリーリリースに含まれることを示すために released::candidate ラベルが MR に適用されます。

マージリクエストウィジェットは、デプロイプロセスのどこにあるかを参照するためにも使用できます。

• gstg-cny は GitLab SaaS ステージング環境の カナリアステージ です
• gprd-cny は GitLab SaaS 本番環境の カナリアステージ です
• gstg は GitLab SaaS のステージング環境です - staging.gitlab.com
• gprd は GitLab SaaS の本番環境です - GitLab.com
• db/gstg はマージリクエストに含まれるポストマイグレーションがステージング環境で実行されたことを示します。
• db/gprd はマージリクエストに含まれるポストマイグレーションが本番環境で実行されたことを示します。

ウィジェットに環境が表示されない場合、MR はまだいずれの環境にもデプロイされていません。

ChatOps コマンド

GitLab チームメンバーは Slack の #releases チャンネルで ChatOps コマンドを使用して、マージリクエストのステータスを確認できます。

マンスリーリリースに関する MR ステータスの確認

マンスリーリリースに関する MR のステータスを確認するために使用できる ChatOps コマンドがあります。

/chatops run release check <MR URL> <upcoming release version (optional)>

例: /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 つのシナリオ:

1. MR が最初にリリースされたバージョンを確認する: /chatops run release check <MR URL> (バージョンを省略した場合、MR がすでにリリースされているかどうかのみ確認します)

2. 次回マンスリーリリースに MR が含まれる可能性を確認する: /chatops run release check <MR URL> <upcoming release version>

マンスリーリリース情報ダッシュボード

GitLab チームメンバーは 内部 Grafana ダッシュボード「Release Information」 で以下の情報を確認できます。

• 次回マンスリーリリースのバージョン
• 次回マンスリーリリースの日付
• 次回マンスリーリリースの期日
• 次回マンスリーリリースの現在のステータス

マンスリーリリースに 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 チャンネルのいずれかに参加することが最善の方法です。

• #releases
• #f_upcoming_release

リリース候補は、自動テストと手動テストの両方のために pre.gitlab.com にデプロイされます。

リリースマネージャーに依頼すれば、より早くリリース候補を作成してもらえますか？

リリース候補をいつ作成するかは、デプロイメントと GitLab.com の状態を考慮した上で、リリースマネージャーが決定します。

リリース関連の質問やリクエストについて、リリースマネージャーに個人的にメッセージを送らないでください。代わりに、#releases チャンネルにリクエスト／質問を投稿してください。

マンスリーリリースに含まれるためには、いつまでに MR をマージする必要がありますか？

[!WARNING] ⚠️ MR がマンスリーサイクルの早い段階でマージされるほど、そのマンスリーリリースに含まれる可能性が高くなります。

マンスリーリリースに MR を含めるための目標期日: リリース手順が始まる日の前日 16:00 UTC (通常は リリース日 の 2 日前)。

全員が提供するものの品質と安定性が、マンスリーリリースに含まれる MR の最終リストを決定します。GitLab.com が安定している場合、リリースの 2 日前にマージされた MR が含まれる可能性があります。いずれかのチームの変更によって安定性が低下している場合、リリースの 1 週間前にマージされた MR でも含まれない可能性があります。

期日前に MR が正常にデプロイされた場合でも、以下の理由でリリースに含まれない可能性があります。

• GitLab.com 上の いずれかの 変更がインシデントやロールバックを引き起こす
• GitLab.com が他の MR の影響で安定性の問題を経験する
• 問題のある変更とともにあなたの変更がロールバックされる

MR がリリースに含まれるためには、以下が必要です。

1. デフォルトブランチに マージ されている
2. GitLab.com 本番環境に正常に デプロイ されている
3. ロールバックされずに デプロイされ続けている

MR のリアルタイムステータスについては、利用可能なツール を使用してください。

高重大度のバグ修正をリリースするにはどうすればよいですか？

高重大度の Issue は、適切なバグおよび重大度ラベルを付けた Issue から始める必要があります。

バグの詳細に応じて、以下のいずれかのプロセスに従ってください。

• 高重大度のセキュリティバグ の場合
• セルフマネージドユーザーに影響する高重大度のバグ の場合。バグがその月の リリース日 の近くに発見された場合は、#releases のリリースマネージャーにも通知してください。
• GitLab.com に影響する高重大度のバグ の場合
• セキュリティマージリクエストによって引き起こされる高重大度のバグ の場合
• Dedicated に影響する高重大度のバグ の場合

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