パッチリリース

パッチリリースポリシー

パッチリリースはセマンティックバージョニングに従います: パッチバージョンにはバグ修正のみが含まれ、自動アップグレードが安全です。多くの顧客は、この保証を信頼しているため、最小限のテストでパッチリリースを適用します。

パッチリリースに含まれるもの

• メンテナンスポリシーに従ったバグおよびセキュリティ修正
• パフォーマンスリグレッションの修正

パッチリリースに含まれないもの

• 新機能またはフィーチャーフラグの有効化
• 「出荷が必要」な未完成の作業
• マンスリーリリースの期限を逃したために要請された変更

このポリシーは顧客を保護するために存在します。ビジネス上のプレッシャーに基づいて交渉できるものではありません。オーナーシップ、例外プロセス、エスカレーションパスを含む一般的なリリースポリシーのフレームワークについては、リリースポリシーのセクションを参照してください。

なぜ機能をバックポートできないのか

セマンティックバージョニングの契約を超えて、機能をパッチリリースに含めてはならない実用的なエンジニアリング上の理由があります: stable ブランチがデフォルトブランチから分岐すると、バックポートが信頼できなくなります。

機能がパッチリリースに導入されると:

• 新しいバグ修正が誤って stable バージョンに導入される可能性があり、安定化したと信じていた本番環境で顧客が新しいバグに遭遇するリスクが高まります。
• 顧客の信頼が損なわれ、彼らはもはや自信を持ってアップグレードを計画したり、私たちのリリースコミットメントに頼ったりできなくなり、重大な修正が含まれている場合でもアップデートの採用をためらうようになります。
• stable ブランチが予測できない形でデフォルトブランチから分岐します
• 周囲のコードが異なるため、将来のバグ修正がクリーンにチェリーピックできない場合があります
• エンジニアは各バージョンに対して手動で修正を適応させる必要があり、エラーのリスクが高まります
• 本来はルーチンのバックポートであるべきものが、カスタム開発作業になります

これは複合的な問題を生み出します。各機能例外が、後続のバックポートをより難しく、遅く、エラーが起きやすくします。 ポリシー違反のたびにメンテナンスの負担が増大し、最終的にはすべての顧客にタイムリーなセキュリティおよびバグ修正を提供する私たちの能力に影響します。

パッチリリースの概要

パッチリリースは、メンテナンス対象バージョンにバグ修正とセキュリティ修正をバックポートするために、GitLab メンテナンスポリシーに従って実行されます。

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

パッチリリースは、マンスリーリリース中に作成された stable ブランチの上に構築されます:

• 修正は、パッチリリースに含める前に、まず GitLab.com にデプロイされなければなりません
• バックポートはメンテナンス対象バージョンの stable ブランチを対象とします
• パッチリリースに含まれるセキュリティ修正は、内部リリースを通じて GitLab Dedicated により早く提供される場合もあります

メンテナンスポリシー外のパッチは、Release Managers とリクエスト者によって要請され合意される必要があります（詳細についてはメンテナンスポリシー外のバージョンへのバックポートを参照してください）。メンテナンス対象バージョンのリストを参照してください。

パッチリリースは、継続的デプロイがブロックされないように、通常の GitLab.com のデプロイと並行して準備されます。このようにして、公開リリースの前に GitLab.com インスタンスにセキュリティ修正を適用できます。

GitLab エンジニアで以下を行いたい場合:

• パッチリリースにセキュリティ修正を含めるには、GitLab エンジニア向けセキュリティランブックの手順に従ってください。
• パッチリリースにバグ修正を含めるには、GitLab エンジニア向けパッチリリースランブックの手順に従ってください。GitLab およびその依存関係のセキュリティ脆弱性は、セキュリティ是正 SLAに従って対処されます。

バグ修正は GitLab の canonical リポジトリで作業されますが、セキュリティ修正は、リリース前に脆弱性が明らかになるのを避けるため、ミラーリングされた GitLab security リポジトリで作業されます。例外は、公開済みの CVE またはベンダーアドバイザリですでに扱われている脆弱性を是正する、依存関係のみのバージョン更新です。これらは、アプリケーション脆弱性管理手順の依存関係のバージョン更新ガイダンスに従う場合、canonical リポジトリで実装できます。

バックポートの準備をしたい GitLab チームメンバーは、パッチリリース情報ダッシュボードを参照してください。

パッチリリースのケイデンス

パッチリリースは月に 2 回、マンスリーリリース（第 3 木曜日）の前後の水曜日を目標にスケジュールされます。正確な日付は毎月異なり、運用上のニーズに基づいて変動する可能性のあるベストエフォートの目標です。

今後のパッチリリース日については、リリース情報ダッシュボード（内部）を確認してください。

SLO コミットメント

計画されたパッチリリースは、緊急リリースを必要とせずに目標リリース日を満たすようにスケジュールされます。

• 詳細なセキュリティ脆弱性是正 SLA については、セキュリティ是正 SLAを参照してください。
• 詳細なバグ脆弱性是正 SLA については、バグ是正 SLAを参照してください。

パッチリリースのタイプ

GitLab には、2 種類のパッチリリースプロセスがあります:

1. 定期スケジュール（デフォルト）: GitLab メンテナンスポリシーに従って、利用可能なすべてのバグおよび脆弱性修正を公開する SLO 駆動のパッチ。 マンスリーリリース週の前後の水曜日に月に 2 回スケジュールされ、計画されたパッチは バグ SLOと セキュリティ是正 SLAに準拠します。 critical 脆弱性を含むパッチは、critical パッチとみなされます。

2. アウトオブバンド: 通常のパッチリリースのケイデンス外で行うパッチで、 高重大度のバグまたは critical 脆弱性の緩和に厳密に限定されます。これらのアドホックな パッチは、期限の超過に対応したり、標準のリリースポリシーを回避したりするために使用してはなりません。 パッチリリースのケイデンスに従い、アウトオブバンドパッチは水曜日に提供されます。

   バグ修正かセキュリティ脆弱性かを問わず、すべてのアウトオブバンドパッチは次の要件を 満たす必要があります:

   • 例外プロセス: 例外リクエストは 必須であり、アウトオブバンドパッチを実行する前に従う必要があります。Release Managers は、 ビジネス上のプレッシャーに関係なく、このプロセスを完了していないリクエストを却下する権限を持ちます。
   • インシデント宣言: 次の属性を持つインシデントを宣言する必要があります:
     • 「Out-of-Band Patch」としてマークされている
     • Severity S1 または S2
     • Contributing Factor が「Inadequate testing or QA」または「Miscommunication or coordination gap」である
   • FCL とインシデントレビュー: あらゆる GitLab プラットフォームの信頼性と可用性を維持するため、 インシデントレビューと FCLを完了することが必須です。

   さらに、critical セキュリティ脆弱性の場合は、セキュリティ RCAが 必須であり、アウトオブバンドリリースを強いた脆弱性を導入した責任を負うチームが完了しなければなりません。 この説明責任に例外はありません。

パッチリリースのプロセス

パッチリリースのプロセスは、1 つの重要な違いを除いてすべてのタイプで同じです: 定期スケジュールのパッチには パッチリリース準備時点で準備が整っているすべてのバグおよびセキュリティ修正が含まれますが、アウトオブバンドパッチには 高重大度のバグまたは critical 脆弱性の修正のみが含まれる可能性があります。

エンドツーエンドのパッチリリースプロセスは、以下のステージで構成されます:

• 図のソース - 内部

任意の時点で、GitLab エンジニアはそれぞれのメンテナンス対象バージョンに対して バグ修正と脆弱性修正を準備します:

• ステップ 1a: バグ修正の準備 - メンテナンス対象バージョンにバグ修正をバックポートするマージリクエストが GitLab エンジニアによって準備されます:
  • マージリクエストは、バグ修正が品質基準を満たすことを保証するために、test-on-omnibus パイプラインを通じてエンドツーエンドテストを実行します。
  • test-on-omnibus パイプラインが失敗した場合、Developer Experience チームによるレビューが必要です。
  • マージリクエストは、メンテナンス対象バージョンに関連付けられた stable ブランチで GitLab メンテナーによってマージされます。
• ステップ 1b: 脆弱性修正の準備 - エンジニアは関連する Security リポジトリで脆弱性を修正します。修正は、以下を含むセキュリティ実装 Issueがある場合にのみ完了とみなされます:
  • すべてのステップが完了したことを示すために、すべてのチェックボックスがチェックされている。
  • デフォルトブランチを対象とした、PSIRT チームメンバーと Maintainer が承認した MR。
  • 各対象バージョンのバックポート MR。ほとんどの場合、これはサポートされている各バージョンをカバーするために 4 つの MR を意味します。各 MR はパイプラインが通過し、必要な承認があり、処理のためにリリースボットにアサインされていなければなりません。
  • ~"security-target" ラベルが適用されている。これにより、Issue が自動的にレビューされ、準備ができていればセキュリティトラッキング Issue にリンクされます。

計画された期日の 2 日前に、Release Managers はパッチリリースプロセスを開始し、 準備されたすべてのバグおよびセキュリティ修正が安全にリリースされることを確認します。GitLab.com へのデプロイは並行して実行されます。

パッチリリースには以下のフェーズがあります:

• ステップ 2: 最初のステップ リリース準備は、Release Managers が prepare chatops コマンドを実行して、パッチリリースを導く新しいリリースタスク Issue を作成したときに始まります。ここから、彼らはチェックリストに従って、リリースの準備に必要な初期セットアップとコミュニケーション Issue を完了します。
• ステップ 3: 早期マージフェーズ - Release Managers は GitLab.com にセキュリティ修正をデプロイします。セキュリティトラッキング Issue にリンクされた ~"security-target" ラベルを持つ修正は、デフォルトブランチを対象とした MR がマージされます。これにより、修正が self-managed ユーザーにリリースされる前に GitLab.com にデプロイできます。
• ステップ 4: バックポートのマージ - リリース期日の前日、サポートされているバージョンを対象とするセキュリティ修正を含むバックポートがマージされます。この時点で、パッチに含まれるすべてのものが GitLab.com にデプロイされていなければならず、バックポートはすべての stable ブランチに適用されなければなりません。
• ステップ 5: リリースの準備* - すべての修正がデプロイされマージされたら、Release Managers はパッケージを準備しテストします。
  • ステップ 5a: タグ付け - Release Managers はメンテナンス対象バージョン用の新しいパッチリリースパッケージにタグを付けます。
  • ステップ 5b: デプロイ - パッチリリースパッケージが GitLab リリースインスタンスにデプロイされテストされます。
  • ステップ 5c: リリース - Release Managers はパッチリリースに関連付けられたパッケージを公開します。
• ステップ 6: 最終ステップ - この時点で、パッチリリースパッケージはすべてのユーザーが利用可能です。Release Managers はパッチリリースの最終ステップを締めくくります。
  • ステップ 6a: パッチリリースのブログ記事が公開されます
  • ステップ 6b: デフォルトブランチ、stable ブランチ、タグが Security から Canonical に同期され、オープンに作業するデフォルトの状態に戻ります。

パッチリリース情報ダッシュボード

GitLab チームメンバーは、今後のパッチリリースに関する以下の情報について、内部 Grafana ダッシュボード「Release Information」を閲覧できます:

• 今後のパッチリリースバージョン（stable バージョン + 2 つのバックポートバージョン）
• 今後のパッチリリース日
• パッチリリースの現在のステータス
  • Open: security-target ラベルが付いたセキュリティ Issue に関連付けられた未マージのセキュリティ MR、およびマージされたバグ修正 MR は、次のパッチリリースに含まれることが期待されます。
  • Warning: チームがバグおよびセキュリティ修正をマージできる状態にすべきであることを示します。
  • Closed: デフォルトブランチのセキュリティ MR がマージされ、それ以上のバグまたはセキュリティ修正は含まれません。

この情報を表示するために使用されるメトリクスは、パッチリリースのプロセス全体を通じて自動的に更新されます。

パッチリリースの FAQ

次のパッチリリースにバグ修正をバックポートするにはどうすればよいですか？

パッチリリースにバグ修正を含めたい GitLab エンジニアは、GitLab エンジニア向けパッチリリースランブックの手順に従ってください。

次のパッチリリース情報はどこで確認できますか？

対象バージョン、予定日、ステータスを含むパッチリリース情報は、内部 Grafana のリリースダッシュボードで確認できます

セキュリティ Issue が私にアサインされました、どこから始めるべきですか？

詳細については、エンジニアとしてのセキュリティプロセスのドキュメントを参照してください。

なぜ私のセキュリティ修正はパッチリリースに含まれなかったのですか？

GitLab Security で作成されたセキュリティ Issue は、セキュリティリリースに含めるために、セキュリティトラッキング Issue に関連付けられる必要があります。セキュリティ Issue テンプレートを使用し、記載された手順に従ってください。

セキュリティ Issue に取り組む際、いくつのバックポートが必要ですか？

master を対象とするマージリクエストに加えて、それぞれのメンテナンス対象バージョンの stable ブランチを対象とするバックポートが必要になります。 詳細については、セキュリティバックポートを参照してください。

セキュリティマージリクエストを取り消すにはどうすればよいですか？

マージされたセキュリティマージリクエストの取り消しは強く推奨されませんし、PSIRT チームからの明示的な承認が必要です。セキュリティ修正のロールバックには深刻な結果があります:

1. ライブのセキュリティ保護を削除することで、GitLab.com、self-managed、Dedicated インスタンスの完全性を損ないます
2. 代替修正なしで取り消すと、リリースが公開された瞬間に脆弱性を公に開示するリスクがあります。これは容認できません
3. パッチリリースは厳しい時間的制約のもとで運用されます。リリースの遅延を避けるために代替修正を間に合わせて準備できる保証はありません

セキュリティ脆弱性が二次的なバグを導入した場合、対応はその重大度によって異なります:

• 脆弱性ではないバグ（S3 および S4）: 適切なパスは、通常のパッチリリースプロセスに従って、パッチリリースが公開された後に canonical リポジトリで Issue を修正することです。
• 脆弱性ではないバグ（高重大度: S1 および S2）: PSIRT と Release Managers に直ちに連絡し、次のステップを調整してください。一方的に取り消そうとしないでください。

セキュリティ修正が公開されているかどうかに関わらず、いかなる取り消しも、進める前に**PSIRT チームからの明示的な書面による承認が必要です**。緩和オプションとステップバイステップのガイダンスについては、セキュリティマージリクエストによって導入されたバグの緩和方法ランブックを参照してください。

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