GitLab リリース

プロダクトのリリース情報をお探しですか？リリースポスト、リリースページ、What’s new、changelog、または機能と非推奨の概要を参照してください。

概要

GitLab には 3 つの異なるリリースタイプがあります:

1. マンスリーリリース: 毎月第 3 木曜日に公開される GitLab バージョン（XX.YY.0）で、GitLab.com へのデプロイが成功した新機能、バグ修正、パフォーマンス改善を含みます。
2. パッチリリース: メンテナンス対象バージョン向けのバグ修正とセキュリティ更新で、月に 2 回公開されます。
3. 内部リリース: 是正 SLA 内で GitLab Dedicated に高重大度の修正を提供するためのプライベートリリース。

リリースポリシー

なぜリリースポリシーが重要なのか

GitLab はセマンティックバージョニングに従っており、これは私たちの顧客との契約を確立します:

• MAJOR バージョンには破壊的変更が含まれる場合があります
• MINOR バージョンには新機能が含まれます（後方互換性あり）
• PATCH バージョンにはバグ修正のみが含まれます（自動アップグレードが安全）

顧客はこの契約に基づいてアップグレードの判断を行います。多くの顧客は、パッチにはバグ修正のみが含まれることを信頼しているため、広範なテストを行わずにパッチリリースを自動アップグレードします。私たちがこの契約に違反すると、次のことが起こります:

• リリースプロセス全体に対する顧客の信頼を損なう
• 予期しない変更で顧客の環境をリスクにさらす
• 顧客が計画のために頼りにしているリリースの予測可能性を弱める
• 急いだリリースが追加のパッチを必要とする新しいバグを導入したときに連鎖的な問題を生み出す

各リリースタイプに含まれるもの

バグおよびセキュリティ修正のタイムラインに関する SLO/SLA コミットメントについては、パッチリリースの SLO/SLA コミットメントを参照してください。

期限を逃したときのオーナーシップ

機能がマンスリーリリースの期限を逃した場合、適切なパスはリリースポリシーへの例外ではなく、次のマンスリーリリースです。

リリースマネージャーは、逃した期限への対応をオーナーとして引き受けることはありません。

例外プロセス

[!IMPORTANT] 承認されたすべての例外には、Feature Change Lock (FCL) とリリース後のインシデントレビューが必要です。これらは任意ではありません。

リリースポリシーへの例外はまれであり、Release チーム外での明示的な承認が必要です。

リリースマネージャーは、リリースポリシーに違反するリクエストを却下する権限を持ちます。 Customer Success、Sales、その他のチームからのプレッシャーは、ポリシー例外の承認を構成しません。

例外が必要だと考えられる場合:

1. リクエスト者がビジネス上の正当性と顧客への影響評価を文書化する
2. リクエスト者がプラットフォームの安定性を保護するために Feature Change Lock (FCL) を開始する（必須）
3. リクエスト者がスポンサーシップを得るために自分の Director/VP にエスカレーションする。承認するリーダーはポリシー違反についての書面による承認確認を提供する
4. スポンサーとなる Director/VP が Delivery/Platforms 組織内のエンジニアリングリーダーシップに例外を要請する:
   • バックポート例外（N-3+）: Senior Engineering Manager 以上
   • アウトオブバンドリリース: Director of Infrastructure (Delivery Enablement) 以上
   • ポリシー違反（パッチ内の機能、マンスリーのやり直し）: VP of Engineering, Infrastructure Platforms 以上
5. リリースマネージャーは書面による承認を受け取った後にのみ実行する
6. リリース後: 例外リクエストの根本原因に対処するためのインシデントレビュー（必須）

このプロセスなしで承認された例外は、すべてのリリースポリシーを損なう前例を作ります。

エスカレーションパス

リリースの調整

関与するチーム

コミュニケーション

• #releases（Slack）: リリースのステータスと質問
• リリースポスト: 公開アナウンス

メンテナンスポリシー

詳細については GitLab メンテナンスポリシーを参照してください

用語

• メンテナンスポリシー: self-managed ユーザー向けのメジャー、マイナー、パッチリリースのリリースペースを説明します。
• 今後のバージョン: 開発中の新しい GitLab リリース（XX.YY.0）。
• メンテナンス対象バージョン: メンテナンスポリシーの対象となる GitLab バージョン。
• バックポート: 最近のバージョンからのバグまたはセキュリティ修正で、古いバージョンに適用されるもの。
• 安定版ブランチ: 顧客に提供される GitLab リリースパッケージのソース。
• 自動デプロイ: アプリケーションの変更を GitLab.com にデプロイする GitLab プロセス。
• リリースマネージャー: GitLab リリースと GitLab.com へのデプロイの DRI。

リソース

マンスリーリリース

• マンスリーリリースのスケジュールとプロセス
• いつまでに MR をマージする必要がありますか？
• 自分の MR が含まれるかどうかをどうやって確認できますか？

パッチリリース

• パッチリリースのプロセスとポリシー
• エンジニア向けパッチリリース runbook
• エンジニア向けセキュリティ runbook

内部リリース

• 内部リリースプロセス
• エンジニア向け内部リリース runbook

リンク

• リリースマネージャーのスケジュール
• Release and Deploy チームへの連絡方法

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